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

Мой критерий оценки: большие затраты на понимание кода не окупаются сокращением времени на его написание. Грубо говоря, не каждый поймёт чужой или даже свой собственный код через полгода будь он написан на С++, а если речь о функциональном ЯП....   

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

Будущее за ML-языками или нет ???

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

Да-да, питон... Насчёт питона хотел отдельно тут сказать, но ты опередил: смешанные ЯП не рассматриваем, речь о парадигме программирования (функциональные vs. остальные). Питон будем считать коллаборационистом-шпионом в обоих лагерях 

О какая тема 
Функциональщина в нынешнем виде в массы не пойдёт из-за описанных симптомов мозгового взрыва.
С другой стороны, в следующей версии Visual Studio мы увидим среди основных языков F#, который более походит всё же на OCaml, нежели на C#. Думаю, тогда в сравнительно короткие сроки он побьёт по популярности OCaml и выйдет куда-нибудь во второй-третий десяток рейтинга TIOBE.
Непонятно так же, какие подходы станут мейнстримными в «борьбе» с многоядерностью: Erlang-style, STM, что-то ещё.
В конечном итоге, думаю, востребован открытый ум, готовый ко всяким инновациям.

зря. будущее за ними. Да и настоящее уже тоже

Добавлено через 23 секунды
не голосовал, пожалйста.

Если добавить ещё один вариант в голосование, ясное дело кто победит. Поэтому умышленно его пропустил.   

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

Аналогично! Только причина "поломки" - Haskell.


Как что, так сразу Python! В C# 3.0 тоже появились некоторые идеи из ФП.  


В качестве что-то ещё: Smalltalk + разрешить объекту продолжать свои действия после посылки сообщения и после отправки ответа. 
ConcurentSmalltalk.

Это сообщение отредактировал(а) kemiisto - 4.8.2008, 18:40

серебряной пули нет

А когда "въедешь", будешь говорить - просто, просто   

Я пытался, пытался - и забил. Сейчас нет, нет, да загляну в Foundations of F#. Там как то попонятней, чем в той книге по которой я "ломал" мозг с помощью Haskell.

Душкин ?       
ИМХО крайне неудачная книга

советую обратить пристальное внимание на CL, по нему есть оч. хорошая литература.

  Как Вы угадали?


CL = Common Lisp? 
Aristotelb, а можно ссылочки на хорошую литературу? 
По ФП листал (кроме уже упомянутого Душкина и Robert Pickering):

• Harold Abelson and Gerald Jay Sussman with Julie Sussman - Structure and Interpretation of Computer Programs в русском переводе. ЯП = Scheme, тяжеловато идёт.
• John Harrison - Введение в функциональное программирование.  

В итоге всё сводится к непониманию исчисления лямбда конверсий (или как его там правильно). По сему два вопроса:

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

на сколько я знаю она единственная по Haskell на русском языке.

по Common Lisp:

"Мир лиспа" Хювяннен и Сеппянен (1990 г) книга хоть и старая, но очень основательная и доступная для понимания (есть в эл. виде)

Practical Common Lisp посовременнее и есть неплохое описание объектной модели CLOS

ну это классика

P.S можно на ты.

Очень даже.


Желательно... и развитое логическое мышление приветствуется. Но научиться можно всему.

Итак, Haskell. Если есть базовое знание английского - рекомендую Yet Another Haskell Tutorial. Чтение несложное, в конце каждой главы есть практические задания (с решениями на случай полного невтупления; здорово просветляют). Осторожно, там почти мегабайтная пэдээфка, не тыкайте ссылку при нехватке трафика.

Aristotelb, Shaggie спасибо за ссылки. Посмотрю - отпишусь как дело пойдёт. 

Ну что ж так тема заглохла?! Я тут, понимаете ли, жду мегакода на хаскеле, эрленге и пр. Скучно :(

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

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

Void, ну покажи пример, а ?...   

mr.DUDA, дык, какой? Микропримеры на 10 строчек в контексте темы не катят, а что-нибудь реальное поди напиши. Могу только ссылками покидаться в ответ на провокации 

А почему против? Как по мне - так питон сочетает их. Его и юзаю )

 Потому что он очень яркий.
