Зачем нужны динамические языки?

> Векторный редакто? На Ruby? Name one!

Ну почему сразу на руби. Вот тебе на петоне: sK1.

sk1 на Питоне написан.

> Если type inference развит, то компилятор динамического языка может и warning напечатать :)

А может и не напечатать :)

> А может и не напечатать :)

Я вообще особого трагизма из-за неотлавливаний ошибок типов не вижу. Разработка-то (в Лиспе) ведётся в живом образе, написал новую функцию, откомпилировал (она попала в образ), тут же запустил тестики на работоспособность в окружении, на 90+ процентов совпадающем с будущим продакшеном. Биться с ругающимся компилятором не на много быстрее, имхо. Мне иногда приходится программы на плюсах с бустом писать, это гораздо медленнее и утомительнее, чем то же самое на Лиспе делать.

Ну и встроенные в язык регулярные выражения подсовывать вместо макросов Common Lisp какгбе нечестно... ;)

> Я вообще особого трагизма из-за неотлавливаний ошибок типов не вижу.

Разуй зенки.

Отлавливание ошибок типизации нужно не только для "ловли блох". Например, в Хаскеле достаточно часто используется такой приём: после изменения сигнатуры функции запускаем компиляцию - и компилятор автоматически сообщает нам, в каких местах функция используется по-старому (и, как следствие, в каких местах надо исправить). Очень удобная техника.

> Я вообще особого трагизма из-за неотлавливаний ошибок типов не вижу.

Это не мешает языку быть Тьюринг-полным, да.

> тут же запустил тестики на работоспособность

Считай компилятор генератором и запускалкой тестов.

> Биться с ругающимся компилятором не на много быстрее, имхо. Мне иногда приходится программы на плюсах с бустом писать, это гораздо медленнее и утомительнее

Ну Буст и Си++ - это отдельная страшная история.

> Например, в Хаскеле достаточно часто используется такой приём: после изменения сигнатуры функции запускаем компиляцию - и компилятор автоматически сообщает нам, в каких местах функция используется по-старому (и, как следствие, в каких местах надо исправить). Очень удобная техника.

И даже в Си++ :)

> Отлавливание ошибок типизации нужно не только для "ловли блох". Например, в Хаскеле достаточно часто используется такой приём: после изменения сигнатуры функции запускаем компиляцию - и компилятор автоматически сообщает нам, в каких местах функция используется по-старому (и, как следствие, в каких местах надо исправить). Очень удобная техника.

Надену шапку жаботролля и скажу, что можно ещё поставить аннотацию deprecated и разом увидеть всё такие места. Всё, снял шапочку.

> Вообще вопрос скорее такой: сильно ли распространены места, когда ошибка типов не оказывается обнаружена сразу же при первом же тесте.

Если говорить о перле -- то запросто, может быть не замечено очень долго. Пусть даже и есть unit-test со 100% покрытием кода, это может сразу не выстрелить, а выстрелит только когда код сдан в продакшн и работает под нагрузкой.

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

Угу. И при каждой компиляции тратить время на доказательство этой теоремы. А также пытаться уложить свои идеи в прокрустово ложе системы типов конкретного языка (что само по себе бывает мучительно больно).

Кроме того, я бы советовал почитать о системе типов языка с динамической типизацией N1, т.е., Common Lisp. Я говорю не про классы, а про deftype.

Что же касается ошибок, то нет никакого общего средства от ошибок.

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

При это я сам энное время назад перестал быть фанатом динамической типизации, но никто не назвал здесь ту причину, к-рая меня напрягает. И не назову, из вредности :-P

> Считай компилятор генератором и запускалкой тестов.

