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

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

J>>А то пока что непонятно, почему бы просто не написать a -> а -> c вместо (a ~ b) => a -> b -> c.

MM>Опять-таки, если есть функции над типами, то возможно что-нибудь вроде (F a ~ G b) => a -> b -> ...

Т.е. просто проверка совпадения типов?
Типа такого?

template<class a, class b>
enable_if<is_same< F<a>::type, G<b>::type >>
func( a a_, b b_ )
{}

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

Здравствуйте, alex_public, Вы писали:
_>Разделять (логически) — это одно. А использовать для них разные инструменты (и плюс неизбежные переходники делать) — это только от бедности используемых инструментов. К счастью у моих команд в руках инструменты позволяющие и просто создавать быстрый системный код с логикой и быстро создавать красивые интерфейсы.
Нелюбимый Вами tcl/tk изначально был рассчитан на двухязыковую среду: C (или замена) и tcl. Просто в жизни появилось много проектов на одном tcl/tk (или tcl/tk с некоторыми сишными модулями). Но заявленный Остерхутом принцип создания приложений -- два языка.

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

MM>>Опять-таки, если есть функции над типами, то возможно что-нибудь вроде (F a ~ G b) => a -> b -> ...

J>Т.е. просто проверка совпадения типов?
J>Типа такого?

Угу, оно самое.

Здравствуйте, alex_public, Вы писали:
А>> Да куда уж узкоспециализированнее? Там своя, отличная от всего остального семантика предметной области. ГУЙ на XAML или Tcl/Tk делать надо, на специальных DSL-ях, а не на языках общего назначения.

_>Ну конечно. ))) Может ещё ресурсы (*.rc) от MS были хорошим решением? )))

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

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

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

_>Вообще то это не ответ на мой вопрос — я предложил перечислить подходящие языки. )

Scheme, Ruby, ML, Haskell

А>> Причем тут "бедность"? Это единственный вменяемый подход. Логика отдельно, отрываемые разные ГУЙни к ней — отдельно, другим процессом, с текстовым тупым протоколом между гуем и логикой. Unix way, однако.

_>Да, да, идеология завоевавшая целый 1% рынка — это самый достойный образец для подражания. )))

Идиотские у вас критерии, батенька. Абсолютно все вменяемые приложения под тот же Windows строятся ровно по той же идеологии. Хотя, гуятому программисту этого не объяснить. Для таких, как вы, возможность оторвать безболезненно гуй и заменить его скриптом, или оторвать гуй и заменить его другим гуем (тем же вебом, например) не значит ничего. Потому-то я и не пользуюсь говнопрограммами, которые пишут такие как вы.

А>> Это C++-то? Не поверю. C++ для логики шикарен, да. Но гуй на нем деланный выглядит тошно (имею в виду код). Особенно если это какая-либо пакость вроде Qt.

_>Мне как бы пофиг как он там внутри выглядит — его генерит графический редактор, в котором контролы таскают мышкой. )))

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

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

А>Здравствуйте, alex_public, Вы писали:
А>>> Да куда уж узкоспециализированнее? Там своя, отличная от всего остального семантика предметной области. ГУЙ на XAML или Tcl/Tk делать надо, на специальных DSL-ях, а не на языках общего назначения.

_>>Ну конечно. ))) Может ещё ресурсы (*.rc) от MS были хорошим решением? )))

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

А есть какие-то внятные варианты таких DSL, но чтоб не были прибиты к MS (XAML) или Firefox (XUL) ?

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

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

К>А есть какие-то внятные варианты таких DSL, но чтоб не были прибиты к MS (XAML) или Firefox (XUL) ?

Лично меня прибитость гвоздями к MS или Moonlight ни разу не пугает, красота кода важнее. Для кроссплатформности Tcl/Tk есть.

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

А> Функциональный код на Питоне?!? Не смешите мои панталоны! Какой такой "функциональный" код на языке, где expression и statement это разные вещи?

Лучше скажи, какой "функциональный" код на языке, где expression и statement это одна и та же вещь?

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

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

DSL надо использовать, если он в чём-то удобнее основного языка. Что касается GUI, то в современных инструментах он в любом случае генерируется в визуальных редакторах. Соответственно что там генерируется на самом деле не особо и принципиально — всё равно руками это трогать скорее всего никто не будет. А если редактор имеет возможность генерировать напрямую код на языке, используемом для программирования логики, то это получается совсем хорошо, т.к. убирает все лишние сущности при построение проекта.

А> Scheme, Ruby, ML, Haskell

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

А> Идиотские у вас критерии, батенька. Абсолютно все вменяемые приложения под тот же Windows строятся ровно по той же идеологии. Хотя, гуятому программисту этого не объяснить. Для таких, как вы, возможность оторвать безболезненно гуй и заменить его скриптом, или оторвать гуй и заменить его другим гуем (тем же вебом, например) не значит ничего. Потому-то я и не пользуюсь говнопрограммами, которые пишут такие как вы.

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

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

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

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

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

