Про динамическую типизацию
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 04:09 pm (UTC)no subject
Date: 2012-10-12 06:08 am (UTC)У Ocaml вроде как очень плохо с библиотеками, D я думаю не лучше (у него только FFI с C может быть получше, но это нишевая фича).
Если говорить об IDE, то есть IDEA и Resharper, вроде как полномасштабная поддержка скалы на подходе, но остальные статические языки не могут похвастать столь хорошей инструментальной поддержкой.
У динамических языков тоже нет поддержки уровня IDEA, но они другим берут - библиотеками, сообществом, дешевизной разработчиков, learning curve, малым временем старта интерпретатора, интеграцией с нетипизированными протоколами и т.п.
Продвинутые статические языки пока - это удел трудных проектов без лигаси. Трудность проекта означает, что объем работ сосредоточен в предметной области, а не в кодировании. Отсутствие лигаси означает, что можно отказаться от старых проверенных решений.
Nasa и Boston Dynamics используют С++ почему-то.
Так что остается только Скала, которая достаточно молода (в отличие от хаскеля и мл) и хайпова, т.е. мне всё ещё непонятно, выстрелит она или нет.
no subject
Date: 2012-10-12 07:08 am (UTC)С++ vs Nasa и Boston Dynamics
Date: 2012-12-14 11:47 am (UTC)На PDP11 траекторию до Марса считали неделю, а на 386 - часа четыре.
На туже совсем другую тему:
вот если выкинуть HTML и перейти на координаты вместо тегов, то сайты будут делать секретарши, как стенгазету: вырезать ножницами и вклеивать, и тогда PHP ненавистный и умрёт.
Re: С++ vs Nasa и Boston Dynamics
Date: 2012-12-14 01:23 pm (UTC)вы явно не в теме
> Этим ребятам всё равно, какой язык.
Вот именно. Язык не важен.
Re: С++ vs Nasa и Boston Dynamics
Date: 2012-12-14 01:52 pm (UTC)"И совершенно непонятно, играет роль в применении для масштабных проектов их типизированность или относительная (по сравнению с дин. языками) убогость выразительных средств, позволяющая легче разбираться в коде."
Как раз порог вхождения повышать - безумие, иначе как бы
"быстренько переписали библиотеки"?
Тут всё время говорят о количестве строк, лаконизме кода. Бред. Пусть хоть миллион, читабельность главнее. Да и транслятор/компилятор/интерпретатор/VM проще.
Если водителю машины хватает для всего руля и педалей, зачем мне ФП, ООП?
Это всё конечно должно быть, но должно быть скрыто от меня, закопано и запрятано. Я машинист экскаватора, закончивший двухмесячные курсы.
Это те самые DSL-языки, про которые автор топика говорит.
Re: С++ vs Nasa и Boston Dynamics
Date: 2012-12-14 03:59 pm (UTC)> лаконизме кода. Бред.
На чём вы основываете своё заключение? На "личном опыте"?
Есть объективные данные о постоянстве строк в день вне зависимости от языка.
Re: С++ vs Nasa и Boston Dynamics
Date: 2012-12-14 05:15 pm (UTC)"Есть объективные данные о постоянстве строк в день" - не вижу глагола. Написания, тестирования, чего?
На разных языках? На разных IDE?
Не верю.
Re: С++ vs Nasa и Boston Dynamics
Date: 2012-12-14 07:55 pm (UTC)"Данных", как оказалось, нет. Беру свои слова обратно.
Re: С++ vs Nasa и Boston Dynamics
Date: 2014-07-02 08:59 pm (UTC)гугление pdp11 calculation mars не помогло
Re: С++ vs Nasa и Boston Dynamics
Date: 2014-07-03 04:21 am (UTC)Re: С++ vs Nasa и Boston Dynamics
Date: 2014-07-03 04:32 am (UTC)Re: С++ vs Nasa и Boston Dynamics
Date: 2014-07-03 04:45 am (UTC)Все эти расчёты в совковом космосе остались под грфом Сов. секретно, так что гуглить не чего, извините ещё раз. Там была , конечно не PDP -11, а совковый аналог. Но производительность компьютеров нас тогда поразила резким сокращением времени расчёта. Возможно дисковая система на 386 была гораздо шустрей, ведь памяти стало 2 МБ вместо 256 кБ. Уже все давно на пенсии, может и живых нет.
Re: С++ vs Nasa и Boston Dynamics
Date: 2014-07-03 04:51 am (UTC)Re: С++ vs Nasa и Boston Dynamics
Date: 2014-07-03 05:54 am (UTC)Re: С++ vs Nasa и Boston Dynamics
Date: 2014-07-03 07:27 am (UTC)Фобос-1 в 1988 году запустили
386 в 1985 году
все ок
Re: С++ vs Nasa и Boston Dynamics
Date: 2014-07-03 07:43 am (UTC)