Очевидно, что проверка типов - это только один и не самый важный тип тестов. Программы всё же, как правило, императивны (даже программы на Хаскеле :-P A тест - это тест функционала. Кроме того, почему я обязан ограничиться _только_ таким типом тестов? И почему я должен платить за их выполнение при каждой компиляции даже тогда, когда они _мне_ в данный момент не нужны? Почему, например, я не могу запускать их каждый 5-й, или каждый 10-й раз или только при сборке релиза?

> Очевидно, что проверка типов - это только один и не самый важный тип тестов.

"Один" - очевидно, "не самый важный" - нет.

> Программы всё же, как правило, императивны

Без расшифровки это утверждение невозможно понять. Впрочем, оно в любом случае не имеет отношения к вопросу.

> Кроме того, почему я обязан ограничиться _только_ таким типом тестов?

??? Кто сказал "ограничиться"?

> И почему я должен платить за их выполнение

Купи нормальный комп.

> При это я сам энное время назад перестал быть фанатом динамической типизации, но никто не назвал здесь ту причину, к-рая меня напрягает. И не назову, из вредности :-P

Причин то много может быть. Тем более - вот нам радость, гадать, что тебя напрягает. Сколько людей, столько и "напрягаловок". Я например когда увидел, как какая-то библиотечная перловая функция возвратила значение "0 but true" (не помню кто конкретно, кто-то из семейства POSIX::*) , чуть кофе не подавился.

> И не назову, из вредности :-P

Вы случаем не девушка?

> Тем более - вот нам радость, гадать, что тебя напрягает
Хорошо, что мне уже с утра удалось кого-то порадовать :)

>> Кроме того, почему я обязан ограничиться _только_ таким типом тестов?
> ??? Кто сказал "ограничиться"?
В статических языках я не могу изменить сам компилятор и мало что могу делать во время компиляции. В CL я во время компиляции могу делать что угодно. И это, кстати, характерное свойство правильного динамического языка. Правда, современные динамические языки это свойство потеряли, если я правильно осведомлен.

> В статических языках я не могу изменить сам компилятор и мало что могу делать во время компиляции. В CL я во время компиляции могу делать что угодно. И это, кстати, характерное свойство правильного динамического языка. Правда, современные динамические языки это свойство потеряли, если я правильно осведомлен.

вот и проговорился

>В статических языках я не могу изменить сам компилятор и мало что могу делать во время компиляции.

Зато в природе существует Форт. Который по своей сути статический, но таскает в себе компилятор. И посему может менять себя в рантайме :)

> В статических языках я не могу изменить сам компилятор и мало что
> могу делать во время компиляции. В CL я во время компиляции могу
> делать что угодно. И это, кстати, характерное свойство правильного
> динамического языка. Правда, современные динамические языки это
> свойство потеряли, если я правильно осведомлен.

В хороших языках - очень даже можете :] (а в плохих это решается препроцессором)

Например, template haskell позволяет вызвать компилятор на стадии компиляции сколько угодно раз и даже сгенерировать различные конструкции языка (или запустить фиговы тесты ;]).

happstack вообще преобразует вбитый прямо в хаскелевский исходник XML в хаскелевские конструкции "втихаря" от пользователя, переопределяя обычный препроцессор своим.

Пример из guestbook в пакете happstack: http://rafb.net/p/x22kzQ25.html преобразуется в http://rafb.net/p/kvtY2U47.html через trhsx

Запуск тестов - это даже не проблема компилятора/интерпретатора - а системы сборки.

> проверка типов - это только один и не самый важный тип тестов.

Это не повод отказываться от этих тестов.

> И почему я должен платить за их выполнение при каждой компиляции даже тогда, когда они _мне_ в данный момент не нужны?

И как, много платишь?

> Почему, например, я не могу запускать их каждый 5-й, или каждый 10-й раз

А в динамичском языке ты можешь такое? Нет. Ты вообще не можешь сказать компилятору "проверяй типы".

>> И почему я должен платить за их выполнение при каждой компиляции даже тогда, когда они _мне_ в данный момент не нужны?
> И как, много платишь?

Ну ты ж сам знаешь, сколько программа на сиплюсплюсе с бустом компилится :)
С этой точки зрения интересен D : там вроде бы есть режим интерпретации кода, для коорого компилировать не нужно. Грубо говоря, как раз вариант "проверяй типы"/"не проверяй типы".

