Джентельменский набор ЯП

> Читай внимательно. Она развалится в любом случае.

Сотфина, написанная на языке со статической типизацией, всё так же заваливается на всяких lexical_cast данных, полученных извне. От проверки корректности параметров никто ведь не избавляет. Чтобы проверить работоспособность при неправильных входных данных, нужно писать юнит-тесты, независимо от использованного ЯП.

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

есть только один критерий оценки специалиста - оценка результатов его работы. не видел ещё ни одного примера запоротого по вине хаскелястов проекта. поделишься?

>Любую мурзилку по ООП открой.

А ты про это... Тут точка зрения другая... Любая, даже самая копипастная программа на языке 1с (Господи, прости) является моделью реального мира. Только отличие в том, что она об этом не знает. Вся эта "модель реального мира" размазана по ней тонким слоем и плюшек от того, что она видите ли модель она не получает.

А про ООП не будем. Я тут почитал намедни "Объектно-ориентированный анализ и проектирование с примерами приложений"... Блин, ценного в книге только библиография. И самое смешное, что придраться не к чему: с тех позиций, с которых авторы смотрят на сишный/явский ООП все правильно.

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

Не видел ни одного проекта на Хаскелле, всё плюсы да йава сплошь и рядом ;)

> Сотфина, написанная на языке со статической типизацией, всё так же заваливается на всяких lexical_cast данных, полученных извне.

"There is no silver bullet" (c)

> Чтобы проверить работоспособность при неправильных входных данных, нужно писать юнит-тесты, независимо от использованного ЯП.

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

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

>>Любую мурзилку по ООП открой.

>А ты про это... Тут точка зрения другая...

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

> Любая, даже самая копипастная программа на языке 1с (Господи, прости) является моделью реального мира. Только отличие в том, что она об этом не знает.

И что? Это модель, пусть коряво написанная. И то, что прогер не понимал, что делает именно модель - это от неумения читать (или понимать прочитанное).

Кстати, есть мнение, что язык 1С - это DSL.

> Я тут почитал намедни "Объектно-ориентированный анализ и проектирование с примерами приложений"... Блин, ценного в книге только библиография.

"Намедни"? Это вчера/неделю/месяц назад? Ну это само по себе многое объясняет.

P.S. насчет того, где разъяснялись DSL и проектирование "снизу вверх" вопросов нет?

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

А это с какого перепоя?

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

> А это с какого перепоя?

С того, что типы неизвестны.

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

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

Мне совершенно никакой разницы не было, как именно проявлялась ошибка в xlib с перепутыванием пиксмапа с окном: сишный wmii сегфолтился, лисповый stumpwm в дебаггер вываливался. Не знаю, как бы себя в такой ситуации повёл православный xmonad, но, думаю, примерно в том же самом духе.

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

Зато на Лиспе проще писать :) Сложные программы выглядят просто.

>> не видел ещё ни одного примера запоротого по вине хаскелястов проекта. поделишься?

Не видел еще ни одного серьезного проекта на хаскеле, поделшься?

> С того, что типы неизвестны.

Почему не известны? "hello" - string, 5 - integer, 'abc - symbol. Если программа сама в себе, то можно вывести типы и проверить корректность программы. Если взаимодействует с внешним мирам, то тут уже пофиг на статичность типизации.

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

Не только. В динамических языках они еще и отлавливают часть несовпадений типов.

> Если код писать вообще без проверок его работоспособности (компиляется, и ладно), то даже ML'шики напишут гонево.

Их гонево будет лучше лисперского ;) Самы лучший комплимент Хаскелю, который я читал - это "если программа скомпилировалась, она с вероятностью 90% заработает правильно".

> Мне совершенно никакой разницы не было, как именно проявлялась ошибка в xlib с перепутыванием пиксмапа с окном

Си? Причем здесь Си? Там даже строгой типизации нет :) Ассемблер, хуле.

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

> Зато на Лиспе проще писать :)

Опа, еще один инопланетянин запалился. Всех в MIB сдам :D

> Сложные программы выглядят просто.

Какой лживый язык :)

> Если программа сама в себе, то можно вывести типы и проверить корректность программы.

