ML-стайл вывод типов мне норм. Другое дело, что он не ко всем проектам подходит (я вот, например, сегодня добавил поддержку нового обрабатываемого типа данных в выполняющуюся программу прямо на ходу, не останавливая её), но по крайней мере он имеет отчётливый смысл и в ряде случаев полезен.
Я Ваши повадки хорошо знаю и оспаривать их не собираюсь, но согласитесь, что сама по себе невозможность присвоить паскалевской переменной типа integer значения типа boolean никак Вас к вашей цели не приблизит.
А почему вы смешиваете отсутствие типизации (нет, я никогда не буду в серьёзных разговорах использовать оксюморон «динамическая типизация») и неявную типизацию?
Я вроде не смешивал.
Паскаль у нас теперь образец языка с сильной и выразительной системой типов?
Нет, Паскаль образец языка с полумерами в отношении системы типов, которые и в смысле контроля ничего особенного не дают, и лишнюю писанину делать заставляют.
Реальная востребованность их, как видим, невелика.
Ну куда уж TS и mypy до Lisp и Scheme, понятное дело.
Конечно, но надо смотреть, когда и насколько это оправдано.
Для сложных вычислительных задач, когда надо выжимать последние наносекунды из обработки чисел, конечно, надо использовать адекватное машинное представление. Но там и Фортран выучить бы заодно неплохо.
А в рядовой повседневной практике арифметика неограниченной точности может быть вполне оправдана.
Предположу, что ситуации, когда не возможно определить тип элементов коллекции довольно далеко от обучения программированию.
Тут возникла некоторая путаница в изложении. Конечно, нетривиальные случаи выходят за рамки обычного обучения. Однако тут приводился аргумент, что обучение динамическому языку плохо, потому что в коммерческой практике динамические языки плохи. И вот это утверждение сомнительно как в своём обосновании, так и в причинно-следственной связке.
А в Питоне меня в своё время поразил переход на key-functions вместо компаратора (ну или интерфейса Comparable, если бы такое там было).
Это действительно очень странно. Безусловно, в Питоне много странных вещей. Начиная с отступов.
ML-стайл вывод типов мне норм. Другое дело, что он не ко всем проектам подходит (я вот, например, сегодня добавил поддержку нового обрабатываемого типа данных в выполняющуюся программу прямо на ходу, не останавливая её), но по крайней мере он имеет отчётливый смысл и в ряде случаев полезен.
Я Ваши повадки хорошо знаю и оспаривать их не собираюсь, но согласитесь, что сама по себе невозможность присвоить паскалевской переменной типа integer значения типа boolean никак Вас к вашей цели не приблизит.
Пример чего? Когда не всегда возможно? Сортировка.
Я вроде не смешивал.
Нет, Паскаль образец языка с полумерами в отношении системы типов, которые и в смысле контроля ничего особенного не дают, и лишнюю писанину делать заставляют.
До JS и CPython.
Когда попробуете. Это ж динамическая типизация.
Ну вообще-то есть. Например, неоднократно рекомендовавшийся здесь Scheme.
Но в большинстве языков приоритеты операций вполне естественны и не нуждаются в специальном заучивании.
Проблема в том, что для элементарных типов это не так. Хотя логически никакой принципиальной разницы нет.
Но эта проблема касается большинства языков.
Один только приоритет операций чего стоит.
Ну это где как. В том же питоне не отличается.
Это совсем упрощённое понимание. На самом деле же ячейки фоннеймановской памяти ни для чего специально не предназначены.
Обычно это как раз они допускают.
Согласен с Вами.
Тем не менее, качественно результат там тот же.
Хотя репрезентативность опроса, в котором Haskell и Lisp каждый вдвое популярнее Фортрана, вызывает у меня большие сомнения, при всей моей любви к ФП.
Большая часть человечества вообще кушает палочками, так что аналогия не очень ясно просматривается.
Конечно, но надо смотреть, когда и насколько это оправдано.
Для сложных вычислительных задач, когда надо выжимать последние наносекунды из обработки чисел, конечно, надо использовать адекватное машинное представление. Но там и Фортран выучить бы заодно неплохо.
А в рядовой повседневной практике арифметика неограниченной точности может быть вполне оправдана.
Ну питон и некоторые другие языки так работают.
Если он именно кастовался, то статическая типизация ничем не помогла. А вот динамическая, кстати, помогла бы в момент первого инкремента.
Так что ваш аргумент играет против того, что вы, по всей видимости, хотели им доказать.
Согласно TIOBE, интерес к TS более чем на порядок меньше, чем к JS.
Тут возникла некоторая путаница в изложении. Конечно, нетривиальные случаи выходят за рамки обычного обучения. Однако тут приводился аргумент, что обучение динамическому языку плохо, потому что в коммерческой практике динамические языки плохи. И вот это утверждение сомнительно как в своём обосновании, так и в причинно-следственной связке.
Это действительно очень странно. Безусловно, в Питоне много странных вещей. Начиная с отступов.
Scratch–Logo–Scheme – это прямо немеркнущая классика.