>>> И почему я должен платить за их выполнение при каждой компиляции даже тогда, когда они _мне_ в данный момент не нужны?

>> И как, много платишь?

> Ну ты ж сам знаешь, сколько программа на сиплюсплюсе с бустом компилится :)

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

> Я не знаю, сколько из этого времени компилятор занимается проверкой типов, сколько - обработкой метапрограммных конструкций, сколько - оптимизацией и генерацией машкода. И подозреваю, что den73 тоже этого не знает :)

Исходя из того, что gcc при компилировании сишного исходника до момента получения ast ест мало, а после ast различий особых с плюсами нет, то g++ просто пипец сколько жрёт на разборки с темплейтами. Без теплейтов, кстати, тоже быстро собирает.

> gcc при компилировании сишного исходника до момента получения ast ест мало, а после ast различий особых с плюсами нет

O_O нунихренасебе. Я всегда думал, что AST - это как раз то, что на входе у семантического анализа, где собственно и случается особая Си++-магия

> g++ просто пипец сколько жрёт на разборки с темплейтами. Без теплейтов, кстати, тоже быстро собирает.

Вопрос в том, можно ли "работу с темплейтами" Буста отнести к "проверке типов". ИМХО, это чистое метапрограммирование. Но тогда получается, что сама проверка типов - операция дешевая :)

> O_O нунихренасебе. Я всегда думал, что AST - это как раз то, что на входе у семантического анализа, где собственно и случается особая Си++-магия

Хз, где точно случается магия.

> Вопрос в том, можно ли "работу с темплейтами" Буста отнести к "проверке типов". ИМХО, это чистое метапрограммирование.

Само собой.

> Но тогда получается, что сама проверка типов - операция дешевая :)

Имхо, темплейты - это единственное место в плюсах, где хоть что-то с выводом типов есть. Так-то всё задекларированно должно быть (auto, или как оно там, из последнего стандарта во внимание не берём).

> В статических языках я не могу изменить сам компилятор и мало что могу делать во время компиляции.

В какой момент это стало мешать писать тесты?

Скорее наоборот, систему тестирования, подобную QuickCheck, без статической типизации как-то и не напишешь.

> В CL я во время компиляции могу делать что угодно.

Я тебя обрадую: компилятор ты всё равно менять не можешь.

> Зато в природе существует Форт. Который по своей сути статический, но таскает в себе компилятор.

Поперхнулся бубликом. Это с какого бодуна Форт стал статическим?

>Это с какого бодуна Форт стал статическим?

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

>> В CL я во время компиляции могу делать что угодно.

> Я тебя обрадую: компилятор ты всё равно менять не можешь.

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

>В том-то и прикол, что менять можно вообще всё, за исключением малюсенькой сишной прослойки.

Ну, «почти» - не считается ;)

"Почти" - это часть рантаймовой прокладки между образом и хостом, к компилятору не относится.

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

> Вообще вопрос скорее такой: сильно ли распространены места, когда ошибка типов не оказывается обнаружена сразу же при первом же тесте.

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

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

Например:

$a=array(
"vasya_pupkin@example.com"=>array( "inbox"=>array(....), "sent items"=>array(....) ),
"vasya_pupkin@test.ru"=>array( "inbox"=>array(....), "sent items"=>array(....) )
)

Никто не помешает мне перепутать и написать $a["inbox"]["vasya_pupkin@test.ru"].

Еще на ЛОРе приводил пример: дурное поведение count() в случае массива/обычного значения.

> Мне иногда приходится программы на плюсах с бустом писать, это гораздо медленнее и утомительнее, чем то же самое на Лиспе делать.

А вот давай отделим мух от котлет.

В с++ отвратительный синтаксис, отстутсвует type inference, нет доступа к АСТ (напрямую или через удобную прослоку). Потому оно и намного утомительнее лиспа.

При этом статичкская типизация даже как-то тебе и незаметна.

> Надену шапку жаботролля и скажу, что можно ещё поставить аннотацию deprecated и разом увидеть всё такие места.