Ну сам посуди:
Область применения - от десктопного гуевого софта и серверных приложений до игр и софта под мобилы.
Куча библиотек, многие нереально мощные. Twisted, PyQt4, Django.
Выразительность языка и очень богатые языковые возможности.
Вот поэтому и приводят его в пример )

Void, ну приведи какой-нибудь коронный пример парсера...   

haskell интересный язык, изучение его будет очень полезным.
Меня сейчас в свете semantic web больше интересует другая ветвь декларативного программирования - логическое, и базы знаний. Изучаю RDF и OWL, благо эти вещи, еще вчера казавшиеся игрушками, получили серьезную поддержку в Oracle 11g. Там реализована поддержка семантической сети, причем реализована как говорится эффективно и масштабируемо. Правда SPARQL в 11ой версии не реализован, но его обещают в будущем, а пока можно использовать инструменты от третьих фирм, для которых oracle будет идти бекэндом (в качестве rdf-store).

Посмотри на haskell.org, там есть примеры использования parsec. Только не зная haskell все равно их не поймешь. Насколько я понял, тебе интересно, стоит ли тратить время на изучение ФП? Определенно стоит, даже если использовать фя не будешь. Собственно, есть три основных способа описания вычислительного процесса, и желательно представлять их себе хотя бы приблизительно.

1. Традиционная машинка Тьюринга - с этим понятно
2. Лямбда-исчисление (ФП)
3. Мат. логика, предикаты первого порядка (логическое программирование).

Для изучения второго оптимален haskell, но пойдет и ocaml, для третьего - prolog, но можно сразу взять RDF/OWL, так как это ближе к практике.

а в системном программировании ФЯ применить можно? 

допустим реализовать функцию int GetModuleHandle("xxxx")

императивный алгоритм такой:
1) получить указатель на структуру PEB из FS:[0x30]
2) пройтись по цепочке указателей в структурах до связанного списка структур описывающих загруженные модули
3) поиском по этому связанному списку найти структуру нужного модуля
4) взять в этой структуре искомый хендл

И в чем вопрос? 
  Можно ли на ФЯ реализовать подобный алгоритм? - Да можно.
  Имеет ли смысл? - Нет не имеет.

LSD, т.е. исходник для этого алгоритма на ФЯ будет на порядок длиннее чем на С++, 
и код на ФЯ будет написан с использованием разнообразных хаков, не свойственных обычным программам на ФЯ ?

GoldFinch, ФЯ применить можно, только ФП в этом будет маловато.
Любой функциональный язык имеет нетривиальный рантайм, прежде всего, сборщик мусора. Следовательно, обращения к памяти, не находящейся под его управлением, должны быть обставлены церемониями с FFI.
В Haskell, навскидку, через Foreign можно сделать всё описанное, кроме первого шага, который придётся вынести во внешнюю библиотечку из одной функции. Но никаких особенных преимуществ перед кодом на Си не будет: ноги отстреливаются с той же лёгкостью, а синтаксис довольно многословен. Не для микроскопа гвоздь выходит.

давайте что-нибудь напишем, на ФЯ и сравним с обычным ЯП  

Lazin, я тольк что предложил алгоритм, вот его и напиши на ФЯ

если ты это имел ввиду

то он будет выглядеть так-же, да и не серьезно это как-то)
я имел ввиду что-то более серьезное, например реализовать какой-нибудь алгоритм на графе, поиск кратчайшего пути например
то, что на haskell/ocaml/erlang нет смысла писать системные приложения это всем и так понятно

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

А почему, собственно, нет. Haskell — неплохой императивный язык 
GoldFinch, у меня нет GHC на Windows, так что код я не проверял и вполне мог не всё понять правильно из MSDN, но для иллюстрации пойдёт (здесь с подсветкой):

Если всерьёз понадобится много тягать внешние структуры из Haskell, можно соорудить библиотечку EDSL, сделать deriving Storable на Template Haskell и т.д.

