Про динамическую типизацию

[thedeemon]

Поразжигал немного в комментах у ребе Б. рознь к социальной группе "ленивые авторы языков". Чтобы не излагать свою позицию каждый раз заново, сохраню сюда.

Знаете, некоторые печальные даты надолго остаются в памяти людей: 11 сентября, 17 августа, 1917-й год, 1941-й. К ним стоит добавить 1995-й - год появления JavaScript, PHP, Ruby, ну и Java тоже. Кому-то захотелось по-быстрому добавить динамизма в веб-странички, и он за пару недель наговнякал интерпретатор, встроив его в браузер Netscape. Кому-то захотелось оживить свою домашнюю страничку, добавить счетчик посетителей, еще что-то, и он на коленке сделал такой вот изменятель страничек на стороне сервера. О больших проектах тогда никто не думал, personal home page назывался тот изменятель. А когда делаешь интерпретатор, проще всего сделать его на динамической типизации. Это банально очень просто. О системе типов вообще можно не задумываться, не говоря уже об их выводе. К сожалению, на фоне тогдашнего мейнстрима (Си, ранние плюсы, что там еще было?) эти скриптовые языки выглядели очень выигрышно, писать мелкие куски кода на них было намного проще. Что такое нормальная система типов тогда мало кто знал: хаскель был еще в пеленках, ML'и традиционно не выходили из университетов. Так что люди эти скрипты подхватили, стали добавлять все новые функции. Менять систему типов стало поздно. В итоге выросло то, что выросло. С тех пор одна масса людей занята тем, чтобы делать все более сложные интерпретаторы, которые бы не так тормозили, другая масса придумывает 121-й способ добавить в JS типы, а третья на динамических языках пишет и плачет в бложиках о том, как грустно им делается. И проблема не только и не столько в скорости, сколько в maintainability кода и усилиях на необходимые тестирование и отладку при росте проектов.

Единственная реальная причина появления динамически типизированных языков - лень и недальновидность авторов. Эволюционно динамические языки - тупиковая ветвь, хоть они и обречены рождаться вновь и вновь просто потому что их делать проще, а делать языки люди любят. Сегодняшняя популярность некоторых из них - случайность, исторический казус, следствие контраста между этими языками и мейнстримом начала 90-х. То, что много идиотов используют идиотские языки, говорит лишь о том, что идиотов много. Сегодня, когда есть языки с нормальной статической системой типов, никаких реальных преимуществ у динамической больше нет. Только я имею в виду действительно нормальные статически типизированные языки - как минимум с параметрическим и ad hoc полиморфизмами, с выводом типов. Не Си с джавой. Хаскель, окамл, скала - такого уровня. У этих конкретных языков могут быть свои проблемы, часто инфраструктурные, но речь сейчас не о них, речь о динамической vs. статической типизации в целом.

Comments

[thedeemon.livejournal.com]

Беда, и не одна, несомненно. Но это тоже вопрос хозяйственно-исторический - кто, где и сколько занимался их реализациями. Основная же мысль, что есть примеры нормальных систем типов, лишающих дин.тип. языки их кажущегося превосходства над статическими.

[geekyfox.livejournal.com]

видишь ли, когда код оперирует данными, которые по сути своей имеют типы данных вида Map

[Error: Irreparable invalid markup ('<string,>') in entry. Owner must fix manually. Raw contents below.]

видишь ли, когда код оперирует данными, которые по сути своей имеют типы данных вида Map<String, Object> (как JSON запрос-ответ) или List<Array<Object>> (как базоданный резалтсет) или вообще Array<Object> (как XML DOM) - то единственное эффективное достоинство статической типизации состоит в том, что долгими зимними вечерами можно занять руки <strike>онанизмом</strike> написанием кучи typecast бойлерплейта.

с другой стороны, если надо оперировать действительно хитровыебанными структурами данных - то не подходящий ли это момент, чтобы задуматься о том, а нужны ли эти структуры вообще?

с третьей стороны, у многих ли борцов за статику поднимутся руки объявить несовместимые между собой типы String-который-назначение-платежа и String-который-номер-счёта?

[thedeemon.livejournal.com]

В том-то и проблема, что кто-то поленился типизировать ответ от сервера, и приходится либо писать бойлерплейт, либо держать типы в уме и молиться богам Кобола, что данные придут подходящие.

Если все строго типизировать, никаких Array<Object> и его проблем не будет.

[geekyfox.livejournal.com]

и как ты предлагаешь "типизировать ответ от сервера"? на уровне клиента или на уровне протокола?

[thedeemon.livejournal.com]

На уровне протокола.

[thedeemon.livejournal.com]

Вопрос "стоит ли очень сильно увлекаться типами" закономерен. Если слишком увлечься, получим еще одну Агду, очередной теорем-прувер, продуктивность может сильно упасть. Имеет место компромисс между бысртотой наипсания и корректностью. Я не знаю, где на этой прямой оптимальная точка, и есть ли она, это наверняка зависит от задачи. Для мелких задач (до 200 строк) и скрипты часто сгодятся.

[geekyfox.livejournal.com]

дело не в том, что "увлекаться".