Гнутые плюсы тоже умеют deprecated. Однако deprecated тебя не спасет, если ты все-таки пропустишь в одном из мест поменять сигнатуру вызова после смены сигнатуры определения функции.

FIX: Однако deprecated тебя не спасет, если ты в *динамическом языке* все-таки пропустишь в одном из мест поменять сигнатуру вызова после смены сигнатуры определения функции.

> В свете всего этого, языки без типизации (точнее говоря "с динамической типизацией") на мой взгляд - это просто инструмент для лентяев не осиливших типизацию.

FIX:

В свете всего этого, языки без типизации (точнее говоря "с динамической типизацией") на мой взгляд - это просто инструмент, созданный студентами-лентяями, не осилившими type inference.

> А также пытаться уложить свои идеи в прокрустово ложе системы типов конкретного языка (что само по себе бывает мучительно больно).

У хаскеля и в меньшей степени у С++0х система типов не является прокрустовым ложем.

За опровергающий пример был бы благодарен. Впрочем, для этого надо знать их.

> В статических языках я не могу изменить сам компилятор и мало что могу делать во время компиляции.

Это *совсем* не связанные вещи. Метапрограммирование вполне совместимо со статикой и не требует при этом много лишних усилий.

> Имхо, темплейты - это единственное место в плюсах, где хоть что-то с
> выводом типов есть. Так-то всё задекларированно должно быть (auto,
> или как оно там, из последнего стандарта во внимание не берём).

И не просто с выводом типов, с большим абсолютным количеством исходников.

> Простейший пример на РНР: пусть у нас есть есть массив, где хранятся почтовые сообщения, причем первым ключом идет аккаунт, вторым ключом -- название ящика, а внутри уже массив сообщений.
> Никто не помешает мне перепутать и написать $a["inbox"]["vasya_pupkin@test.ru"].

Сдуру можно и в валенок нагадить.
А если писать селектор типа такого: a get -dir "inbox" -account "vasya_pupkin@test.ru", то такую ошибку совершить невозможно.
Отсюда хороший дизайнерский хинт: если ключей больше двух, их стоит подписать.

> FIX: Однако deprecated тебя не спасет, если ты в *динамическом языке* все-таки пропустишь в одном из мест поменять сигнатуру вызова после смены сигнатуры определения функции.

В динамическом языке может оказаться уже проблемой насти место, где поставить это @deprecated :)

Мне вообще тоже очень интересен этот вопрос о (мифическом?) преимуществе языков с динамической типизацией хотя бы хоть в каком-то одном моменте. К сожалению, мне его так никто и не объяснил.

Я постепенно склоняюсь к тому мнению, что чисто исторически сложилось так, что

1. языки, где поленились сделать нормальный type inference взамен сделали что-то полезное, типа метапрограммирования

2. языки с нормальным type inference типа хаскеля окончательно испорчены функциональной парадигмой

3. языки вроде с нормальным type inference типа ocaml имеют слишком слабую систему типов

... короче не сделали пока хорошего языка.

Qi II? Лисп, паттерн матчинг в классическом виде, нормальная система типов (говорят, вроде, лучше даже, чем есть в Хаскелле, но я не разбираюсь), опциональная статическая типизация (можно выключить и потом опять включить). Если образ Qi II собирать на SBCL, то кодогенератор ещё и вполне хороший код выдавать будет.

> насти место

*найти место

> Собственно, лисповый компилятор в SBCL написан полностью на лиспе,

плохо

> и его можно модифицировать

хорошо

> на лету.

плохо

> Qi II? опциональная статическая типизация (можно выключить и потом опять включить) Если образ Qi II собирать на SBCL, то кодогенератор ещё и вполне хороший код выдавать будет.

Ты уже приходишь к более тонким вопросам. Вкратце:

1. я считаю неправильным иметь доступ к АСТ не через прослойку

2. хороший язык должен оперировать в виртуальной машине с/с++ (плоское сегментированное адресное пространство с реальными указателями)

3. если авторы библиотек не заморачиваются с Qi, то она в общем-то бесполезна (тут вопрос о том, насколько типизация считается опциональной коммьюнити)