Предлагаю реализовать на чём угодно вторую задачу из конкурса дельфистов, на многопоточное программирование. Визуализацию можно консольную, но с GUI будет идеально. С меня решение на Haskell. Холивар? 

Это сообщение отредактировал(а) Void - 27.3.2009, 20:00

хорошая идея)

Добавлено через 11 минут и 53 секунды

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

Просто реализовать описанное асинхронное поведение.
Вот это условие:

мы переформулируем, чтобы не заострять внимание на деталях реализации:

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

Lazin, нет, задачка чисто техническая. В оригинале предлагалось минимизировать блокировки, ну а нам надо бы показать, что есть весёлого в ФЯ на тему параллелизма 

Придётся первому, значит 

Сразу решил делать что-то вроде актёров: два потока, хулиган и дворник, отсылают через асинхронную очередь сообщения третьему, который хранит состояние поля и обновляет его в соответствии с полученными данными. Очередь на основе STM уже в стандартной библиотеке. Актёр крутится в бесконечном цикле, при этом его состояние хранится в монаде State.
Визуализацию сделал на Gtk2Hs и Cairo. Скриншот в аттаче. Поскольку GTK не потокобезопасен, получилось четыре потока: добавился главный поток GUI, в контексте которого можно выполнить действие с помощью библиотечной функции postGUIAsync.

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

Тестировал на Linux с GHC 6.10.1 и Gtk2Hs 0.10.0. На 6.8.* не скомпилируется из-за изменений в системе исключений, а с 6.10 работает Gtk2Hs не ранее 0.10, так что свободы выбора особо нет. Собирать с -threaded, конечно же.
с подсветкой



Это сообщение отредактировал(а) Void - 2.4.2009, 00:27

Присоединённый файл ( Кол-во скачиваний: 21 )
 hooligan.png 6,61 Kb

Прошу не считать меня невеждой, но в обсуждении я так и не нашел хотя бы краткого перечня задач, для которого программирование на функциональных языках будет по каким-то причинам предпочтительнее, чем на традиционных.
Я ни разу не писал код на Haskell или Ocaml (использовал Python одно время для инженерных расчетов), но из обсуждения непонятно есть ли перспектива изучения подобных языков и в каких областях. Как коррелируется изучение этого класса ЯП с применением в различных практических областях?
Прошу внести ясность, если кто-то может.

Это сообщение отредактировал(а) Unlocker - 2.4.2009, 09:56

Будущее за классикой, ибо она - золотая середина вся.

Unlocker, во-первых, не обязательно противопоставлять ФП привычному структурному и ОО-подходу. Они вполне могут сочетаться, и тому есть хорошие примеры: F#, Scala.
Трудно сразу показать на практическом примере преимущества ФП. Обычно следуют такие возражения:
1. Это непонятно. Пусть при императивном подходе будет больше кода, но я его быстрее напишу и другие быстрее поймут.
2. Как следствие из предыдущего: где найти программистов, которые будут это поддерживать и кто мне позволит использовать ФЯ на работе?
3. Это неэффективно и будет тормозить.
4. Для ФЯ нет инфраструктуры: библиотек и сред разработки.
Всё это в какой-то мере справедливо. Глупо выдавать ФП за серебряную пулю, но перечисленного недостаточно, чтобы закрыть на него глаза.
ФП, как и любое новшество, требует времени на обучение. Нет никаких доказательств того, что ФП фундаментально сложнее. Напротив, оно ориентировано на работу от базовых принципов, а не перечисление неформальных особенностей поведения. ФП благосклонно к более формальному подходу, но отнюдь не требует зубодробительной математики. Неоднократно слышал, как программист, поставленный перед необходимостью использования ФЯ на работе (да, бывает и такое), в минимальные сроки разбирался и начинал писать код — не больше проблем, чем с очередным фреймворком (пруфлинк, первый попавшийся).
Гибридные языки вроде F# позволяют сохранить привычную компонентную структуру на высоком уровне и в то же время получить в распоряжение набор новых инструментов для создания программной логики уровнем ниже. Возьму на себя смелость утверждать, что подход, основанный на композиции чистых функций над неизменяемыми структурами данных, проще, легче поддерживается и менее подвержен ошибкам.
Тем, кто работает на платформе .NET, однозначно надо попробовать F#. Microsoft тянет его в мейнстрим и одновременно обогащает C# ФП-возможностями. Заодно отпадает вопрос об IDE и библиотеках.
Другое направление, в виде Haskell, стремится развить как можно более строгую систему типов со статическими проверками. Здесь сложнее обещать немедленный эффект, но на мой взгляд стоит хотя бы попробовать, что такое отделение чистых функций на уровне типов, классы типов, всеобщая ленивость и т.д.