Я знал, что кто-то это скажет :) Заметь, ты говоришь о статически типизированном подмножестве Лиспа.

> Если взаимодействует с внешним мирам, то тут уже пофиг на статичность типизации.

Ненене. На функции ввода-вывода можно наложить (системой типов) ограничения, и всё снова шоколадно.

>> С того, что типы неизвестны.

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

> Я знал, что кто-то это скажет :) Заметь, ты говоришь о статически типизированном подмножестве Лиспа.

Ну есть статейки, как это провернуть можно. В Qi вот, который действительно подмножество, есть опционально отключаемая статика. Имхо, это вообще killer feature: в бреду пишем новые идеи без типизаций, а как всё устаканилось более-менее, включаем статику и чистим, чистим...

> Ненене. На функции ввода-вывода можно наложить (системой типов) ограничения, и всё снова шоколадно.

В динамических языках тоже ограничения на io ставят :) В чём же такая реально большая разница?

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

Доказательство "в предположении"? Отлично, отлично.

>И что? Это модель, пусть коряво написанная.

В этом все дело. В точке зрения. В подходе к проектированию. Программа создается в терминах ООП, а не в терминах предметной области. Мы сначала объект предметной области упакуем в парадигму ООП, в понимании C++/Java. И имеем нехилый impedance mismatch между ООП и предметной областью, который мы начинаем доблестно преодолевать.

Даже если при проектировании составляется словарь предметной области, то он тоже составляется в терминах ООП. Куда не кинь - всюду ООП.

Вот в чем проблема не глупых-то в общем-то книжек.

>Ну это само по себе многое объясняет.

Вот только давай не будем опускаться до таких аргументов.

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

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

>> Ненене. На функции ввода-вывода можно наложить (системой типов) ограничения, и всё снова шоколадно.

> В динамических языках тоже ограничения на io ставят :) В чём же такая реально большая разница?

Реальная качественная разница - в том, что ограничения, наложенные системой типов в статическом языке, понятны и известны компилятору.

> Си? Причем здесь Си? Там даже строгой типизации нет :) Ассемблер, хуле.

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

> Доказательство "в предположении"? Отлично, отлично.

На входе в функцию компилятор автоматически ассерты ставит. И часто, ещё и ругается при компиляции. Де, в функции тип такой-то, а ещё выщывают не пойми с чем. У вас Питоне не так? :)

>> Си? Причем здесь Си? Там даже строгой типизации нет :) Ассемблер, хуле.

ты хотел сказать хиндли-миллер?

> Реальная качественная разница - в том, что ограничения, наложенные системой типов в статическом языке, понятны и известны компилятору.

Само по себе никакого изменения в качестве это не даёт. Ну известны типы компилятору, ну и что дальше? Сругается на явно неправильный код, промолчит на неявно неправильный. Как это реально изменит качество? :)

Я не противник статики, просто ничего особенного в ней не вижу.

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

Почему же эксперименты? В том же самом erlang'e есть dialyzer. Хотя пример не совсем корректен.

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

То есть при таком подходе в динамике соответствие типов проверяет человек? Э-э-эм, а зачем, когда есть достаточно продуманные системы типов, и когда этим может заняться компилятор?

> Даже если при проектировании составляется словарь предметной области, то он тоже составляется в терминах ООП. Куда не кинь - всюду ООП.

Смотри глубже. У того же Буча приведена обширная библиография :)

>Вот только давай не будем опускаться до таких аргументов.

Ы... ну извини. Мы все когда-то ничего не знали, в этом нет ничего зазорного. Просто когда ты взываешь к духу веталега и считаешь плодами "преодоления" материал учебника :)

И да. Давайте все-таки различать строгую/нестрогую статическую/динамическую типизацию.

>> Си? Причем здесь Си? Там даже строгой типизации нет :) Ассемблер, хуле.

> ты хотел сказать хиндли-миллер?

Ты хотел сказать Хиндли-Милнер? :) Нет, я не об этом, а о возможности насильного непроверяемого преобразования типов.

>Смотри глубже. У того же Буча приведена обширная библиография :)

Так а я про что?

