ME>>а еще он может быть дыряв даже на хаскеле с расширениями
K>А пример можно? Только, чтоб именно с параметрическим полиморфизмом проблемы были, а не с помощью лазеек типа unsafeCoerce и прочих unsafe*.

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


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

что значит "полноценность"?

в принципе, данный код можно починить -- скажем, считать, что null означает "вектор у которого дальше идут все нули (т.е. 0-ли), поэтому вычисление скалярного умножения можно закончить прямо здесь"

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

Здравствуйте, alex_public, Вы писали:
А>> Не надо каку с конфеткой сравнивать. У вас, похоже, весьма слабые представления о том, что такое DSL.

_>DSL надо использовать, если он в чём-то удобнее основного языка.

А DSL (если он хорошо спроектирован) всегда удобнее языка общего назначения. Просто по определению.

_> Что касается GUI, то в современных инструментах он в любом случае генерируется в визуальных редакторах.

Руки отрывать мышевозюкалам с их "визуальными редакторами". Особенно если мышевозюкалы свои гнусные привычки на всяких там уродливых Delphi заработали, и ни черта про layout manager-ы не слышали.

_> Соответственно что там генерируется на самом деле не особо и принципиально — всё равно руками это трогать скорее всего никто не будет.

Нуну. Вы, вероятно, из тех, кто HTML в Ворде верстает?

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

Чушь. Забористая такая, начисто лишенная смысла чушь.

А>> Scheme, Ruby, ML, Haskell

_>Т.е. Lisp (кажется в этой темке уже несколько человек сказали что Лисп совсем не функциональный), семейство ML (OCaml, Haskell, F#?) и Ruby (это с его то навязанным ООП???) — это функциональные, да? А скажем Scala, Python, Javascript уже нет? )))

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

_>Что-то попытался вспомнить хоть одно популярное приложение работающее в два процесса (движок и интерфейс) на винде и так не смог.

Что-то не могу припомнить ни одно приличное популярное приложение. Попса она на то и попса.

_> Случаи интерфейсов к драйверам или сервисам естественно не рассматриваем, т.к. там это вынужденная мера. А вы говорите "абсолютно все".
_> Может и MS Office так работает?

MS Office как раз таки образец редкостного говнища. На кой он нужен, когда есть TeX, когда есть Mathematica (кстати, типичный пример архитектуры с оторванным от гуя ядром).

А>> А, мсье мышевоз? Ну что-ж вы тогда в Хаскелль-то полезли, да и вообще в программирование? Ваше дело — дизайн, вот и дизайньте себе.

_>Т.е. у вас проектируют GUI в текстовом редакторе? Соболезную)))

Повторюсь — тем, кто гуйню рисует мышой, надо грабли отрывать без анастезии. Чтоб точно никогда больше не смогли гуйню рисовать.

Следует обратить внимание, что современный гуй под Windows (на XAML) как правило делается именно в текстовом редакторе. Ибо нефиг.

_>Но вот то что Lisp императивный — это довольно неожиданная новость. )))