Задачку никто больше решать не будет? Erlang бы взял кто-нибудь, хоть с консолью, хоть с gs.
А код на Haskell комментировать? Хотя бы в духе «это хуже чем Perl» :-)

дык оно-же не работает с моим ghc, нужно скачивать 6.10

будет  

написал то-же самое на с++, но без GUI, все выводится в консоль, всего есть 3 потока, один для хулигана, один для дворника и основной поток, первые два потока отправляют основному потоку свое состояние через очередь(порт завершения), основной поток выступает в роли брокера, и вычисляет общее состояние

300 строк, почти в 2 раза больше чем у Void

Добавлено через 3 минуты и 55 секунд
ps
winsows only

не очень понятна фраза "Дворник бегает от края до края поля за раз сметая 3 бумажки (очищая 3 соседние ячейки) в течении 400мс."

GoldFinch, это значит что область в три клетки каждые 400 мс смещается на одну клетку, «отражаясь» от краёв поля.

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



С подсветкой

Это сообщение отредактировал(а) fixxer - 23.4.2009, 17:38

Void, fixxer, а теперь собственно хотелось бы услышать, где же тут преимущества. Кроме alien-look кода, я ничего не увидел.

Блин. Как обидно, что почти все умные мысли уже оформлены в слова... И не тобой.  

Ещё подумалось, что неспроста же машины императивны. Ведь создавали же мы(?)  их по собственному образу и подобию. Точнее, по нашим собственным представлениям о нас самих, о природе нашего мыслительного процесса. А он, походу (в смысле, мне так думается), императивен. Это не классический процедурный императив, но ООП - как раз то, что надо! Окружающий нас мир, состоящий из объектов, характеризуется неким состоянием. Да и у самих объектов состояние имеется. И мы на них воздействуем посылая сообщения и тем самым их состояние изменяя.

Так что ФП, по моему скромному мнению, не более чем ещё одна неудачная идея, неожиданно начинающая приобретать популярность. Цепь событий, примерно, понятна. Умные дяденьки-тётеньки, закончивышие всяческие Гарварды-Оксфорды, хотять получать побольше денежек и идут работать в различные R&D (пусть же будет это, для примеру, Microsoft Research). Дабы поразить работодателя и будучу людьми не глупыми, понимающими на чём мир стоит, эти дяденьки-тётеньки рассказывают про ФП. Что за зверь такой, работодателю не ведемо... Но разве это главное... "Функциональное говорите? Красиво звучит! Математики придумали? Ай хорошо! Экий фантик будет! Давьненько у нас ничего принципиально новенького не было..." - сказал манагер из MS и пошло-поехало... Далее всё и так понятно...

Фаньтик... Фаньтик и не более того... Вот такое впечатление...

Это сообщение отредактировал(а) kemiisto - 26.4.2009, 16:25

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


Их создавали практики, а функциональные языки - теоретики, каждый для себя  

По поводу «объектности мышления» у dz как раз недавно баталии разворачивались. Это палка о двух концах. ФПшники скорее предлагают выводить ООП из некоторой математической базы, как безусловно полезную в некоторых случаях концепцию, а не брать за основу всего и вся.
Сторонников ФП часто обвиняют в религиозном рвении, но на мой взгляд попытки причесать программную индустрию и тем более человеческое мышление под Истинный Объектный Путь (и пророк его Java/Oberon/подставьте по вкусу) куда более религиозны по сути. Не в пику их практической эффективности: в религиозном «фреймворке» люди работают уже тысячи лет, массово, надёжно. Но по некоторым вопросам мозги рекомендуется отключить и на полочку, во избежание.
Чем по тысячному разу перемывать... вот человек хорошо сказал (не далее как вчера, хех): ЯПомерам посвящается.

