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

> Вроде обещают более быструю разработку, но за счет чего? За счет того, что не надо писать тип при объявлении переменной?

Еще за счет выстрого цикла edit-run (из-за интерпретации), и встроенных в язык конструкций вроде хэшей и списков. И специфически динамических фишек, которые позволяют меньше заморачиваться на проектирование.

> Естественно, такие языки можно использовать только для прототипирования, но не проще ли сразу использовать язык, который обеспечит и скорость разработки и скорость выполнения [...] я имею ввиду современные языки с выводом типов

Это какие? Haskell как язык быстрого прототипирования? %)

> Еще за счет выстрого цикла edit-run (из-за интерпретации)

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

> встроенных в язык конструкций вроде хэшей и списков

аналогично

> специфически динамических фишек, которые позволяют меньше заморачиваться на проектирование.

Например? Сыкономив сейчас, потом прийдется все равно ведь переписывать, разве нет? (ну если речь идет не об одноразовом скрипте)

> Например в ocaml

А, то есть в качестве языка быстрого прототипирования предлагается ocaml?

>> специфически динамических фишек, которые позволяют меньше заморачиваться на проектирование.

> Например?

setattr бывает удобен для навешивания на объекты непредусмотренных атрибутов.

> Сыкономив сейчас, потом прийдется все равно ведь переписывать, разве нет?

"сЭкономив", блин. Быть переписанным - это судьба и цель жизни прототипа. Точно так же скорость проги на том же Питоне упирается обычно в ввод/вывод.

P.S. ненавижу динамические языки, но активно использую Питон. И то, поскольку полноценный type inference для полного Питона довольно сложен (и никем не реализован), как бэ намекает, что type inference уменьшит его выразительность.

> А, то есть в качестве языка быстрого прототипирования предлагается ocaml?

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

>> А, то есть в качестве языка быстрого прототипирования предлагается ocaml?

> Да это не суть важно

Бгг. Если разговор о сферических конях вакууме, тогда да.

> есть более удобные и быстрые вещи

Удобные чем и для кого? Кстати... ты знаешь, что первый транслятор ML был написан на Lisp?

> Мотивация писателей этих динамических языков.

Динамический язык проще в использовании (как минимум - для неподготовленных людей) и проще в реализации.

> если программу нельзя ни нормально верифицировать

"Нормально верифицировать" нельзя и программу на Ocaml.

> ни добиться приемлемой скорости выполнения

Чушь.

> ни добиться приемлемой скорости выполнения

man jit

> инамический язык проще в использовании (как минимум - для неподготовленных людей)

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

> и проще в реализации.

Тысячи людей должны мучиться, т.к. пейсатель языка ниасилил?

> Чушь.

В принципе, я и сам скептически отношусь к аргументу "скорость", когда разница меньше порядка, но:

http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=ocaml&...

> man jit

Это мантра? Смысл в компиляции, если в следующий момент времени все может поменяться и придется все делать заново?

> На мой взгляд аргумент "проще для новичка" -- очень плохой аргумент

На мой взгляд, это у тебя от недостатка опыта. Форма юношеского максимализма.

> Ведь не будут же переделывать панель боинга, только потому что я зайду в кабину и скажу "ребята, новичку тут никогда не разобраться, давайте переделывайте"? Что мне скажут на такое заявление?

Тебе скажут, что Як-52 тебя ждет (и ЕМНИП, чемпионаты по воздушному пилотажу проводятся именно на них).

>> и проще в реализации.

> Тысячи людей должны

О чем ты вообще? Не хочешь пользовать - не пользуй.

> мучиться

В сети куча материалов о том, что "писАть на Питоне - удовольствие, на Яве - унылая рутина". Так что всё относительно.

>> я и сам скептически отношусь к аргументу "скорость", когда разница меньше порядка, но:

> http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=ocaml&;...

man SAGE. man Numeric Python.

http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=gcc&am...

хотя и непонятно, что это доказывает.

> Это мантра? Смысл в компиляции, если в следующий момент времени все может поменяться и придется все делать заново?

Это способ получить бонусы динамического языка (в скорости разработки) и нивелировать пенальти на интерпретацию кода в уже готовом проэкте (даёт возможность не переписывать на С после рализации прототипа).