лисп, скажем так, не шибко функциональный -- т.е. ленивость там можно сделать на макросах, и из персистентных структур данных ( http://en.wikipedia.org/wiki/Persistent_data_structure ) там только списки, да и то, емнип, там есть операции, деструктивно меняющие поля конс-ячейки

MM>Разумеется, нет. Хаскель — это новое изообретение, а не коллекция старых трюков.

че, правда? а как насчет миранды ?

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

MM>Аргумент про type erasure не понятен для языков, компилирующихся в натив. В ассемблерном коде типов всё равно нет.

MM>Вот в Java, где типы сохраняются в байткоде, там да, там type erasure приводит к безумным спецэффектам — скажем, если есть interface I<T>, то нельзя одновременно в одном классе реализовать I<A> и I<B>. В шарпе можно, там не на стирании типов это дело завязано.

что мы имеем:

1. в яве стирание типов, эмулирующее ПП
2. в шарпе ПП
3. твое скалярное произведение пишется и на яве, и в шарпе

вывод -- тебе достаточно стирания типов, а не ПП, ведь так?

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

ФП это чистые функции и персистентные структуры данных, не?

о чем тут можно холиварить?

K>ML семейство и Scheme — это функциональные, императивные языки. Haskell функциональный и декларативный. В принципе, любой язык, в котором функции первоклассны — функциональный и таких ФЯ-инвалидов довольно много.

объясни, в каком месте хаскель более декларативен, чем язык из ML семейства

V>Соответственно, список из print-ов -- это именно список из print-ов ([IO ()]), а не список, в процессе вычисления которого что-то мимоходом напечаталось. Соответственно, его еще надо как-то запустить (вычислить), самое простое -- sequence_.

поподробнее насчет различия "список из print-ов -- это именно список из print-ов ([IO ()]), а не список, в процессе вычисления которого что-то мимоходом напечаталось"

скажем, почему список из объектов, у каждого из которых есть функция print, чем-то хуже "списка из print-ов"?

V>Поскольку IO a -- это именно действие (и, между прочим, чистая ф-я), то их можно комбинировать также как и все остальные выражения. Т.е. можно сделать несколько таких спискок-print-ов и сливать их, можно сделать take/drop, да что угодно. Т.е. уровень работы с программой совершенно другой.

каким образом IO a -- чистая ф-я?

FR>Ну и у рефала ПМ также намного мощней чем у более традиционных ФЯ.

сравнение с традиционными ФЯ не особо интересно, интереснее сравнить ПМ рефала с ПМ пролога

Здравствуйте, Аноним, Вы писали:

_>> Может и MS Office так работает?

А> MS Office как раз таки образец редкостного говнища. На кой он нужен, когда есть TeX, когда есть Mathematica (кстати, типичный пример архитектуры с оторванным от гуя ядром).
Вообразим маленький эксперимент. Завхозу объяснили, как компьютер включать, и назначение некоторых клавиш. Бедолаге надо напечатать крупными буквами "Туалет закрыт из-за отсутствия воды". Есть возможность консультироваться по телефону (пока консультанту не надоест). Какой инструмент ему выбрать -- TeX или Word?

Здравствуйте, Аноним, Вы писали:

А> А DSL (если он хорошо спроектирован) всегда удобнее языка общего назначения. Просто по определению.

Кроме случая, когда вообще без разницы какой там язык.

А> Руки отрывать мышевозюкалам с их "визуальными редакторами". Особенно если мышевозюкалы свои гнусные привычки на всяких там уродливых Delphi заработали, и ни черта про layout manager-ы не слышали.

Хы, в наших инструментах как раз всё на layout manager'ах и работает. Но вставляем мы их в окошко кликом мышки в визуальном редакторе.

А> Нуну. Вы, вероятно, из тех, кто HTML в Ворде верстает?

Я лично ничего не верстаю вообще, как впрочем и GUI не рисую сам. Я больше занимаюсь проектирование архитектуры всего этого. И вот в рамках нашей архитектуры все html генерятся у нас с помощью xslt шаблонов из xml данных.

А> Чушь. Забористая такая, начисто лишенная смысла чушь.

Ну да, понятно.. Образование слабое... Про принцип Оккама никогда не слышали... Сочувствую..

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

В мультипарадигменных языках это не обязательно, т.к. есть другие (и часто более эффективные) инструменты. Не "чистые" естественно.

А> Что-то не могу припомнить ни одно приличное популярное приложение. Попса она на то и попса.
...
А> MS Office как раз таки образец редкостного говнища. На кой он нужен, когда есть TeX, когда есть Mathematica (кстати, типичный пример архитектуры с оторванным от гуя ядром).

Аааааааа, понятно... Тяжёлый случай запущенного красноглазия... Сочувствую...

Кстати, наш софт работает и под Win и под Маc и под Linux. Но последнее мы сделали только потому, что наши инструменты позволяли сделать это автоматически. Если же для этого требовались бы хоть какие-то специальные усилия, то точно не стали бы делать — нафиг нужен этот недорынок (я здесь не про серверный сегмент естественно)...

А> Повторюсь — тем, кто гуйню рисует мышой, надо грабли отрывать без анастезии. Чтоб точно никогда больше не смогли гуйню рисовать.

Так я так не понял, каким инструментом для создания GUI пользуетесь лично вы? )))