Ну да, ну да...  


Я что-то невижу пока, чтоб кто-то всерьёз этим занимался. Это раз. А два... nickless, не в обиду, но я как бы эти лозунги не первый раз слышу. Начитаются в интернетах и давай декламировать...


Опять же - просто слова. Не вижу я простоты создания компиляторов! И её быть не может. Ты по ссылке ходил в моём сообщении. Ежу же понятно, что если железка императивна, то и легче реаоизовать соотв. ЯП.


Вот откуда ветер дует.  Значит не в интернетах начитался, а у профессоров наслушался... Ну, профессоров то много... Кстати, утали моё любопытство, что за университет?


Вот я (точнее Вирт  ) как раз об этом...

Void, приведённая тобой цитата согласуется с твоей же подписью.  

Оно, конечно, да. Но жизнь, штука, короткая.  Я это уже понял... За двумя зайцами погонишься - от обоих ... получишь! К тому же, мне кажется изучать ФП вообще и, по крайней мере, в нашем веке - разбрасоваться по мелочам.

И вот ещё что... Это что-то навроде доверять или проверять? Всё проверять, повторюсь, времени не хватить. А вот кому доверять, каждый выбирает сам. Я выбрал, и мнение этого человека привёл. Это не моё мнение, но мнение, которому я доверяю...

А ты интересовался? Или всерьёз — это когда в Visual Studio 20xx добавили кнопку «Proof correctness» или, на худой конец, в ETH Zurich заинтересовались? Системы типов именно для верификации и создаются.

Ну вот и не изучай, заставляют тебя что ли :-)
При наличии фактов успешного коммерческого применения ФЯ, пусть и немногочисленных, делать столь глобальные выводы мне кажется как минимум поспешным.

«Изучение бесконечности требует бесконечного времени. Поэтому работай, не работай — всё едино!»

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

Нет.


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


Неа!  Слепая вера != заслуженное доверие.

я ходил, и я бы не верил слепо тому, что там написано
к примеру там есть один забавный перл, о том, что Prolog - единственный логический ЯП
либо вот это:
 
За то, что у ФП больше будущее говорит хотя-бы то, что единственная нормальная реализация composed transactional memory есть в haskell. Программисты на c#, pascall итд о таком и мечтать пока не могут.  


фи...  

Ну.. В своё время, говорили, что за ООП будущее. Однако, наиболее успешны сегодня гибридные языки. ИМХО тоже касается и ФП. Какие-то концепции в том же шарпе или питоне активно используются уже сегодня. Но вот полного перехода на ФП-шные языки, я думаю, не будет.

Почему перл? Классификации однозначной нет. Некоторые даже Пролог не относят к логическим ЯП.


Я не знаю, что такое composed transactional memory. А Вирт, скорее всего, имел ввиду Active Oberon и ОС Bluebottle.


Что фи?

Ну так сравни мои 60 строк с 300 на C++, в которых почти половина инфраструктурного кода и синтаксических приседаний. На Erlang оверхеда почти нет. Учится он за два вечера под пиво, прост как валенок. Из фишек ФП которые у меня были использованы:
- нет состояния. вообще нет переменных, только формальные параметры функций. (F не считается можно обойтись и без нее).
- функции высшего порядка
- анонимные функции
- хвостовая рекурсия
- паттерн матчинг, очень мощная вещь
- ну и главная фишка Erlang'а: потоки и сообщения.

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

Добавлено через 11 минут и 20 секунд

По поводу "фантиков". Да вся история развития программирования заключается в формулировании этих самых "фантиков". А именно формирование способов представления абстракций как элемента борьбы со сложностью. С объективной сложностью, кстати. Как говорил Абельсон в своих лекциях, при изучении нового языка вас должны волновать лишь две вещи: means of abstraction и means of combination. 

