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

[thedeemon]

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

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

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

Comments

[codedot.livejournal.com]

Вот это да, сплошные бугагашечки: Си - тупиковая ветвь, JavaScript - на коленке... Си не умрет до тех пор, пока остается язык ассемблера, то есть еще довольно долго, а более элегантного языка, чем JavaScript, мир не знает. Остальные языки мало интересны, так как доступны не везде, кроме, пожалуй, скриптовых языков IEEE 1003.1, но они неотделимы от операционной системы.

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

[dimitrykakadu.livejournal.com]

Я вас прочитал и вспмнил "Срезал" Шукшина.

[w00dy.livejournal.com]

> а более элегантного языка, чем JavaScript, мир не знает

Жжоте напалмом

Мне нравятся такие проверки:
((typeof x === typeof 1) && (null !== x) && isFinite(x)) ;

Object.prototype.toString.call (x) === "[object Date]" ;

Элегантно, лаконично, через жопу ;)

[codedot.livejournal.com]

Будто язык виноват в том, что вы на нем пишите.

[w00dy.livejournal.com]

вот расскажите мне как проверить "тип" того что ко мне пришло? А ещё расскажите как элегантно работают замыкания на уровне функций, а не блоков, как во всех человеческих языках.

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

[codedot.livejournal.com]

Видимо, действительно, проще застрелиться, чем прекратить повсюду совать полиморфизм.

[stdray.livejournal.com]

Как в той презенташке про TypeScript: "Мы смотрели исходники на JavaScript и видели, как разработки перед функцией в комментариях пишут что-то вроде: name : string. Это похоже на систему типов в комментарих. Только ее проблема в том, что она ничего не проверяет".

[mr-aleph.livejournal.com]

а про Closure Compiler мужики-то похоже и не слышали до TypeScript'а

[henryflowerjr.livejournal.com]

$ coffee
coffee> q = new Date()
Thu Oct 11 2012 13:23:36 GMT+0300 (EEST)
coffee> q instanceof Date
true
coffee> class Foo
[Function: Foo]
coffee> w = new Foo()
{}
coffee> w instanceof Foo
true
coffee> q instanceof Foo
false
coffee> class Bar extends Foo
{ [Function: Bar] __super__: {} }
coffee> e = new Bar()
{}
coffee> e instanceof Foo
true
coffee> isNum = (n) -> !isNaN(parseFloat n) && isFinite n
[Function]
coffee> isNum q
false
coffee> isNum w
false
coffee> isNum null
false
coffee> isNum NaN
false
coffee> isNum 1.01
true
coffee> isNum 42
true

[w00dy.livejournal.com]

спасибо, поржал

>> "123" instanceof String
false

А самое забавное:
>> a instanceof test
true
>> JSON.parse (JSON.stringify(a)) instanceof test
false

С локально созданными объектами проблем нет. А вот что делать с данными которые аяксом приезжают? Тащить за собой всю type info?

[henryflowerjr.livejournal.com]

"123" instanceof String

это же классика! ггг

coffee> typeof "123"
'string'
coffee> typeof 123
'number'

или не менее классическое:

coffee> isStr = (s) -> toString.apply(s) == '[object String]'
[Function]
coffee> isStr 123
false
coffee> isStr "123"
true

по поводу JSON.blah мне не понятно, как интерпретатор должен догадываться, когда JSON.blah не делают eval, а имеют гораздо более простой парсер (по известной причине). JS тут не при чем.

Тащить за собой всю type info

нет, просто jsonschema, как обычно.

[blueher.livejournal.com]

Справедливости ради - typeof это всё-таки штука которая пролезла в JS скорее по ошибке. По крайней мере в том виде в каком он есть сейчас. Ну не правильный это стиль для динамики, тут же утиная типизация - надо не даты ждать а чего-то у которого есть метод getDate. Ну нету в JS интерфейсов, а typeof - есть, вот и работает оно вот так вот убого... Да ещё и неявные преобразования типов свою немалую лепту вносят.

Кстати ИМХО - если учесть время за которое делался JS - он просто невообразимо крут. А если ещё и сравнить его с альтернативой на тот момент (VBScript, ага) то нам надо как пацакам - надеть намордники и радоваться что у нас есть такое вот счастье ;)

[w00dy.livejournal.com]

хорошо, расскажу что мне нужно. Есть у меня визуализатор. Ему подсовывают нечто, он это нечто красиво рисует. Подсунули собаку, нарисует собаку. Подсунули утку - будет утка. Число - значит выровняет его по правому краю, дату - посмотрит рядом на формат и отформатирует как попросили, деньги - свои правила. Данные приходят аяксом где никакой информации о типах нет. Что в этом случае делать? То что оно краякает как утка ещё не значит что это утка, может быть это охотник с манком.