А> Следует обратить внимание, что современный гуй под Windows (на XAML) как правило делается именно в текстовом редакторе. Ибо нефиг.

http://ru.wikipedia.org/wiki/Microsoft_Expression_Blend ага, исключительно в текстовом редакторе.

Здравствуйте, m e, Вы писали:

ME>ФП это чистые функции и персистентные структуры данных, не?

ME>о чем тут можно холиварить?

А если язык позволяет писать в стиле "чистые функции и персистентные структуры данных", но не навязывает это как обязательное, то тогда он какой?

Кстати, тут есть и ещё вариант выбора. Есть языки не навязывающие этот стиль, но при этом позволяющие контролируемую компилятором (а не программистом) чистоту — это в D такое есть например. А есть не контролирующие чистоту, но позволяющие все остальные функциональные техники — тот же Питон.

Здравствуйте, alex_public, Вы писали:

_>А вообще я обозвал мегамонадами случаи, когда вся программа состоит только из одной монады (main соответственно) и всё. Т.е. никакого "нормального" код рядом.
_>Да, а в данном случае вообще странно. Я ожидал увидеть в начале презентации системы сборки что-то типа такого http://www.scons.org/doc/production/HTML/scons-user/c258.html — нормальный пример достигаемого эффекта. А то что вылезло там на экран первым делом (после приветствия)... Даже слов нет...

Мне почему-то кажется, вы не поняли, что там было на первом слайде. Весь код на экране был в монаде Shake, а не IO.

Здравствуйте, alex_public, Вы писали:

_>Да, а в данном случае вообще странно. Я ожидал увидеть в начале презентации системы сборки что-то типа такого http://www.scons.org/doc/production/HTML/scons-user/c258.html — нормальный пример достигаемого эффекта. А то что вылезло там на экран первым делом (после приветствия)... Даже слов нет...

Вообще непонятно, чего ты ожидал от видео, озаглавненного "The theory behind an old version of Shake"

Все равно что говорить — посмотрел лекцию по С++, называется "алгоритмы оптимизации инстанцирования шаблонов", думал там Hello World на плюсах увидеть, а там какие-то ужасы и матан.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, jazzer, Вы писали:

J>Вообще непонятно, чего ты ожидал от видео, озаглавненного "The theory behind an old version of Shake"

Я вроде показал в ссылке на scons что я ожидал увидеть на первом (!) слайде к системе сборки. Для тривиальных случаев она по любому должна быть проще чем даже make, иначе никакого смысла нет. Это потом, при добавление сложностей к проекту, могут уже появляться какие-то реальные коды на внутреннем языке системы. Я конечно понимаю, что тут доклад был не о "релизной версии комерческого софта", а о принципах, но не до такой же степени. )))

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, vshabanov, Вы писали:

V>>А собирать хаскелл scons-ом -- это сильно, конечно. Две строчки в Makefile заменить на целую систему сборки.

_>Ну как бы там на языке этой сборки файл проекта и получется из двух строчек. Только он при этом умеет заметно больше make файла. Кроссплатоформенность, отслеживание изменение, отслеживание зависимостей и т.д..