Но в принципе мне всегда хватало скорости самого динамического языка. А если что-то было слишком нагрузочным - писал сразу на С++ и биндил функции в дин. язык, либо писал на дин. языке с учетом того, что потом эту часть выкину и земеню на оптимальную версию на С++.

>За счет того, что не надо писать тип при объявлении переменной? Так это ведь глупость, никакой скорости разработки это не добавит.

сравни в задачах по обработке текста Java и Perl. потом расскажи про скорость разработки :редлол:

>Например? Сыкономив сейчас, потом прийдется все равно ведь переписывать, разве нет? (ну если речь идет не об одноразовом скрипте)

нет

Лень читать. Скажу так

Динамический язык подразумевает task orintation решение задачи.

То есть ты знаешь, что у тебя есть некоторый набор окружения, который умеет решать задачи (например read from file 2 number)

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

Статический же язык ПОДРАЗУМЕВАЕТ знание (детальное) своего окржения

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

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

Есть связь между динамичностью среды и исполнения и свободой типизации. В динамичной среде требование согласованности типов и вообще их "вмороженность" в исполняемую программу заметно затрудняет возможность поменять программу на лету. Хотя вот MS SQL является прекрасным примером динамичной среды со статической типизацией.

Firebird почему-то не позволяет поменять сигнатуру функции, если на неё есть ссылки. А MS SQL позволяет. Видимо, Firebird работает быстрее, но MS SQL гораздо легче поддерживать.

> сравни в задачах по обработке текста Java и Perl. потом расскажи про скорость разработки :редлол:

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

Без динамической типизации, или хотя бы костылей, прикрывающих ее отсутствие(например, без рантайм полиморфизма, вроде "Object" из жабы), вменяемое рефлекшн невозможно.

И, кстати - python или perl - никудышные примеры динамических языков; лучше смотреть в сторону smalltalk и lisp.

А производительность не то чтобы очень уж страдает
http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=sbcl&a...

> Ты после этого не задумываешься, какое окружение тебе доступно,

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

Рискну предположить что на нединамическом языке фреймворк типа django не написать. Например, такое: Entry.objects.filter(headline__startswith="What") где вместо headline можно вписать имя любого поля и он по имени найдёт нужный метод. Один объект может быть "многоликим". Если есть метод __unicode__ то для него в строковом контексте определены строковые операции, если __iter__ то итератор итп.

На самом деле главное грамотный API. Если сделано по-человечески то и на C писать несложно. Вот у питона большинство модулей с грамотным api.

На мой взгляд, интерпретируемость подразумевает и высокоуровневость. Поэтому на интерпретируемых языках часто легче писать. Но есть и исключения(шелл :)).

> ты просто и непринужденно вылавливаешь ошибки в рантайме

тестирование никто не отменял. Там где у одних ошибки в рантайме у других сигфолты :)

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

А с каких пор статика может поймать что-то кроме ошибок типов?

> с каких пор статика может поймать что-то кроме ошибок типов?

Динамика даже их не ловит.

Ошибки типов это одни из самых простеньких видов ошибок. Фактически, в большинстве случаев это опечатки. Вменяемые динамические языки предоставляют инструменты(например, макросы лиспа), используя которые, такие ошибки допустить просто не получится.

А вот использование статики можно сравнить с бегом в стальных валенках - ну то есть да, о попавшиеся на дороге стекла или гвозди ноги ты конечно не поранишь.

> А с каких пор статика может поймать что-то кроме ошибок типов?

Знаете, это тоже очень даже неплохо, поймать ошибки типов

>> А с каких пор статика может поймать что-то кроме ошибок типов?
> Знаете, это тоже очень даже неплохо, поймать ошибки типов

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

> Ошибки типов это одни из самых простеньких видов ошибок.

Это значит, что их не надо ловить?

> Фактически, в большинстве случаев это опечатки.

Чушь.

> Вменяемые динамические языки предоставляют инструменты(например, макросы лиспа), используя которые, такие ошибки допустить просто не получится.

Макросы для ловли ошибок типа? Как интересно. Ну а во втором вменяемом динамическом языке, Smalltalk, что есть для ловли таких ошибок?

> А вот использование статики можно сравнить с бегом в стальных валенках

Это расскажи тем, кто не работал одновременно со статикой и динамико - может, они и поверят.

>> Знаете, это тоже очень даже неплохо, поймать ошибки типов

> Назови класс задач, в котором эта проверка сильно помогает.

