Про динамическую типизацию
Oct. 11th, 2012 01:33 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
thedeemonПоразжигал немного в комментах у ребе Б. рознь к социальной группе "ленивые авторы языков". Чтобы не излагать свою позицию каждый раз заново, сохраню сюда.
Знаете, некоторые печальные даты надолго остаются в памяти людей: 11 сентября, 17 августа, 1917-й год, 1941-й. К ним стоит добавить 1995-й - год появления JavaScript, PHP, Ruby, ну и Java тоже. Кому-то захотелось по-быстрому добавить динамизма в веб-странички, и он за пару недель наговнякал интерпретатор, встроив его в браузер Netscape. Кому-то захотелось оживить свою домашнюю страничку, добавить счетчик посетителей, еще что-то, и он на коленке сделал такой вот изменятель страничек на стороне сервера. О больших проектах тогда никто не думал, personal home page назывался тот изменятель. А когда делаешь интерпретатор, проще всего сделать его на динамической типизации. Это банально очень просто. О системе типов вообще можно не задумываться, не говоря уже об их выводе. К сожалению, на фоне тогдашнего мейнстрима (Си, ранние плюсы, что там еще было?) эти скриптовые языки выглядели очень выигрышно, писать мелкие куски кода на них было намного проще. Что такое нормальная система типов тогда мало кто знал: хаскель был еще в пеленках, ML'и традиционно не выходили из университетов. Так что люди эти скрипты подхватили, стали добавлять все новые функции. Менять систему типов стало поздно. В итоге выросло то, что выросло. С тех пор одна масса людей занята тем, чтобы делать все более сложные интерпретаторы, которые бы не так тормозили, другая масса придумывает 121-й способ добавить в JS типы, а третья на динамических языках пишет и плачет в бложиках о том, как грустно им делается. И проблема не только и не столько в скорости, сколько в maintainability кода и усилиях на необходимые тестирование и отладку при росте проектов.
Единственная реальная причина появления динамически типизированных языков - лень и недальновидность авторов. Эволюционно динамические языки - тупиковая ветвь, хоть они и обречены рождаться вновь и вновь просто потому что их делать проще, а делать языки люди любят. Сегодняшняя популярность некоторых из них - случайность, исторический казус, следствие контраста между этими языками и мейнстримом начала 90-х. То, что много идиотов используют идиотские языки, говорит лишь о том, что идиотов много. Сегодня, когда есть языки с нормальной статической системой типов, никаких реальных преимуществ у динамической больше нет. Только я имею в виду действительно нормальные статически типизированные языки - как минимум с параметрическим и ad hoc полиморфизмами, с выводом типов. Не Си с джавой. Хаскель, окамл, скала - такого уровня. У этих конкретных языков могут быть свои проблемы, часто инфраструктурные, но речь сейчас не о них, речь о динамической vs. статической типизации в целом.
Знаете, некоторые печальные даты надолго остаются в памяти людей: 11 сентября, 17 августа, 1917-й год, 1941-й. К ним стоит добавить 1995-й - год появления JavaScript, PHP, Ruby, ну и Java тоже. Кому-то захотелось по-быстрому добавить динамизма в веб-странички, и он за пару недель наговнякал интерпретатор, встроив его в браузер Netscape. Кому-то захотелось оживить свою домашнюю страничку, добавить счетчик посетителей, еще что-то, и он на коленке сделал такой вот изменятель страничек на стороне сервера. О больших проектах тогда никто не думал, personal home page назывался тот изменятель. А когда делаешь интерпретатор, проще всего сделать его на динамической типизации. Это банально очень просто. О системе типов вообще можно не задумываться, не говоря уже об их выводе. К сожалению, на фоне тогдашнего мейнстрима (Си, ранние плюсы, что там еще было?) эти скриптовые языки выглядели очень выигрышно, писать мелкие куски кода на них было намного проще. Что такое нормальная система типов тогда мало кто знал: хаскель был еще в пеленках, ML'и традиционно не выходили из университетов. Так что люди эти скрипты подхватили, стали добавлять все новые функции. Менять систему типов стало поздно. В итоге выросло то, что выросло. С тех пор одна масса людей занята тем, чтобы делать все более сложные интерпретаторы, которые бы не так тормозили, другая масса придумывает 121-й способ добавить в JS типы, а третья на динамических языках пишет и плачет в бложиках о том, как грустно им делается. И проблема не только и не столько в скорости, сколько в maintainability кода и усилиях на необходимые тестирование и отладку при росте проектов.
Единственная реальная причина появления динамически типизированных языков - лень и недальновидность авторов. Эволюционно динамические языки - тупиковая ветвь, хоть они и обречены рождаться вновь и вновь просто потому что их делать проще, а делать языки люди любят. Сегодняшняя популярность некоторых из них - случайность, исторический казус, следствие контраста между этими языками и мейнстримом начала 90-х. То, что много идиотов используют идиотские языки, говорит лишь о том, что идиотов много. Сегодня, когда есть языки с нормальной статической системой типов, никаких реальных преимуществ у динамической больше нет. Только я имею в виду действительно нормальные статически типизированные языки - как минимум с параметрическим и ad hoc полиморфизмами, с выводом типов. Не Си с джавой. Хаскель, окамл, скала - такого уровня. У этих конкретных языков могут быть свои проблемы, часто инфраструктурные, но речь сейчас не о них, речь о динамической vs. статической типизации в целом.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-10-11 11:54 pm (UTC)no subject
Date: 2012-10-12 12:35 am (UTC)Однако объекты там полностью динамические.
Компилятор только изредка варнинги печатает, если объект не поддерживает метод который пытаешься вызвать.
В рантайме иногда крешится, иногда молча возвращает nil, поведение зависит от объекта, у которого метод вызываешь.
Методы там можно форвардить другим объектам, обрабатывать всем скопом в одной функции, добавлять методы к типам в рантайме (вот как тут, поищи "resolveInstanceMethod", увидишь 3 строчки кода, которые добавляют к классу методы по мере необходимости).
Добавлять методы к типам в рантайме
Date: 2012-12-14 11:30 am (UTC)Идея статического ООП из немецкого Ordnung, то есть бредовая.
От объекта никак не зависят мои мысли о использовании его в моих целях. Объекту не дано знать мои мысли, чо я хочу с ним замутить.
Re: Добавлять методы к типам в рантайме
Date: 2012-12-14 05:05 pm (UTC)"Она же" не катит, это 3 совсем разных концепции.
C++ — из перечисленного есть только интерфейсы.
JavaScript — динамические объекты и лямбды.
Obj-C — лямбды (т.н. blocks) имеют мало общего с дин.объектами.
C# — есть все три фичи, но использование каждой опционально: дин. объекты нужны только для COM interop, интерфейсы полезны только начиная со средних по объёму проектов, лямбды обычно нужны только для LINQ.
>Идея статического ООП из немецкого Ordnung, то есть бредовая
В языках вроде C++, Java и C# это прекрасно работает.
Re: Добавлять методы к типам в рантайме
Date: 2012-12-14 05:40 pm (UTC)Сначала интерфейс, потом динамический объект, потом лямбда.
Так же и сначала 1+1, потом a+b, потом a*b, правильное направление мысли.
Сначала исходники до компиляции - статика, потом динамика, потом eval.
Кстати, С++11: http://ru.wikipedia.org/wiki/C%2B%2B11, уже лямбда.
Java: - http://openjdk.java.net/projects/lambda/
и так далее, все хотят остаться на рынке параллельного ПО.
Про ООП и его прекрасную работу я в курсе лет 15, из-за этого надо постоянно выпускать обновления, например полностью переписать ОС, если я хочу шесть мышек включить сразу. Ну вот как без сенсорного экрана сделать жесты?
Подключаете шесть мышек...
Re: Добавлять методы к типам в рантайме
Date: 2012-12-14 06:16 pm (UTC)Лямбды не лучшее решение для параллельного ПО.
Лучшее что я видел, C# 5.0 async/await — работает без лямбд.
>полностью переписать ОС, если я хочу шесть мышек включить сразу
Под винду вообще не надо трогать ОС, есть несколько утилит которые это делают в user-mode.
Это не сложно, т.к. в винде есть нужные API для этого, и для симуляции input тоже.
>как без сенсорного экрана сделать жесты?
Во-первых сенсорные экраны будут, см. сотни новых моделей ноутов с наклейками "Windows 8".
Во-вторых специально для жестов без сенсорного экрана, прошлой зимой вышел Kinect for Windows.
Re: Добавлять методы к типам в рантайме
Date: 2012-12-14 07:22 pm (UTC)