У хаскелла есть ghc --make, кроссплатформено, отслеживает изменения и зависимости. Одна строка. Вторая строчка -- опции, чтобы .o/.hi клал в отдельную папку. Я знаком с SCons, для большинства проектов -- это overkill (хотя, до autotools ему еще далеко .

Здравствуйте, vshabanov, Вы писали:

V>У хаскелла есть ghc --make, кроссплатформено, отслеживает изменения и зависимости. Одна строка. Вторая строчка -- опции, чтобы .o/.hi клал в отдельную папку. Я знаком с SCons, для большинства проектов -- это overkill (хотя, до autotools ему еще далеко .

Для Хаскеля возможно, не буду спорить. Я на нём пока компилировал только программки в один файл и на одной платформе и с одним компилятором. Но для C++ допустим это отличный инструмент. Ну и потом частенько бывает в рамках проекта собираются ещё какие-то дополнительные вещи (хелп например или файлы перевода), которые удобно собирать одной общей командой.

Здравствуйте, m e, Вы писали:

V>>Соответственно, список из print-ов -- это именно список из print-ов ([IO ()]), а не список, в процессе вычисления которого что-то мимоходом напечаталось. Соответственно, его еще надо как-то запустить (вычислить), самое простое -- sequence_.

ME>поподробнее насчет различия "список из print-ов -- это именно список из print-ов ([IO ()]), а не список, в процессе вычисления которого что-то мимоходом напечаталось"

В питоне для [f(x) for x in range (a, b)], если f(x) что-то еще печатает на экран, то он и напечатает (ну и какой-нить результат вернет заодно). В хаскеле так нельзя, 'f' должен быть действием (IO ()) и [f x | x <- [a..b]] будет списком таких действий.

ME>скажем, почему список из объектов, у каждого из которых есть функция print, чем-то хуже "списка из print-ов"?

Тем что это объекты с ф-ей print, а не просто ф-ия print сама по себе. Больше сущностей.

V>>Поскольку IO a -- это именно действие (и, между прочим, чистая ф-я), то их можно комбинировать также как и все остальные выражения. Т.е. можно сделать несколько таких спискок-print-ов и сливать их, можно сделать take/drop, да что угодно. Т.е. уровень работы с программой совершенно другой.

ME>каким образом IO a -- чистая ф-я?

Повторяю:
IO a = World -> (a, World)

Был один мир, открыли файл -- стал другой мир. Т.е. openFile -- вполне себе чистая ф-ия, оперирующая над миром.

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

_>А если язык позволяет писать в стиле "чистые функции и персистентные структуры данных", но не навязывает это как обязательное, то тогда он какой?

тогда он на правильном пути

однако без поддержки компилятора это не имеет особой ценности

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

скажем, можно вспомнить мемоизацию результата чистой функции -- она мутирует данные, но тем не менее не мешает чистоте; с другой стороны, если компилятор не сможет отловить ошибку программиста в *этом* сценарии (когда, скажем, по ошибке из кэша выдается мемоизированный результат не для данной функции, а для другой) -- то это неполноценность языка

_>Кстати, тут есть и ещё вариант выбора. Есть языки не навязывающие этот стиль, но при этом позволяющие контролируемую компилятором (а не программистом) чистоту — это в D такое есть например.

D на правильном пути

_>А есть не контролирующие чистоту, но позволяющие все остальные функциональные техники — тот же Питон.

и ассемблер, гы-гы

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, vshabanov, Вы писали:


V>>Я про то, что писать сборочные скрипты на хаскеле в scons не получится.

FR>Странно что еще не написали сборочную систему на хаскеле, или уже?

Наверняка. Всегда находятся люди, которым нужна система сборки.

V>>А собирать хаскелл scons-ом -- это сильно, конечно. Две строчки в Makefile заменить на целую систему сборки.

FR>make не сборочная система?

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

FR>Две строчки будут в make только для "hello world".

Равно как и в SCons.

FR>Для кроссплатформенных или когда нужна многовариантная сборка scons или аналоги существенно проще чем маке.

Для больших C++ проектов, возможно. Для многих средних проектов make-а более чем достаточно.