Комментарии 49
Положительные стороныто есть считает и Erlang и LISP — «зашкваренными».
В первую очередь, конечно же чистота языка. Чистота в обоих смыслах: чистота функций и полное отсутствие ООП-парадигмы. Это очень здорово...
Что может быть чище AST? То есть, если мы говорим о семантической чистоте — то Haskell рядом не валялся с LISPом. А если о полном отсутствии ООП-парадигмы (не уверен, что я понимаю, что кроется за этими очень нынче модными словами, но в любом случае) — то Haskell рядом не валялся с Erlang’ом.
Или я ошибаюсь?
Это поведение можно безопасно расширить в пользовательскую сторону — мемоизация чистых функций безопасна по определению.
Стало быть, остается «чистое — отдельно» ну и «lazyness», конечно.
Вот теперь у меня есть вопрос, который я всегда задавал и всегда мне отвечали конструктивными минусами вместо слов. Задам еще раз :)
Вот берем, скажем, эрланг и программиста уровня «умнее стиральной машины „Bosch“». И он нам пишет вотсап. Потому что виртуальная машина и «умри, если споткнулся» — распараллеливается ничуть не хуже. Да, компилятор по рукам не надает, но люди еще со времен ассемблера как-то более-менее научились с этим справляться. Я обычно понимаю, где у меня чистая функция, а где — не очень. Более того, я все нечистое запущу сбоку и оно мне мое чистое не испортит.
Что именно я упускаю из того, что делает вот эту «абсолютную чистоту» такой киллер фичей? Только, если это возможно, очень прошу — без примеров из вычислительной математики (здесь никто и не спорит) и абстрактных тезисов (типа «чистый лучше, чем нечистый»).
Все это абстрактный спор, далекий от практики программирования.
А фильтры спама в Фейсбуке с таким-же успехом реализуются на любом другом языке.
Про статическую типизацию я умею спорить аргументированно. Здесь я в предмете плаваю, потому и спрашиваю. Вот случайный комментарий рядом: «Haskell в этом смысле чистый, Erlang и Lisp — нет». Внимание, вопрос: и чё? Не то, чтобы даже «почему это зорошо?», нет. «Почему на этом имеет смысл заострять внимание?».
Тем более, что мы выше разобрались с IO монадой, это уже как бы не совсем так.
В том же эрланге ничего не мешает запихать функцию, рассылающую сообщения, в lists:map/2 вместо lists:foreach/2. Оно конечно будет работать, но порядок вычислений однажды может начать давать какие-нибудь интересные побочные эффекты. А в хаскелле компилятор сразу ткнет носом в то, что похоже написано не то, что хотелось написать. Оно может и непрактично порой, но как идеализированная концепция привлекательно.
Вот. Спасибо. Вот те слова, которых мне не хватало: «идеализированная концепция». Я без иронии вовсе. Я действительно просто нуждался в словах «это идеальная сфера, на которой очень удобно оттачивать наши знания о геометрии и ньютоновской механике, — гораздо удобнее, чем на футбольном мяче».
Я бы даже сказал, «чистая, типа „идеализированная“ концепция» :)
Могу назвать преимущества на уровне компилятора. В частности, на функциях без побочных эффектов хорошо работают оптимизаторы. Поскольку в функциональных языках переменных как таковых нет, а все значения являются read only, то отпадает большое количество ограничений, которые компилятор обычно вынужден накладывать и учитывать.
Работа с памятью оказывается существенно проще, хвостовая рекурсия выполняется на раз. Алиас анализ делать существенно проще, поскольку пользовательские значения гарантировано не алиасятся, а это приводит к меньшим накладным расходам ввиду меньшего количества обращений в память. Раскладка значений по регистрам может быть выполнена более точно и т. д.
Это вы сейчас прямо как из рекламной брошюры по OTP кусками скопипастили :)
Я понимаю же, какие плюсы у stateless вообще (там, где stateless уместен, но «уместность» — это опять на похоливарить, так что замнем, тут это ни при чем вовсе).
Я не понимал, чем эрланг хуже. У меня просто складывалось такое ощущение, что haskell — про «а давайте все запретим, чтобы дебил-программист не отстрелил себе ногу», как golang. С появлением в дискуссии слова «академический» все встало на свои места. Это действительно идеальный язык для академического моделирования (whatever it means); тут очень заметно, что эрланг разрабатывался бизнесом, а хаскел — наукой.
Потому что в чертовом бизнесе завтра обязательно надо будет вот это на лету подменить перед складыванием в хранилище, или же развести красивого отложенного кода вокруг на пару тысяч строк.
Я вообще не понимаю разговоров вида X лучше/хуже Y. Больше всего воплей обычно от людей, которые ни того ни другого обычно и в глаза не видели, но зато «точно знают» что лучше.
Про дебилов программистов точно не по адресу — действительно, хаскель является академическим языком, но цели у него скорее философско-исследовательские чем индустриальные. Что впрочем не мешает применять его там, где он оказывается действительно удобен.
Лично я и изучал и эрланг и хаскель, но не собираюсь делать никаких однозначных выводов в пользу того или другого. Все зависит от задачи.
У меня просто складывалось такое ощущение, что haskell — про «а давайте все запретим, чтобы дебил-программист не отстрелил себе ногу»
Вот вы хитрите. Как будто Эрланг не про это :) Покажите Эрланг тому же лисперу. Он тоже пожалуется на ограничения — иммутабельность данных, единичные присваивания и падение процесса при сфейлившимся паттерн-матчинге.
Хаскель развивает идею «мощь в ограничениях» дальше, предлагая статическую типизацию и элегантное отделение чистого кода от кода с побочными эффектами. Но он никак не запрещает все, иначе невозможно было бы взаимодействие с нашим императивным миром.
Ограничения в Эрланге и Хаскеле нужны для помощи программисту. Это не значит, что их используют инвалиды ума. Просто человек существо такое — совсем не косячить он не может.
Кстати, а чего мы все про Эрланг? Да это крутой нишевый инструмент, но не более. Телеком, работа с сетью его конек. Написание же на нем вещей типа Wings 3D будет малоинтересным занятием.
Я бы сказал бы, что Erlang разрабатывался инженерами для решения своих задач. На эту тему очень интересна дискуссия: Joe Armstrong and Simon Peyton Jones discuss Erlang and Haskell
никак нельзя контролировать объём потребляемой памяти
Я вроде видел хаки на эту тему, не могу отыскать ссылку, к сожалению. Типа, как доползли до N гигов памяти — щелкаем по доминошке. Но история про «все мемоизовал, сожрал всю память и закуклился» очень смешная, конечно. В хорошем смысле: это же еще одно явное указание на академическую природу языка.
Хотя… Для правоверных функциональщиков, '!' может являться признаком ООП ереси.
полное отсутствие ООП-парадигмы
Есть мнение, что автор «ниасилил» ООП.
Lisp — на 31, 1958г
Scheme — 34, 1975г
Scala — 32, 2003г.
Видим, что два языка, появившиеся раньше, являются и более популярными. Как-то это не очень согласуется с термином «общепринятый стандарт». Вот было бы просто «История и перспективы....» и вопросов бы не было. В других двух упомянутых рейтингах относительные позиции у Haskell лучше, но всё же пафос так мешает…
ps: и вообще перспективы так описаны, что действительно пессимизм в отношении Haskell возникают…
Видим, что два языка, появившиеся раньше, являются и более популярными.
Ну так Haskell — "чисто функциональный", а другие два языка — нет.
Опять же, некая часть популярности Scala берётся от JVM платформы. В языке намешано всё что угодно и нередко предполагается (поначалу) "писать как на джаве". Не пытаюсь доказать, что Scala "недостаточно функциональна", но не уверен, что (очень) мультипарадигменные языки могут быть "стандартом" в чём-то одном.
Собственно, не удивлюсь, если Clojure популярнее чем Common Lisp. А в рейтинге TIOBE вообще некий "обобщённый" лисп присутствует: вполне возможно, что туда всё лиспо-подобное попало.
2. А точно стал? Как это определяется?
3. И в конце концов, что такое стандарт функционального программирования? «Язык считается стандартом функционального программирования если находится на 38 позиции в индексе TIOBE»?
Не очень хорошая формулировка. Я бы сказал, что он «де-факто он самый популярный» и то Ocaml сейчас, вроде бы, быстрее набирает популярность
Очень многие туториалы по функциональному программированию используют именно Haskell для иллюстрации примеров, даже в статьях по другим функциональным языкам типа Scala бывает.
От создателя Haskell
Curry — встраиваемый язык программирования общего назначения, реализованный поверх языка Haskell
Чем докажете? Вроде бы Curry делали совсем другие люди, нежели Haskell.
Вообще, статья донельзя обзорная и короткая. Писали чисто ради денюжки?
А Scheme — динамически типизированный язык, как и большинство Lisp-ов.
Статья довольно интересная, хотелось бы прокомментировать Козлова в конце.
В то время как с самими выводами о плюсах и минусах хаскеля я согласен, аргументация местами довольно странная. Возможно, дело в неточности формулировок.
Нет ООП поэтому нет проблем с приведениями
ничего не мешает сделать ООП-язык и запретить в нём downcasting на уровне компилятора. Сила типов хаскеля не в «отсутствии ООП».
Например, нельзя перепутать применение функции и ссылку на функцию, как в Scala, так как в Haskell функции являются объектами первого класса.
Л — логика. На самом деле проблема с предпосылками. В Scala функции также являются объектами первого класса.
В Хаскеле нет проблем с перепутыванием потому, что ленивые вычисления и функция сама вызовется в рантайме когда надо. В коде она всегда в одном виде — как ссылка.
В первую очередь, конечно же чистота языка. Чистота в обоих смыслах: чистота функций и полное отсутствие ООП-парадигмы.
Свойство языка, без которого разговор о Haskell был бы бессмысленным – это полиморфизм.
Подскажите плиз, как полиморфизм может быть без ООП?
История языков программирования: как Haskell стал стандартом функционального программирования