дело в том, что когда нельзя тотально гарантировать корректность логики посредством типов (см. выше пример про перепутанные между собой номер счёта и назначение платежа) - то не получится отвертеться от необходимости писать (А) тесты и (Б) рантаймные валидаторы. а вот эта вот неизбежность тестов и рантаймных валидаторов - она достаточно сильно нивелирует пафос по части статической типизации ;-)

[w00dy.livejournal.com]

как можно перепутать номер счёта и назначение платежа? Это ж разные поля объекта, например.

[thedeemon.livejournal.com]

Ничуть. Тестировать только логику и тестировать все-все-все вплоть до очепяток в именах переменных - большая разница. Чем больше можно переложить на машину, с гарантией полноты, тем лучше. Видимо, до некоторого предела - где сложность обеспечения корректности типами начинает превышать сложность тестирования.

Тесты - это одиночная стрельба в игре "морской бой". Типы - стрельба очередями, проходящими через все поле.

[thesz.livejournal.com]

Типы представляют собой логику. Поэтому гарантировать корректность логики программы с помощью типов можно. Например, легко сделать так, что нельзя перепутать номер счёта и назначение платежа. Поэтому тесты нужны только функциональные, не на каждый чих. И да, проверок условий (рантаймных валидаторов) в нормальной программе быть не должно.

[geekyfox.livejournal.com]

глобально же, меня уже несколько месяцев занимает вопрос того, почему никто не думает о разработке систем в виде пачек изолированных "скриптов до 200 строк" (по скрипту на окошко, допустим, или по скрипту на бизнес-правило)?

почему "большой софтверный проект" - это обязательно объектно-озабоченный монолит на десятки и сотни тысяч строк кода с паттернами, типами, кросс-зависимостями, жабами и змеями?

[thedeemon.livejournal.com]

По идее, сторонники SOA как раз это предлагают - разбивать систему на множество простых сервисов. Но вот всякую ли систему можно так разбить - хз.

[metaclass.livejournal.com]

Потому что изолированные скрипты во всех известных мне реализациях невозможно проверить на валидность статически.
А монолитный проект на C#/F#/Жабе хотя бы часть гарантий дает.

[rblaze.livejournal.com]

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

Надо будет посчитать интереса ради, как меняется число связей в полносвязной системе, если начать делить ее на кластеры. Где-то там в середине долна быть точка минимума.

[potan.livejournal.com]

Видел такие проекты.
Скрипты были на sh и awk в основном. ;-)

[metaclass.livejournal.com]

Так это конечно разные типы. У них даже область допустимых значений совершенно разная. Достаточно поле с Foreign Key объявить - и вот вам новый кошернейший зависимый тип.

[geekyfox.livejournal.com]

я с большим и неподдельным интересом посмотрю на то, как вы будете проверять foreign key в компайл-тайме

[dmzlj.livejournal.com]

на самом деле с "нормальными системами типов" есть некоторая беда, см. например BitC и историю его фейла.

И я в HopC забуксовал из-за этого.

[grey-kristy.livejournal.com]

А где можно почитать про историю его фейла, я что-то сходу не смог нагуглить.
И вообще, для фела рановато - он же еще до первого релиза не дошел?

[thesz.livejournal.com]

BitC прекратили развивать.

[aamonster.livejournal.com]

Для меня то, что Хаскель так и не был портирован ни на WM, ни на Андроид - показатель, что "что-то в консерватории не так". Ведь желающие им пользоваться есть. Значит, устройство компилятора/интерпретатора неоправданно сложное.

[thedeemon.livejournal.com]

Я думаю, это лишь вопрос времени. Тем более, что GHC теперь умеет через LLVM код генерить. Рантайм у хаскеля относительно сложный, заметно сложнее окамловского, но вряд ли сложнее JVM. Вот потребление памяти может стать проблемой, на телефонах ее пока часто не очень много.

[soonts.livejournal.com]

На WM и не будет. WM кагбэ на помойке истории, а под WP7 теоретически есть F#.

Практически однако на нём никто не пишет, по 2 причинам:
1. C# достаточно хорош, особенно с Async CTP расширением языка.
2. Поддержка IDE отстаёт.
Например иногда идеологически правильных data binding/MVVM/visual states/прочих higher-level плюшек не хватает, и нужно идеологически неправильно вручную работать с visual tree.
Для этого IDE компилирует XAMLs в partial classes, герерируя C# properties для именованных элементов в XAML.
Технически не сложно написать например на T4 (Microsoft's Text Template Transformation Toolkit) custom tool, который сгенерирует F# код вместо C#, но AFAIK этого никто не сделал ещё.

[aamonster.livejournal.com]

Кагбэ я искал, когда WM ещё не ушёл окончательно на помойку.
F# - дело хорошее, поддержка одного из диалектов ML Микрософтом - существенный вклад в возможность использования FP. Но мне, пожалуй, интереснее именно Хаскель - потому как он банально проще (ленивость позволила создателям заметно упростить язык) и изящнее, а на данный момент мне пока что актуально не серьёзное использование ФП, а изучение.

Уходя в сторону: не угостите ссылкой, где коротко и понятно описывается async ctp? Кажется, это достаточно интересно, но выискивать информацию в куче постов MS-овского блога - не оптимальный вариант, где-то же должно быть в двух словах (или эта технология неактуальна)

[permea-kra.livejournal.com]

У GHC очень сложный рантайм.