О, кстати, моя любимая ссылка на эту тему: http://www.pphsg.org/cdsmith/types.html

> Строгая типизация кардинально поможет, если сайд-эффекты полностью запрещены, плюс в самом компиляторе нет ошибок. Отказ от сайд-эффектов в реальном мире очень дорого стоит.

Блин, да что за идеализм? Вечно вам "серебряную пулю" подавай.

P.S. пойду поработаю. Не скучайте :)

>> Доказательство "в предположении"? Отлично, отлично.

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

> Вообще странно у вас там все, 3000 лет математики доказывали теоремы без статической типизации, а тут пришли хаскеллисты и сказали, что это не тру.

А вот это лютейший 4.2

С самого Евклида математики все объекты стали делить на типы, самый простейший пример: арифметические числа и геометрические фигуры. Весь древний мир не решался смешивать вычисления, одновременно пользуясь и тем, и тем. И по этому поводу было очень-очень много парадоксов. Например, парадокс концентрических окружностей. Или самый известный из них: Ахил и черепаха.

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

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

Какие нахрен эксперименты? В лиспе это все уже лет 20 если не больше существует. И очень часто в таком "бреду" все и пишется. Типизация включается чтобы сократить расходы в runtime.

>> То есть при таком подходе в динамике соответствие типов проверяет человек? Э-э-эм, а зачем, когда есть достаточно продуманные системы типов, и когда этим может заняться компилятор?

При чем здесь компилятор? Речь идет о доказательстве свойст функция, а не о проверке их сигнатур.

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

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

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

Вот и думаем кто на самом деле типизацией рулит.

> При чем здесь компилятор? Речь идет о доказательстве свойст функция, а не о проверке их сигнатур.

Ну да, банальный пример в случае haskell -- это djinn у lambdabot. Свойства функций действительно доказываются. Вопрос в том, как это в динамике делать? Откуда компилятор знает, что подсунут на вход в следующий раз?

>> Нет, я не об этом, а о возможности насильного непроверяемого преобразования типов.

Ну да типа преобразование float -> double обрушит все нафиг. Btw, большинство нормальных компиляторов тебе на любом неявном преобразовании выдадут варнинг (если ты конечно опции компиляции правильные выберешь)

>> С самого Евклида математики все объекты стали делить на типы, самый простейший пример: арифметические числа и геометрические фигуры.

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

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

Это уже вопрос правильности работы парсера. Парсер -- это в тривиальном случае функция, которая вернет либо правильную структуру данных , либо ошибку. Что здесь не является статическим типом? Функция определена на множестве входных строк.

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

4.2. Сумма двух площадей и равенство третьей. Пифагоровы штаны помнишь?

>> 4.2. Сумма двух площадей и равенство третьей. Пифагоровы штаны помнишь?

Замечательно что ты это вспомнил. А дальше что? Ну пифагоровы штаны и чего?

А то, что они стали формулироваться так, как в современном мире, лишь во времена Эйлера и Ко. 3000 лет математики думали немного не так свободно, как ты сейчас :)

>> djinn у lambdabot

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

>> А то, что они стали формулироваться так, как в современном мире, лишь во времена Эйлера и Ко. 3000 лет математики думали немного не так свободно, как ты сейчас :)

К черту подробности :)

>Не видел еще ни одного серьезного проекта на хаскеле, поделшься?

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

а серъёзные прокты на хаскеле все как один classified под грифом "перед прочтением съесть"

"С точностью до изоморфизма", да. Тем не менее перед тем, как построить функцию саму, там сначала доказываются ее свойства. Наверняка же ты читал Вадлера по этому поводу.

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

(++) [] xs = xs
(++) (x:xs) ys = x:(xs ++ ys)

эквивалентно

(defun append (x y)
  (cond ((null x) y)
        (t (cons (car x (append (cdr x) y))))))

Дык если почему в первом случае мы можем доказывать свойства (++), а во тором нет?

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

Уже нет :)

Да возьми хотябы тотже С++(только не читай всяких Александреских!!!:), попрогай всякие алгоритмики, потом модельки поизучай(типо MVC, например). Да можно и питон и жабку.