_>Соответственно что там генерируется на самом деле не особо и принципиально — всё равно руками это трогать скорее всего никто не будет.
Как правило так
_>А если редактор имеет возможность генерировать напрямую код на языке, используемом для программирования логики, то это получается совсем хорошо, т.к. убирает все лишние сущности при построение проекта.
При таком подходе профи может быстро сделать качественный интерфейс. Но вот почему-то то, что творит большинство гуевых специалистов вызывает не очень положительные эмоции. Поменял размер окна -- и ты в заднице. Или чего-то не видно, или ещё что... А что, ведь когда автор мышом контролы двигал в редакторе, у него всё отлично смотрелось.

_>Т.е. у вас проектируют GUI в текстовом редакторе? Соболезную)))
Кому? Не факт, что это требует больше времени или движений рук

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

_>Эээ, Lisp — это тоже анти Хаскель? )))

Особенно Lisp.

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

А>> Scheme, Ruby, ML, Haskell

_>Т.е. Lisp (кажется в этой темке уже несколько человек сказали что Лисп совсем не функциональный)

Scheme — не лисп. Ну, или, если считать, что Scheme — лисп, то тогда Common Lisp — не лисп. Тут, знаете, как с римскими папами и антипапами ситуация. Они бы и жгли друг друга на кострах с удовольствием, да боятся, что огонь на бороду перекинется.

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

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

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

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

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

_>Возможно стоит ещё посмотреть это. Есть какие-нибудь интересные примеры "правильного" кода, но при этом не из абстрактной области, а из реальных приложений?

Не могу сказать. Чукча не читатель. В принципе можно на Hackage залезть, посмореть. Там, правда, в основном библиотеки, и многие сделаны достаточно хило, но все-таки.

V>>Из практики -- позволяет очень много чего обрабатывать как списки, а не в цикле, при этом не выжирая всю память. Какой-нить (putStr . map toUpper =<< getContents) может хоть на гигабайтном вводе работать.
V>>Также можно не задумываясь писать и использовать всякие (forM_ [1..n] ...), никакого списка в памяти не будет (а последние версии ghc вроде вообще такой код могут до обычного цикла соптимизировать).

_>Кстати, что касается ленивости в списках, то в том же Питоне есть некая забавная попытка ленивости — две отдельных функции range и xrange.

А в хаскелле над этим думать не надо (если только в некоторых местах, где может быть переполнение ленивых thunk-ов, но со временем просто перестаешь писать код, где это возможно)

V>>Для утилит хаскелл в принципе самое то (если, конечно, недостаточно sed/awk/grep/10 строк perl). Хотя и для остального хорошо подходит, просто с утилитами проще всего попробовать.

_>У нас много сложных процессов. Правда у Питона в данном случае ещё преимущество в быстрой правке (не компилируемые программки).

Хаскелл вообще достаточно быстро компилится (к тому-же у него есть очень удобный repl, и большую часть времени вообще ничего компилить не надо). А сложные процессы обычно быстро не правятся, т.к. сложные. Плюс, лучше подождать пару секунд компиляции, чем сразу запустить и через полчаса обнаружить опечатку.

V>>Не сказал бы, что монады вообще напрягают и чего-то там слишком много. Кроме ввода/вывода/вызова внешних ф-ий, есть еще и логика, ради которой все эти вызовы делаются. И вот эта логика обычно чистая.

_>Во многих приложения сама логика часто реализуется в виде набора вызовов системных функций. Т.е. даже дело не в императивности (возможно это и можно было под функциональных стиль подвести), а именно в том что вызовы системы, а это в Хаскеле "не чистое". )))

V>>В хаскеле тоже можно, только потом придется sequence добавить, чтобы все-таки выполнить список действий:
V>>sequence_ [do print x; print y | x <- [1..5], y <- [1..5]]

_>Воо, это уже интереснее. ) Но в том же Питоне оно у нас без лишних слов работает. Но в любом случае посмотрею на эту sequence_...

В питоне есть много других лишних слов -- def, class, скобки при вызове ф-ий.
sequence -- просто выполнить список действий:
sequence_ [] = return ()
sequence_ (x:xs) = x >> sequence_ xs

Дело в том, что
IO a = World -> (a, World)
т.е., чистая ф-ия, изменяющая мир (она действительно так реализована)

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

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

Т.е. все эти "нечистые" монадные вычисления, на самом деле чистые, и по сути:
do a <- b; c
более простой способ записать
\ w0 -> let (a, w1) = b w0 in c w1

По-сути, единственное нечистое место -- это ф-я main.

V>>Ну неполезность, она от задач зависит. Возможно, если есть куча наработок/нужных библиотек на питоне, от хаскелла особого толка и не будет. Хотя, у кого как http://habrahabr.ru/company/selectel/blog/135858/

_>Интересно. ) Хотя если у них затык в быстродействие был, то я бы на их месте перешёл на C++11... Ещё про OCaml или D можно было бы подумать, но только в рамках "поиска и фана". А вот C++11 (если конечно найти реальных специалистов) дал бы гарантированный результат.

Про C++ сразу же вспоминается, почему Торвальдс не использовал C++ для Git (где-то был еще более развернутый ответ, чем по сслыке).

