Про динамическую типизацию
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-12 05:27 am (UTC)JScript (который MS-ная реализация JS) заменяет VBScript для целей автоматизации COM на 99%. Оставшийся процент не покрыт скорее из-за лени а не из-за того что есть какие-то принципиальные архитектурные ограничения. Чтобы было понятнее - я имею в виду невозможность сделать на JS вызов IDispatch.invoke с параметром DISPATCH_PROPERTYPUTREF. Есть ещё небольшая мелочёвка с тем что из JScript невозможно менять уже существующий SAFEARRAY - а из VBScript - можно. И это по-моему всё - два редко встречающихся случая, в остальных - всё что можно сделать на VBScript прекрасно делается на JScript. И это так уже много-много лет - начиная с IE4 а может даже и раньше. Да, и реализованы они так что переключать с VBScript на JScript можно просто поменяв один GUID в начале инициализации движка.
И при всём при этом - JS в плане синтаксиса (его регулярности и удобства написания на нём программ) кроет VBS как бык овцу.
Я к чему всё это - задачи этих языков абсолютно одинаковы. Языки эти абсолютно взаимозаменяемы. То что один родился совсем страшненьким а второй - ну, на любителя ;) - то причиной этому только ДНК его родителей ;)
no subject
Date: 2012-10-12 06:03 am (UTC)"on error resume next" не делается
MsgBox, InputBox тоже.
Оut и In-Out параметры не передаются.
Опциональные параметры не передаются.
Для чисел всего два типа данных, int32 и float64, даже байтов нет.
int64 арифметики нет (которая VT_CY = ole automation currency).
Формат дат свой, отличный от VT_DATE, заебёшься в JScript.
Наконец в JScript даже классов нет.
Кому-нить другому сказки будете рассказывать :-)
no subject
Date: 2012-10-12 06:44 am (UTC)это фича языка, не COM. В JS есть exception-ы которые как бы более общепринятый механизм обработки ошибок. Так что мимо.
>MsgBox, InputBox тоже.
alert, prompt. Были всегда
> Оut и In-Out параметры не передаются.
Это как раз то что я имел в виду под DISPATCH_PROPERTYPUTREF. Был косноязычен, мысль не выразил ясно, каюсь.
> Опциональные параметры не передаются.
Это фича языка, не COM. Мимо
> Для чисел всего два типа данных, int32 и float64, даже байтов нет.
С числами ЕМНИП VBScript тоже не покрывает всего множества вариантов того что лежит в VT_* . Хотя в целом с возражением согласен.
> int64 арифметики нет (которая VT_CY = ole automation currency).
согласен
> Формат дат свой, отличный от VT_DATE, заебёшься в JScript.
согласен
> Наконец в JScript даже классов нет.
А миль пардон - какие классы в COM? Опять же - фича языка. В JScript другой подход к наследованию - классы там как бы и не нужны.
В итоге приходим всё к тому же - есть мелкие несоответствия которые при наличии силы воли можно было легко устранить. Боюсь что не страняли просто потому что в рамках WSH или там HTA VBScript и JScript стыкуются почти бесшовно (как Scala c Java) и если что-то не получается в JScript - ну, добавь VBS-ный файлик и сделай из него.
no subject
Date: 2012-10-12 07:24 am (UTC)И что?
В сценариях автоматизации иногда удобнее resume next.
Из resume next можно сделать аналог try-catch засунув try block в процедуру, а шоб сделать наоборот, нужно каждую строчку оборачивать в свой try-catch.
>alert, prompt
Только в web browser, в рантайме cscript.exe/wscript.exe их нет.
>Это фича языка, не COM
Неверно.
VBScript всё правильно делает, передаёт VARIANT с полями vartype=VT_ERROR scode=DISP_E_PARAMNOTFOUND.
>не покрывает всего множества вариантов того что лежит в VT_*
Конечно не покрывает, и не может: там легко может лежать например IUnknown не поддерживающий IDispatch.
>В JScript другой подход к наследованию - классы там как бы и не нужны.
Классы становятся нужны, если на VBScript/JScript делать что-то сложнее одной страницы кода. ASP Classic приложение, например.
>есть мелкие несоответствия которые при наличии силы воли можно было легко устранить
Можно устранить если вы пишете и скрипт, и COM-объекты с которыми он работает.
Если вы автоматизируете приложение написанное кем-то другим, устранить можно не всё.
Добавлять файлики можно не всегда.
Скрипты которые вообще не обязаны лежать на диске, они могут лежать в базе данных например, и исполняться в контексте какого-нить сервера.
P.S. На одной из прошлых работ довольно много программировал на WSH, только изредка COM-объекты на VB6 и C++, когда скриптов не хватало.
Там было пофигу на чом программировать, поэтому в начале я тоже подумал - чо это они все на VBScript пишут, щас на JScript понахерачу: язык стандартный, и я на нём уже программировал что-то до этого.
Зафейлил, именно из-за херовой поддержки COM Automation.
no subject
Date: 2012-10-12 12:23 pm (UTC)Из resume next можно сделать аналог try-catch засунув try block в процедуру, а шоб сделать наоборот, нужно каждую строчку оборачивать в свой try-catch.
А в JS функции это first-class objects, и из них можно делать массивы описывая шаги отдельно, обработку ошибок - отдельно. Мне лично кажется что это куда как гибче, ну да ладно, спорить не стану.
> Только в web browser, в рантайме cscript.exe/wscript.exe их нет.
Оки, согласен
> VBScript всё правильно делает, передаёт VARIANT с полями vartype=VT_ERROR scode=DISP_E_PARAMNOTFOUND.
Да, с этим согласился уже
>Конечно не покрывает, и не может: там легко может лежать например IUnknown не поддерживающий IDispatch.
Я имел в виду богатство только числовых типов (1-2-4-8 байт, signed/unsigned) - их там с десяток и ЕМНИП VBScript поддерживает далеко не все.
> Классы становятся нужны, если на VBScript/JScript делать что-то сложнее одной страницы кода. ASP Classic приложение, например.
В том-то и поинт мой что как язык для написания чего-то более сложного JSсript лучше VBScript. Классы там есть, просто другие :)
> Добавлять файлики можно не всегда.
> Скрипты которые вообще не обязаны лежать на диске, они могут лежать в базе данных например, и исполняться в контексте какого-нить сервера.
Ну да, но доработать этот сервер для поддержки двух языков - не суперсложная задача.
> Можно устранить если вы пишете и скрипт, и COM-объекты с которыми он работает.
> Если вы автоматизируете приложение написанное кем-то другим, устранить можно не всё.
Опять Вы меня неправильно поняли - я о том что если бы MS хотела бы продвигать JScript как замену VBScript - то дополнила бы JS поддержкой COM на уровен VBS, не так уж много там доделывать. А не захотела бы поддержать JS - пропихивала бы VBScript, и лично мне кажется что плача в форумах по поводу того какой у нас корявый язык на веб-страничках было бы куда как больше.
no subject
Date: 2012-10-12 12:52 pm (UTC)Оба говно: динамическая типизация ;-(
>доработать этот сервер для поддержки двух языков
Сервер для которого я программировал тогда скрипты прекрасно поддерживал оба языка. Однако шоб из JS позвать VBS код, нужно было
(1) Писать этот VBS код в отдельном WSC файле где-то на диске сервера.
(2) Не забыть regsvr32 этот WSC.
(3) Как-то отреплицировать операции (1) и (2) на все компьютеры где работает копия сервера, MSSQL со скриптами прекрасно реплицировался сам.
Разумеется ни одна из проблем не стоила того: на порядки проще было писать всё на VBS.
>если бы MS хотела бы продвигать JScript как замену VBScript
Это после судебного разбирательства 1997-2001 Sun vs. Microsoft?
>пропихивала бы VBScript
Они и пропихивали.
Но к сожалению просрали момент когда нужно было вкладывать ресурсы в свой IE :-(
>плача в форумах по поводу того какой у нас корявый язык на веб-страничках было бы куда как больше.
Вообще бы никто не плакал: довольно быстро смигрировали бы всех на .NET, там статическая типизация :-)
no subject
Date: 2012-10-12 07:09 am (UTC)