Определи "сильно". По моему опыту, статическая проверка типов сильно помогает, когда программу приходится переделывать.

>> Назови класс задач, в котором эта проверка сильно помогает.
> Определи "сильно".

Оценка времени на проведение каких-либо действий с кодом без этой проверки возрастает в 5-6 раз. Пусть будет так. Цифры, разумеется, приблизительные.

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

А можешь рассказать более приближенные к коду места, где эта помощь помогала? Ну и, разумеется, язык сообщить.

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

>>> Назови класс задач, в котором эта проверка сильно помогает.

>> Определи "сильно".

> Оценка времени на проведение каких-либо действий с кодом без этой проверки возрастает в 5-6 раз

Тогда все задачи относятся к этому классу - IDE обычно проверяет код по мере его ввода, и указывает на ошибки, так что затраты времени нулевые. А прогон юнит-тестов требует ненулевого времени.

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

> А можешь рассказать более приближенные к коду места, где эта помощь помогала?

Не понял. Тебе пример реального кода? Извни, не будет.

> Ну и, разумеется, язык сообщить.

Питон. Но не думаю, что это играет роль.

> Я, конечно, помню, что на школьных олимпиадах в условиях резкого дефицита времени компилятор помогал мне не спутать string и integer, но не считаю такой случай уж больно значимым

Ошибки несовпадения типов в 99% случаев свидетельствуют о логической ошибке (олимпиадные задачи не рассматриваем).

>> А можешь рассказать более приближенные к коду места, где эта помощь помогала?
> Не понял. Тебе пример реального кода? Извни, не будет.

Ну не пример кода, я прекрасно знаю, как расшифровывается NDA :) , а типа моего "спутать string и integer".

> Ошибки несовпадения типов в 99% случаев свидетельствуют о логической ошибке (олимпиадные задачи не рассматриваем).

Да и в них тоже об этом свидетельствуют.

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

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

Хотя я, вероятно, хочу чего-то непонятного :)

>Макросы для ловли ошибок типа? Как интересно. Ну а во втором вменяемом динамическом языке, Smalltalk, что есть для ловли таких ошибок?
Не для ловли ошибок. Для построения абстракций, dsl, предотвращающих ошибки-опечатки. st также обладает мощными средствами для построения абстракций.
>Это расскажи тем, кто не работал одновременно со статикой и динамико - может, они и поверят.
А вы из динамических языков попробуйте сначала что-то кроме python и других скриптовых, может тоже поверите.

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

100% покрытие тестами вещь редкая, а при переделке кода не-сбоящие тесты очень сложно придумывать. Ну и по-любому, прогон тестов - это _добавочное_ к компиляции время. Если ошибка обнаружена компилятором, то это время сэкономлено.

> ...кроме тупой сишной ошибки с приведением неразыменованного указателя к целому...

это кстати не "тупая ошибка", а довольно полезное свойство в ряде задач (в основном отладка).

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

Такое не подходит, не?

>> Макросы для ловли ошибок типа? Как интересно. Ну а во втором вменяемом динамическом языке, Smalltalk, что есть для ловли таких ошибок?

> Не для ловли ошибок. Для построения абстракций, dsl, предотвращающих ошибки-опечатки.

Ты сказал:

> Ошибки типов это одни из самых простеньких видов ошибок. Фактически, в большинстве случаев это опечатки. Вменяемые динамические языки предоставляют инструменты(например, макросы лиспа), используя которые, такие ошибки допустить просто не получится.

А теперь говоришь, что с помощью Лиспа и Смолтока можно строить статически типизированные DSL? %)

>>Это расскажи тем, кто не работал одновременно со статикой и динамико - может, они и поверят.

> А вы из динамических языков попробуйте сначала что-то кроме python и других скриптовых

Я знаю Схему в рамках SICP - ровно то же самое. Не говоря уже о том, что многие лисперы не видят принципиальной разницы между Питоном и Лиспом (Норвига почитай).

>Вызов метода объекта, который тебе передали
А вот как насчет добавления классу метода, раз уж про ооп?

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

> 100% покрытие тестами вещь редкая, а при переделке кода не-сбоящие тесты очень сложно придумывать. Ну и по-любому, прогон тестов - это _добавочное_ к компиляции время. Если ошибка обнаружена компилятором, то это время сэкономлено.

