<Т.е. MUMPS не умеет читать числа в научной нотации? Вы уверены? Это, скажем так, довольно большой недостаток.
>
Не уверен. Зависит от реализации.
<Это если локаль английская. А в русской локали не выдаст ли оно 3,5?
Хотя тут я, конечно, протупил >
По моему независимо от локали в MUMPS всегда используется '.'
Я не встречал использовании запятой.

Пробелы не игнорируются. В приведенных примерах я не заметил пробела. Если 123 начинается с пробела, то это 0.
" 123"+«3 2 1»=3

«1,5» + «2.5» =3.5
«5E2» + ".01" =5.01
" 123" + «3 2 1» =126

Думать как раз не надо. В MUMPS все всегда однозначно:
«1»+1=2,
«a»+1=1,
«1»+«1»=2.
Всегда так. В арифметической операции «a» = 0, а «25aw7/9» = 25
И никаких неожиданностей быть не может.

Результатом сложения всегда будет число, так как это арифметическая операция. Операцией сцепления всегда будет строка, так как это операция строковая. А при манипулировании данными вообще тип переменной не имеет никакого значения.

Расчетные задачи не самая сильная сторона MSH. Все MUMPS системы разработаны для создания больших информационных систем. Там они и используются. Все используемые MUMPS системы интерпретаторы и этому есть серьезные причины. Часть конструкций этих языков не могут быть оттранслированы в принципе. MUMPS языки это не экзотика, а повседневный рабочий инструмент. То что MSH будет востребован сомнений нет. Просто для языка надо создать экосистему. Это дело труда и времени. Как только экосистема будет создана, с той минуты он и начнет использоваться. Есть достаточно большое сообщество которое в курсе о чем идет речь.

Полностью с вами согласен. Си конечно быстр, но очень далек от идеала. Хотя это связано не только и даже не столько с языком, сколько с окружающей инфраструктурой.

<Разумеется, в языках программирования всё хуже, чем хотелось бы. Но всё, что вы хотите, уже давно есть. Выбирайте — php, javascript — все они радостно будут «управлять типами данных» за вас. А вам останется всего лишь написать логику программы для обработки undefined'ов.>
Конечно есть MUMPS существует уже давно, нет хорошей реализации этого языка, да и некоторые конструкции этого языка устарели. Поэтому то я и занялся этим неблагодарным делом.

Ну тогда вы должны быть в курсе. Я не оспариваю преимущество типизации для трансляторов, они очевидны. Но считаю, транслятор должен быть для программиста, а не наоборот. Для скорости надо писать на Ассемблере.

Я являюсь сторонником безтипового языка.

Программе знать тип конечно необходимо. Но выносить это на программиста вовсе не обязательно. Я знаю по крайней мере 2 способа это реализовать. Любую переменную приводить к одному типу, либо хранить вместе с переменной ее тип.

Незнание не является аргументом. В моем тексте упоминается язык MUMPS. Он и является примером.

Но это не значит, что богатство синтаксиса типов полезно.

В общем случае все вычисления проводятся с базовыми типами, там и возникают проблемы. Против пользовательских типов я ничего не имею против, даже за. Сторонники статической типизации возлагают на нее надежды по борьбе с багами. Проблема багов значительно шире и эффект от применения статической типизации явно преувеличен. Хотя проблема багов одна из самых значительных в программировании, независимо от типизации. Для борьбы с ней наиболее эффективно лишить программиста инструментов управления памятью. Управлять памятью должен полностью компилятор. Динамические языки ближе к решению данной проблемы и поэтому более эффективны.

Можно часть проблем перенести на пользователя. Ввел килограммы вместо грамм. Увидел результат удивился и исправил.

Я не могу судить о вашем проекте. Но я не понимаю как типизация кардинально влияет на создание проекта. Нет типов нет и багов с ними связанными. Речь естественно идет только о базовых типах. Я типизацию только в таком контексте и рассматриваю. В безтиповом языке нет ошибок неправильного применения типа. Любая переменная триединна. Она и целое и действительное и строка одновременно. Ошибка типа заменяется преобразованием к соответствующему типу. Если надо то проверяешь значение всеми доступными средствами, но это касается в основном внешних данных.

<Поэтому я не хочу искать компромиссов, а говорю прямо. Если только начинаете изучать разработку, начинайте со статической типизации.>

А еще лучше вообще забудьте о типизации как о дурном сне.

<Идея ставить во главу типы серьезно повлияла на мое мышление разработчика.
Выбрав в начале пути C#, я прибил гвоздями статическую типизацию к своему мировоззрению, от чего теперь и страдаю. Увидев любую задачу, я пытаюсь представить ее решение как набор типов и принципов их взаимодействия. Когда я разрабатываю модуль, первым делом определяю, какими типами он оперирует и какими взаимодействует со своим окружением. Я даже не помню, как я подходил к решению задач раньше. >

В этом вся соль. Проектирование приложения отталкиваясь от данных. Абсолютно с вами согласен в этом. Только типизация тут вообще не причем. Данные могут быть спроектированы любыми способами способами, хоть в комментариях. Типы только один из способов их спроектировать, и возможно не самый лучший. То что вы к этому пришли через типы, ну прекрасно. Утверждать что проектирование данных вытекает только из статической типизации я бы не стал. Это все таки разные категории.