пока вы пишете на C "супер-эффективный" код, вылизывая каждый его байт так, чтобы он идеально ложился на x86...
дядя Петя собрал кластер из многопроцессорных тачек, набросал пару строк на Erlang для решения той же задачи и грызет семки
это я шучу, разумеется
>> Но на практике нет свободно доступных компиляторов для функциональных языков, которые генерировали бы код сопоставимый по быстродействию с "C"
есть, компиляторы семейства ML сопоставимы по эффективности генерируемого кода с C
>> Далее, большинство функциональных языков явным или неявным образом завязаны на распределение памяти со сборкой мусора
в функциональных языках возможен ескейп-анализ кода для замены heap allocations на stack allocations, чтобы не пришлось на каждый чих выделять объект на хипе
вообще исходя из моей практики если у вас производительность упирается в работу кэша из-за нелокальности доступа это говорит о плохом дизайне
>> И еще с моей личной точки зрения писать большие проекты на функциональном языке гораздо сложнее и этот процесс больше напрягает голову, чем программирование на старом добром императивном языке.
а я сейчас пишу серверную часть на Erlang для вебсервиса никакого напряга, про PHP забыл, как про страшный сон
проблема распараллеливания имеет самое прямое отношение к языку, вы очень сильно ошибаетесь и вводите в заблуждение других читателей этой ветки
вот вам простой пример: в Haskell можно запускать выполнение любой функции в параллельном потоке потому что сама семантика языка гарантирует отсутствие скрытых зависимостей от других контекстов исполнения (например чтения-записи в общую память или же какого-либо I/O с интерфейсами OS, могущими привести к этому)
то есть, это поведение зашито в саму модель языка Haskell
в C++ же компилятору придётся проводить сложный семантический анализ кода для распараллеливания, чтобы выяснить, есть ли скрытые зависимости и в общем случае эта задача там неразрешима
у эрланга и так есть JIT-компилятор HiPe, да и мы сейчас сравниваем существующие уже сегодня решения для параллелизма Эрланг проще на порядок и на прикладном уровне эффективнее, чем C++ с OpenMP, факт
>> К тому же OpenMP это тоже позволяет
OpenMP не позволяет разнести числодробление на 1000 машин, а в Erlang это встроено какой смысл запускать моделирование погоды на одном компе, пусть и с 32-ядерным процессором
P.S. тред уже слишком затянулся, хабр начинает глючить при таком уровне вложенности
>> Сравните к примеру CGI с тем же QT или GTK и поймете чем разница
CGI - это common gateway interface? ну и как его можно сравнивать с GUI фреймворком? это же разные вещи
вот например Yahoo UI library для яваскрипта и GTK очень даже можно сравнить
>> В 70-80 годах строили lisp машины.
это были просто беспомощные игрушки, они были слишком сложные, чтобы работать эффективнее, чем Core 2 :)
сложные вещи не работают
>> Вообще-то я говорил про то что многие задачи проще решаются
многие это какие? не будьте голословны
я пока не вижу ни одной large-scale задачи, которая проще решается на императивном языке
существует критерий эффективности рендеринга в hardware execution модель здесь императивные языки, безусловно, обладают большим потенциалом, т.к. они ближе к этой модели
но чтобы простота и в императивном языке я такого не видел
>> Ну если вы так настаиваете, то я вам советую написать простой почтовый GUI-клиент
я вас уверяю, что на Erlang кода будет меньше и он будет чище, чем с Java это подсказывает мне мой опыт в императивных и функциональных языках
сделать для Erlang биндинг к какому-нибудь рендереру для рисования "квадратиков и кнопочек" много ума не надо
разумеется, если мне надо будет написать почтовый клиент для десктопа я возьму WPF а не erlang, потому что для Erlang надо писать биндинги, а WPF уже сегодня работает из коробки
ну это будет совсем другая статья и не совсем про Erlang
к примеру, чтобы объяснить нетривиальность распараллеливания в языках с shared memory надо целую книгу написать
без таких "рекламных" статей у языка никогда не появится такого же комьюнити, как у Ruby или Python Erlang существует уже пару десятков лет, но до недавнего времени о нём вообще никто не слышал
>> Вообще-то они различаются подходами и механизмами. И кстати очень сильно.
не вижу разницы это интерфейс человек-машина, мышкоклавиатурновизуальный
задачи у веб-приложений и десктоп-приложений одинаковые, просто сегодня еще есть это разделение из-за несовершенства технологий, а завтра его уже не будет
>> Пока не появится машины которая будет выполнять функциональный язык на уровне железа будет всегда наблюдаться преобразование функционал в императив.
такого железа никогда не появится, потому что машина Тьюринга это наиболее близкая к реальности абстракция
>> Но вот количество затраченных ресусров может сильно различаться для разных задач.
именно это я и сказал FRP проще в функциональном языке
а учитывая то, что FRP проще "императивной интерактивности" следует то, что программировать GUI в функциональных языках проще
специально для вас добавил в конец статьи пример с ping-pong
спама на хабре хватает, а это статья, которая полезна людям, разрабатывающим распределенные приложения (скалируемый server-side, например, в контексте веба)
>> второй - нет результата.
почему же, есть результат посмотрите на кол-во комментов к статье, куча народу сегодня узнали про Erlang
>> Уберите рекламные обороты и текст сократится в 3 раза, а то и больше.
и что от статьи останется? "есть вот такая штука Erlang, да, вот такие-то цифры показывают то-то", очень интересная статья
а главное, что тогда задачи своей она не выполнит не вызовет интереса
а чем в вашем понимании интерфейсы в вебе отличаются от "GUI"?
не вижу никакого криминала, кстати, в преобразовании declarative -> imperative, декларативный код сам по себе святым духом исполняться не будет ведь
а FRP возможен в любом языке, хоть в C
функциональное/декларативное программирование не привязано к языку, просто в языке, который на семантическом и синтаксическом уровне поддерживает такой стиль это делать проще, только и всего
к примеру, в .NET всё это дело прекрасно живет в среде императивного C#, просто из-за негибкости языка пришлось сделать доп. декларативную прослойку в виде XAML, в случае Haskell или Erlang этого делать бы не пришлось
вы потратили 5 минут времени на то, чтобы узнать, что есть вот такая штука Erlang, и "о чём" эта штука
а каков синтаксис языка для передачи сообщений это тема для другой статьи
вам что, надо Hello World но в терминах message-passing? классический пример "ping-pong" или thread ring? вы потратите куда больше времени, чем 5 минут на то, чтобы разобрать такой код на незнакомом языке, а практическая ценность такого кода не больше, чем "вычислить площадь с pattern matching"
хотите "реальных примеров" скачайте ejabberd в исходниках
эм. а вот каким местом C "быстрее" C++?
может, вы еще и считаете, что C++ это "ООП"-язык, а C, типа, нет?
>> Дадите кармы - обещаю написать хабратопик, что дает объектно-ориентированный подход, например в PHP :)
не дам, сначала вам надо осознать, что ООП ортогонально функциональным языкам, да и каким-либо языкам вообще
>> что функциональные языки - это то, что придет на смену объектно ориентированным
"объекто-ориентированные" языки это миф
собственно, Армстронг в статье с большой-пребольшой иронией написал "эрланг - не объекто-ориентированный язык"
дядя Петя собрал кластер из многопроцессорных тачек, набросал пару строк на Erlang для решения той же задачи и грызет семки
это я шучу, разумеется
>> Но на практике нет свободно доступных компиляторов для функциональных языков, которые генерировали бы код сопоставимый по быстродействию с "C"
есть, компиляторы семейства ML сопоставимы по эффективности генерируемого кода с C
>> Далее, большинство функциональных языков явным или неявным образом завязаны на распределение памяти со сборкой мусора
в функциональных языках возможен ескейп-анализ кода для замены heap allocations на stack allocations, чтобы не пришлось на каждый чих выделять объект на хипе
вообще исходя из моей практики если у вас производительность упирается в работу кэша из-за нелокальности доступа это говорит о плохом дизайне
>> И еще с моей личной точки зрения писать большие проекты на функциональном языке гораздо сложнее и этот процесс больше напрягает голову, чем программирование на старом добром императивном языке.
а я сейчас пишу серверную часть на Erlang для вебсервиса никакого напряга, про PHP забыл, как про страшный сон
вот вам простой пример: в Haskell можно запускать выполнение любой функции в параллельном потоке потому что сама семантика языка гарантирует отсутствие скрытых зависимостей от других контекстов исполнения (например чтения-записи в общую память или же какого-либо I/O с интерфейсами OS, могущими привести к этому)
то есть, это поведение зашито в саму модель языка Haskell
в C++ же компилятору придётся проводить сложный семантический анализ кода для распараллеливания, чтобы выяснить, есть ли скрытые зависимости и в общем случае эта задача там неразрешима
то-то у меня в Safari каждый второй сайт с cp1251 отображается кракозябрами..
это не в браузерах дело, а в разработчиках этих корявых сайтов
>> А я вообще-то говорил про взаимодействие браузера с сервером через протокол http.
угу, вот мой терминал работает в браузере и взаимодействует с сервером через протокол http хоть я напрямую и не работаю с http
что я делаю не так? :)
как мне увидеть разницу-то?
это неправда, они ничем не отличаются
говорю вам, как разработчик вебсервисов и десктоп-приложений
у эрланга и так есть JIT-компилятор HiPe, да и мы сейчас сравниваем существующие уже сегодня решения для параллелизма Эрланг проще на порядок и на прикладном уровне эффективнее, чем C++ с OpenMP, факт
>> К тому же OpenMP это тоже позволяет
OpenMP не позволяет разнести числодробление на 1000 машин, а в Erlang это встроено какой смысл запускать моделирование погоды на одном компе, пусть и с 32-ядерным процессором
P.S. тред уже слишком затянулся, хабр начинает глючить при таком уровне вложенности
вот недавно писал терминал на Flex/ActionScript с сервером на PHP никакого http протокола я не видел, работал на уровне SOAP-вызовов
пересылку по HTTP за меня делала программная абстракция
и "взаимодействие клиента и сервера" свелось в коде к прямому вызову функций
для меня, как для пользователя разницы нет, какая разница, что находится внизу стека технологий, если в конечном счете работа идет с вершиной стека
>> Среда обеспечивающая работу Erlang сложна, но при этом она работает.
вам кажется на самом деле, оптимизирующий компилятор C++ с поддержкой OpenMP на порядок сложнее виртуальной машины Эрланга
>> GUI-приложения, различные десктопные окружения аля KDE.
хочется продолжить: .. операционные системы :)
*thumbs up*
>> чтобы получить меньше кода чем на императивном языке
вообще-то, объем код сокращается не языком, а программными абстракциями, например FRP
абстракции проще моделировать на функциональном языке это факт
>> К примеру моделирование погоды. Я что-то не слышал чтобы там использовали Erlang.
а я бы использовал там Erlang - для распределенности, а числодробилку вынес бы в C-код
получилось бы очень эффективно и малой ценой
многие числодробильные задачи раскладываются на scatter/gather, т.е. параллелизм по данным
CGI - это common gateway interface? ну и как его можно сравнивать с GUI фреймворком? это же разные вещи
вот например Yahoo UI library для яваскрипта и GTK очень даже можно сравнить
>> В 70-80 годах строили lisp машины.
это были просто беспомощные игрушки, они были слишком сложные, чтобы работать эффективнее, чем Core 2 :)
сложные вещи не работают
>> Вообще-то я говорил про то что многие задачи проще решаются
многие это какие? не будьте голословны
я пока не вижу ни одной large-scale задачи, которая проще решается на императивном языке
существует критерий эффективности рендеринга в hardware execution модель здесь императивные языки, безусловно, обладают большим потенциалом, т.к. они ближе к этой модели
но чтобы простота и в императивном языке я такого не видел
>> Ну если вы так настаиваете, то я вам советую написать простой почтовый GUI-клиент
я вас уверяю, что на Erlang кода будет меньше и он будет чище, чем с Java это подсказывает мне мой опыт в императивных и функциональных языках
сделать для Erlang биндинг к какому-нибудь рендереру для рисования "квадратиков и кнопочек" много ума не надо
разумеется, если мне надо будет написать почтовый клиент для десктопа я возьму WPF а не erlang, потому что для Erlang надо писать биндинги, а WPF уже сегодня работает из коробки
ну это будет совсем другая статья и не совсем про Erlang
к примеру, чтобы объяснить нетривиальность распараллеливания в языках с shared memory надо целую книгу написать
без таких "рекламных" статей у языка никогда не появится такого же комьюнити, как у Ruby или Python Erlang существует уже пару десятков лет, но до недавнего времени о нём вообще никто не слышал
не вижу разницы это интерфейс человек-машина, мышкоклавиатурновизуальный
задачи у веб-приложений и десктоп-приложений одинаковые, просто сегодня еще есть это разделение из-за несовершенства технологий, а завтра его уже не будет
>> Пока не появится машины которая будет выполнять функциональный язык на уровне железа будет всегда наблюдаться преобразование функционал в императив.
такого железа никогда не появится, потому что машина Тьюринга это наиболее близкая к реальности абстракция
>> Но вот количество затраченных ресусров может сильно различаться для разных задач.
именно это я и сказал FRP проще в функциональном языке
а учитывая то, что FRP проще "императивной интерактивности" следует то, что программировать GUI в функциональных языках проще
спама на хабре хватает, а это статья, которая полезна людям, разрабатывающим распределенные приложения (скалируемый server-side, например, в контексте веба)
>> второй - нет результата.
почему же, есть результат посмотрите на кол-во комментов к статье, куча народу сегодня узнали про Erlang
>> Уберите рекламные обороты и текст сократится в 3 раза, а то и больше.
и что от статьи останется? "есть вот такая штука Erlang, да, вот такие-то цифры показывают то-то", очень интересная статья
а главное, что тогда задачи своей она не выполнит не вызовет интереса
не вижу никакого криминала, кстати, в преобразовании declarative -> imperative, декларативный код сам по себе святым духом исполняться не будет ведь
а FRP возможен в любом языке, хоть в C
функциональное/декларативное программирование не привязано к языку, просто в языке, который на семантическом и синтаксическом уровне поддерживает такой стиль это делать проще, только и всего
к примеру, в .NET всё это дело прекрасно живет в среде императивного C#, просто из-за негибкости языка пришлось сделать доп. декларативную прослойку в виде XAML, в случае Haskell или Erlang этого делать бы не пришлось
а каков синтаксис языка для передачи сообщений это тема для другой статьи
вам что, надо Hello World но в терминах message-passing? классический пример "ping-pong" или thread ring? вы потратите куда больше времени, чем 5 минут на то, чтобы разобрать такой код на незнакомом языке, а практическая ценность такого кода не больше, чем "вычислить площадь с pattern matching"
хотите "реальных примеров" скачайте ejabberd в исходниках
в этом и заключается задача статьи
просто раньше об этом как-то никто не задумывался
>> восторженное эссе маркетолога ниочем
не "ни о чём", а про Erlang
без рекламы вы бы про Erlang вообще не услышали