Ну, во-первых, C++. А, во-вторых, и что? Ну у тебя меньше. Но, то, что Lazin написал я хоть понял...

Эх, блин, ещё раз цитирую сами знаете кого:


Итак, если коротко. Существует достаточно строгая (в математическом плане) теория императивного программирования. Хоар, Дейкстра, Вирт, наша новосибирская школа. НО! О ней мало кто знает. А вот об ФП (особенно в русскоязычном комьюнити) трубят как о единственной начной, математически обоснованной, и ко всему прочему ещё и единственной идеально подходящей для параллельных вычислений, концепции. Оно и понятно, рухнул железный занавес люди получили доступ к заруюежной литературе. Что читать? Конечно же американскую! Они там все такие вумные, богатые. А у них там бум ФП. Вот собственно и фсё! А про европейскую то школу императивного программирования никто и не вспомнит... И про нашу, новосибирскую, тоже. А зачем? Ведь в ФП же так много

  

Это сообщение отредактировал(а) kemiisto - 27.4.2009, 13:10

Объясни одну вещь, а при чём тут ты? 
Только не надо на голубом глазу заявлять, что код на C++ можно прочитать, не зная C++.
«Язык плох, потому что его мало кто знает. А поскольку он плох, его никто не будет учить. Единственный способ стать популярным — это быть популярным. Ваши каракули нечитаемы, потому что мы привыкли читать другие каракули».
Таким образом можно поставить под сомнение перспективы широкого распространения ФП (а здесь вроде никто не обещает миллион программирующих на Хаскеле к концу пятилетки), но все остальные выводы — демагогия чистой воды.

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

Я только за себя отвечать могу. Это такой нескрываемый искренний эгоизм! А кто исчо то? Тут жеж нет никог...  И к тому же:

  


Угу, конечно...  Как что супротив ФП, так сразу демагогия. А вот где демагогия чистой воды, так это мы, какбе, не замечаем:



Гы!  Тебе нравиццо!?


Не, не, не! Ты меня с кем-то путаешь. Я таким не занимаюсь. Воспринимай моё прибывание на форуме (и в этом топике в т.ч.) как попытку донести ещё одну точку зрения. Не в пику другой. Просто для сохранения равновесия.  

Это сообщение отредактировал(а) kemiisto - 27.4.2009, 14:26

напиши это на паскале, посмотрим что лучше  
Лично мне нравится смешанный подход, к примеру реализация lazy evalation в python, можно писать чисто в ФП стиле используя generator expressions и itertools, а можно это дело смешивать с генераторами, написанными в традиционном, императивном стиле используя кл.слово yield, или алгоритмы STL, в сочетании с биндами из библиотеки boost и прочей функциональщиной.  

Ситуация: ты Эрланг не знаешь, и для себя решил, что изучения он не стоит. Хорошо, твоё право. На C++ ты плюёшься, но пишешь. Тоже запретить нельзя. А потом заявляешь: «код на Эрланге ерунда, потому что код на C++ я хотя бы прочитать могу». Блаб-синдром? По-моему, да.

В данном топике твоя точка зрения сводится к: «Я этого не знаю. Поэтому оно фигня. И нас таких миллион! Значит точно фигня». В такой ситуации у нас нет базиса для спора.
Я же не против критики, и фанатизмом не страдаю. Но ты не привёл ни одного технического аргумента. А разборки на уровне кто кому прищемил и кого недооценил N-цать лет назад — это не просто неконструктивно, но даже для пофлеймить неинтересно.

Это сообщение отредактировал(а) Void - 27.4.2009, 15:57

Ну, тут скорее, "сходу" (интуитивно) так и не понял.


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


Это сообщение отредактировал(а) kemiisto - 27.4.2009, 16:29

цитата, которую ты привел, наверняка была сказана в бородатые 80-е годы, это уже давно не актуально, современное программирование все дальше и дальше от этого, и слава богу  
вот небольшая презентация, в которой какой-то чувак из Epic games рассуждает на тему следующего mainstream языка программирования
http://www.st.cs.uni-saarland.de/edu/semin...docs/sweeny.pdf
может и боян, но довольно интересный