Ждать от С++ гарантированный результат по скорости не стоит. С моей точки зрения оптимальным является вариант Haskell-а с Си-шными вставками для самых тупых процессоро-емких частей.

Лет 5 назад еще рулил окемл, но хаскелл значительно подтянулся по скорости, плюс умеет использовать все ядра.

_>Что касается нас, то кучи своих библиотек на Питоне у нас может и нет. Но допустим для сборки проектов (а они бывают сложные, многоступенчатые, с тестами, сборками хелпов, языков, инсталляторов и т.п.) у нас используется scons — скрипт сборки представляет собой просто нормальную Питон программу, работающую в особом окружение. Потом у Питона есть биндинги ко множеству полезных нам библиотек: криптография, гуи, сеть, базы данных.

Ну вставить хаскелл в scons конечно не получится ) Про библиотеки можно на hackage посмотреть. Правда там много чего сырого.

_>О, кстати, интересно... А кто-нибудь использует haskell в качестве серверных скриптов? По идее там многие недостатки будут скрыты за допустим fastcgi интерфейсом или чем-то подобным...

Вообще его обчыно вместе с вебсервером используют (всякие yesod/warp/happs), зачем каждый раз скрипт пускать

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

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

От плохих специалистов не застрахован ни один инструмент. Хотя Java/C# усиленно работают в данном направление. )))

_>>Т.е. у вас проектируют GUI в текстовом редакторе? Соболезную)))
A>Кому? Не факт, что это требует больше времени или движений рук

Больше по крайне мере на время построения проекта (что бы хоть взглянуть что вышло и поправить может). Про удобство и т.п. я уже молчу...

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

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

Воот, с такими формулировками я уже соглашусь.

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

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

_>Единственно что маленькую поправку введу: ФЯ-инвалиды — это обычно мультипарадигменные языки.

Все языки, которые я перечислил, тоже мультипарадигменные. ФЯ-инвалиды — это те, которые "могут и ФП, но как-то по инвалидному", например C#, Ruby, Python. В принципе, в императивных ФЯ типа Scheme и ML с ФП тоже некоторые сложности, но ФЯ-инвалидами они все-таки не являются.

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

ME>нет, я убеждаю тебя, что написанный тобой код на жабе и шарпе не работает -- не проверяет статически равную длинну векторов

Но это не связано с полноценностью параметрического полиморфизма.

ME>а еще он может быть дыряв даже на хаскеле с расширениями

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

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

V>А в хаскелле над этим думать не надо (если только в некоторых местах, где может быть переполнение ленивых thunk-ов, но со временем просто перестаешь писать код, где это возможно)

О, кстати, вспомнил ещё про yield в Питоне — тоже интересное решение для ленивости, в императивном стиле можно сказать. )))

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

Это уже к метапрограммированию ближе получается...

V>Т.е. все эти "нечистые" монадные вычисления, на самом деле чистые, и по сути:
V>do a <- b; c
V>более простой способ записать
V>\ w0 -> let (a, w1) = b w0 in c w1

Всё же синтаксис для этой "императивной" части мне не кажется удобным.

V>Про C++ сразу же вспоминается, почему Торвальдс не использовал C++ для Git (где-то был еще более развернутый ответ, чем по сслыке).

Хы, его отношение к C++ давно известно, так что тут это не совсем аргумент. ) А вот если посмотреть на чём написаны apache, nginx, lighttpd... Или те же самые виртуальные машины сами...

V>Ну вставить хаскелл в scons конечно не получится ) Про библиотеки можно на hackage посмотреть. Правда там много чего сырого.

Про scons я немного в другом смысле. Любая система построения может вызвывать скрипты на любом языке. У нас просто так совпало приятно, что внутренний язык системы построения оказался тем же самым языком, что мы выбрали для всех внутренних процессов. Т.е. мы выбрали не из-за scona'a, но в итоге получили подобный приятный бонус (не надо лишних сущностей). Но если бы мы предпочли другой язык (haskell например) для скриптов, то просто в scons'e/cmake'e был бы соответствующий вызов.

V>Вообще его обчыно вместе с вебсервером используют (всякие yesod/warp/happs), зачем каждый раз скрипт пускать

Собственно при fastcgi он и не запускается каждый раз. Но вообще да, отдельный сервер конечно лучше. Хотя мне всё равно пока как-то привычные доверять nginx/lighttpd... )))

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

K>Все языки, которые я перечислил, тоже мультипарадигменные. ФЯ-инвалиды — это те, которые "могут и ФП, но как-то по инвалидному", например C#, Ruby, Python. В принципе, в императивных ФЯ типа Scheme и ML с ФП тоже некоторые сложности, но ФЯ-инвалидами они все-таки не являются.

Тогда значит только OCaml у нас получается "самый самый"? ))) И в ФЯ не инвалид и всё остальное есть? )

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

_>Тогда значит только OCaml у нас получается "самый самый"?

К сожалению, не получается.

_> И в ФЯ не инвалид и всё остальное есть?

Что остальное?

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

_>Эээ, Lisp — это тоже анти Хаскель? )))

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

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