Ну это само собой. Просто я привык, что при переделке я гоняю как минимум один тест (и почаще, едва ли не после каждой пары десятков переделанных строчек) и подмены зелёного на круглое таким образом ловятся.

В любом случае спасибо за мнение.

> Вызов метода объекта, который тебе передали (с динамикой тебе во время исполнения могут рассказать, что нету такого метода у объекта); преобразование типа (в динамике тебе его как-то преобразуют, не факт, что преобразование будет корректным).
> Такое не подходит, не?

Второе подходит, спасибо. А первое обычно ловится первым же тестом.

>Я знаю Схему в рамках SICP - ровно то же самое.
А я знаю бейсик в рамках курса, который в школе проходил.
Не смешите народ, да?
>Не говоря уже о том, что многие лисперы не видят принципиальной разницы между Питоном и Лиспом (Норвига почитай).
Это какие-то неправильные лисперы, с каких пор в питоне код представляется в ast? А Норвиг так он элементарные какие-то мелочи сравнивал, если про это http://norvig.com/python-lisp.html.
Посоветую в свою очередь почитать PAIP, того же Норвига, и попробовать что-нибудь из того что там есть изобразить на своем любимом.
>А теперь говоришь, что с помощью Лиспа и Смолтока можно строить статически типизированные DSL? %)
Нет, я говорю об абстракциях, которые снижают вероятность передать в функцию строку вместо числа.

>>Я знаю Схему в рамках SICP - ровно то же самое.
>А я знаю бейсик в рамках курса, который в школе проходил.
>Не смешите народ, да?
Действительно, зачем вы смешите народ сравнивая SICP и васик?

Scheme это учебный язык, ни на что кроме собственно обучения студентов(о да, и написания 10 вариантов y-комбинатора) не годный.

>> Я знаю Схему в рамках SICP - ровно то же самое.

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

Ну если у вас в школе был курс, сравнимый с SICP, я рад за вашу школу.

> Не смешите народ, да?

Смейся. это полезно для здоровья.

>> Не говоря уже о том, что многие лисперы не видят принципиальной разницы между Питоном и Лиспом (Норвига почитай).

> Это какие-то неправильные лисперы, с каких пор в питоне код представляется в ast?

Может быть, эту фишку считают важной только лисперы ЛОР?

> А Норвиг так он элементарные какие-то мелочи сравнивал, если про это http://norvig.com/python-lisp.html.

Про это: "Python supports all of Lisp's essential features except macros, and you don't miss macros all that much because it does have eval, and operator overloading, and regular expression parsing, so you can create custom languages that way".

> Посоветую в свою очередь почитать PAIP, того же Норвига, и попробовать что-нибудь из того что там есть изобразить на своем любимом.

Там есть глава про это. Заканчивается словами: "Both languages seem very well suited for programs like this". И, поскольку ты читаешь невнимательно, повторюсь - я ненавижу все динамические языки, и Питон - тоже.

>>А теперь говоришь, что с помощью Лиспа и Смолтока можно строить статически типизированные DSL? %)

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

Да ради ТНБ, называй их как хочешь. Что бы это не было, оно статически типизировано.

>(ну если речь идет не об одноразовом скрипте)

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

>Может быть, эту фишку считают важной только лисперы ЛОР?
Определенно, только тролли с лора.
А другие лисперы вообще непонятно зачем скобки эти компилируют, извращены может?
>Да ради ТНБ, называй их как хочешь. Что бы это не было, оно статически типизировано.
Статическая типизация - привязка объекта к определенному типу во время компиляции. Если у вас какое-то другое определение, проблемы ваши.

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

Это не динамические языки, а скриптовые языки, батенька.

jit есть только в jvm

> А другие лисперы вообще непонятно зачем скобки эти компилируют,

Лисперы компилируют скобки? O_O

> Статическая типизация - привязка объекта к определенному типу во время компиляции.

Это многое объясняет.

>Scheme это учебный язык

Зато на васике программируют миллионы мух^W офисных работников, потому я и говорю что сравнение Васика и какойто схемы некорректно.

> Динамические языки только и используются для настройки систем, написания скриптов установки и настройки дистрибутивов и прочей подобной одноразовой мути.

Разумеется, про векторные редакторы, месенджеры и прочий крупный софт на скриптовых динамических языках уважаемый собеседник слыхом не слыхивал?

> Динамика даже их не ловит.

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

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