4. Основная выгода от статики в плюсах -- компилятор знает типы и может соптимизировать. Тут на ЛОРе пробегал случай (с твоим участием кажется) когда SBCL получает указание о типе и в результате генерить более ТОРМОЗНОЙ код.

5. Вместо лиспа (car/cdr) в основе должен быть язык, где веточки устроены более сложно (конкретно щас расписывать не буду).

> Qi II? нормальная система типов (говорят, вроде, лучше даже, чем есть в Хаскелле, но я не разбираюсь)

Можешь указать статьи, где сравнивают эти системы типов? (и да, хорошо бы введение в Qi для знающих плюсовую систему типов)

>> Собственно, лисповый компилятор в SBCL написан полностью на лиспе,

> плохо

С точки зрения кодогенерации - абсолютно параллельно, на чём кодогенератор запрограммирован.

>> на лету.

> плохо

Чем же плохо? Никто не требует модифицировать, просто есть возможность. Если язык позволяет запускать компилятор (aka есть нормальный eval) и включать новый код в тот же образ, то возможность замены всего и вся на лету получается автоматически.

> А если писать селектор типа такого: a get -dir "inbox" -account "vasya_pupkin@test.ru", то такую ошибку совершить невозможно. Отсюда хороший дизайнерский хинт: если ключей больше двух, их стоит подписать.

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

В динамическом языке -- вероятно придется патчить интерфейс коллекции, ну или сразу его писать таким, чтобы он выполнял ту работу, которую выполняет компилятор. Нет?

> 1. я считаю неправильным иметь доступ к АСТ не через прослойку

Для лиспа её и нет. Можно специфичным для реализации способом добраться до ICR или аналога, но это на столько специфично, то для другой реализации всё может быть абсолютно по другому сделано.

> 2. хороший язык должен оперировать в виртуальной машине с/с++ (плоское сегментированное адресное пространство с реальными указателями)

Не понял утверждения. Что такое "виртуальная машина c/c++"? С raw-пойнтерами специфичным для реализации образом работать можно, но лисп умеет жить там, где машинных пойнтеров, как таковых, нет. В конце-концов, лисп - это не ассемблер, хотя и может им быть.

> 3. если авторы библиотек не заморачиваются с Qi, то она в общем-то бесполезна (тут вопрос о том, насколько типизация считается опциональной коммьюнити)

Есть такое исчадие - Clojure, которое работает на JVM, и у которого возможность использовать всё дерьмо, написанное на яве, - одна из killer feature. Моё имхо - Clojure из-за ограничений JVM по некоторым параметрам даже до старичка Коммон Лиспа не дотянет, взять ту же систему исключений.

> 4. Основная выгода от статики в плюсах -- компилятор знает типы и может соптимизировать. Тут на ЛОРе пробегал случай (с твоим участием кажется) когда SBCL получает указание о типе и в результате генерить более ТОРМОЗНОЙ код.

Ну так для того случая type inference в SBCL смог вывести внутренний тип, недоступный пользователю. А пользователь ему потом жёстко задал менее оптимальный тип.

> Можешь указать статьи, где сравнивают эти системы типов? (и да, хорошо бы введение в Qi для знающих плюсовую систему типов)

Гуглем страничку Qi II поищи, там даже автор книжку пишет.

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

Вот тут как раз я и не согласен.

Есть 2 вида гибкости:

1. Можно поменять все что хочешь (а-ля лисп0

2. Можно расставить галки в чекбоксах, выбрать из выпадающих списков и заполнить поля ввода.

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

> В динамическом языке -- вероятно придется патчить интерфейс коллекции, ну или сразу его писать таким, чтобы он выполнял ту работу, которую выполняет компилятор. Нет?

Нет. Написать ещё один селектор, который вернёт съедобную для утилитных классов информацию. И его можно сделать тривиальным для ускорения, а селектор с "подписями" --- несколько более сложным (хотя чего сложного в том, чтобы поставить -mailbox первым аргументом, а -dir вторым?).