[blueher.livejournal.com]

ээээ
не очень понимаю
аяксом данные приходят типизироваными или нет?
как принимается решение десериализировать это в Date или там в Number?

[thesz.livejournal.com]

Пожалуй, отвечу.

VBScript появился позже на год, а уж до широкого применения дело дошло (бы) только в районе IE6, то есть, не ранее 2001 года. На шесть лет позже JS.

Лично я переживаю за альтернативу под названием Tcl, была такая, но тоже позже JS. С ним было бы удобней в разы.

[blueher.livejournal.com]

Я правильно понимаю что тикл был именно альтернативой в том плане что его кто-то серьёзно собирался юзать как внутренний язык для веб-браузера? Я просто про такое не слышал никогда (впрочем, в истории браузеров я не силён).

Или Вы имеете в виду что его МОЖНО было бы встроить?

[kurilka.livejournal.com]

А почему это Tcl позже js? Вроде Tcl на 7 лет старше...

[soonts.livejournal.com]

>с альтернативой на тот момент (VBScript, ага)

JavaScript придумывали для веб страничек.

VBScript придумывали шоб был скриптовым клеем между произвольными COM-объектами.
Обычно написанными на C++, но можно и на том же VBS, см. "Windows Script Components".

В этом качестве он неплохо заруливал, до появления .NET и PowerShell позволяя автоматизировать в мире Windows почти всё шо движется: file system, registry, CDO[EX], ADODB (*), WMI (*), ADSI (*), MS Office, Indexing Service, и т.п.
(*) = "с кучей кастомных провайдеров к ним"

[blueher.livejournal.com]

Я с COM лет 10 проработал, так что ещё помню что там как :)

JScript (который MS-ная реализация JS) заменяет VBScript для целей автоматизации COM на 99%. Оставшийся процент не покрыт скорее из-за лени а не из-за того что есть какие-то принципиальные архитектурные ограничения. Чтобы было понятнее - я имею в виду невозможность сделать на JS вызов IDispatch.invoke с параметром DISPATCH_PROPERTYPUTREF. Есть ещё небольшая мелочёвка с тем что из JScript невозможно менять уже существующий SAFEARRAY - а из VBScript - можно. И это по-моему всё - два редко встречающихся случая, в остальных - всё что можно сделать на VBScript прекрасно делается на JScript. И это так уже много-много лет - начиная с IE4 а может даже и раньше. Да, и реализованы они так что переключать с VBScript на JScript можно просто поменяв один GUID в начале инициализации движка.

И при всём при этом - JS в плане синтаксиса (его регулярности и удобства написания на нём программ) кроет VBS как бык овцу.

Я к чему всё это - задачи этих языков абсолютно одинаковы. Языки эти абсолютно взаимозаменяемы. То что один родился совсем страшненьким а второй - ну, на любителя ;) - то причиной этому только ДНК его родителей ;)

[thedeemon.livejournal.com]

Про Си я такого не говорил. Тупиковая ветвь - динамически типизированные языки, Си я к ним тут не отношу.

Про доступность не везде - нерелевантно, к типизации отношения не имеет. Про место типов в практике - посмешили, спасибо.

[nponeccop.livejournal.com]

Если говорить об очень далеких перспективах - то у типизированных языков всё не так безоблачно. Например, Haskell98 незамкнут относительно эта-экспансии, а замкнутые системы оказываются неудобными либо из-за низкой выразительности, либо из-за отсутствия вывода.

Рассуждения о коде в типизированных языках - это же фейспалм, полная эквациональная теория Haskell Core не так приятна, как хотелось бы, что в Haskell98, что в System FC. Не говоря уже о нечистых и тотальных языках. Все по-средневековому пользуют "morally correct loose reasoning".

У версии бестипового лямбда-исчисления, которой занимается ребе Кодедот, насколько я понимаю, отношение эквивалентности на термах - это транзитивное замыкание отношений эта- и бета-эквивалентности, т.е. очень компактная теория. Удастся ли использовать эту простоту для реализации идеи алгебраизации программирования, о которой нам талдычат уже 40 лет, или же выстрелят конструктивные теории типов - опять же время покажет.

[nealar.livejournal.com]

Haskell98 незамкнут относительно эта-экспансии
Это как? Можно валидный терм эта-расширить и он станет инвалидным?

[nponeccop.livejournal.com]

Это я доумничался. Хорошо что хоть кто-то читает :)

имел ввиду бета-экспансию. (const 5 True, const 5 []) имеет невалидную х98 экспансию (\x -> (x True, x const)) (const 5).

[mr-aleph.livejournal.com]

> а более элегантного языка, чем JavaScript, мир не знает.

годный наброс.

[lemantar.livejournal.com]

а более элегантного языка, чем JavaScript, мир не знает.

ну, вы это ещё не мир.