Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 49
Не увидел источников: http://www.ibm.com/developerworks/ru/library/l-haskell/index.html
В русской транскрипции Шейнфинкеля все таки именуют Моисеем.
Автор придерживается точки зрения:
Положительные стороныто есть считает и Erlang и LISP — «зашкваренными».
В первую очередь, конечно же чистота языка. Чистота в обоих смыслах: чистота функций и полное отсутствие ООП-парадигмы. Это очень здорово...
Речь идет о той чистоте, которая означает отсутствие состояния. Т. е. когда результат функции зависит только от её аргументов.
Возможно. Но есть четкая граница между чистыми функциями и функциями с побочными эффектами, использующими монаду IO например.
Да, разумеется. Собственно, при сворачивании редекса, содержащего несколько вхождений чистых функций, Haskell вычисляет каждое значение только один раз, а в другие места его просто подставляет.
Это поведение можно безопасно расширить в пользовательскую сторону — мемоизация чистых функций безопасна по определению.
Это поведение можно безопасно расширить в пользовательскую сторону — мемоизация чистых функций безопасна по определению.
Да нет никакой киллер — фичи.
Все это абстрактный спор, далекий от практики программирования.
А фильтры спама в Фейсбуке с таким-же успехом реализуются на любом другом языке.
Все это абстрактный спор, далекий от практики программирования.
А фильтры спама в Фейсбуке с таким-же успехом реализуются на любом другом языке.
Гарантии? А так, звучит как «что делает вот эту статическую типизацию такой киллер фичей», при том, что каждый первый может привести пачку доводов и за, и против.
А почему бы и не обратить на это внимание при описании преимуществ? Ведь в нем действительно на чистоту (на самом деле на типы, но ладно) обращается особое внимание.
В том же эрланге ничего не мешает запихать функцию, рассылающую сообщения, в lists:map/2 вместо lists:foreach/2. Оно конечно будет работать, но порядок вычислений однажды может начать давать какие-нибудь интересные побочные эффекты. А в хаскелле компилятор сразу ткнет носом в то, что похоже написано не то, что хотелось написать. Оно может и непрактично порой, но как идеализированная концепция привлекательно.
В том же эрланге ничего не мешает запихать функцию, рассылающую сообщения, в lists:map/2 вместо lists:foreach/2. Оно конечно будет работать, но порядок вычислений однажды может начать давать какие-нибудь интересные побочные эффекты. А в хаскелле компилятор сразу ткнет носом в то, что похоже написано не то, что хотелось написать. Оно может и непрактично порой, но как идеализированная концепция привлекательно.
На самом деле не такой простой вопрос как кажется. Можно много холиварить на «прикладном» уровне, чем в основном и занимаются, но это скучно да и бессмысленно.
Могу назвать преимущества на уровне компилятора. В частности, на функциях без побочных эффектов хорошо работают оптимизаторы. Поскольку в функциональных языках переменных как таковых нет, а все значения являются read only, то отпадает большое количество ограничений, которые компилятор обычно вынужден накладывать и учитывать.
Работа с памятью оказывается существенно проще, хвостовая рекурсия выполняется на раз. Алиас анализ делать существенно проще, поскольку пользовательские значения гарантировано не алиасятся, а это приводит к меньшим накладным расходам ввиду меньшего количества обращений в память. Раскладка значений по регистрам может быть выполнена более точно и т. д.
Могу назвать преимущества на уровне компилятора. В частности, на функциях без побочных эффектов хорошо работают оптимизаторы. Поскольку в функциональных языках переменных как таковых нет, а все значения являются read only, то отпадает большое количество ограничений, которые компилятор обычно вынужден накладывать и учитывать.
Работа с памятью оказывается существенно проще, хвостовая рекурсия выполняется на раз. Алиас анализ делать существенно проще, поскольку пользовательские значения гарантировано не алиасятся, а это приводит к меньшим накладным расходам ввиду меньшего количества обращений в память. Раскладка значений по регистрам может быть выполнена более точно и т. д.
А что такое OTP? :) Понятия не имею, написал исходя из своего опыта разработки.
Я вообще не понимаю разговоров вида X лучше/хуже Y. Больше всего воплей обычно от людей, которые ни того ни другого обычно и в глаза не видели, но зато «точно знают» что лучше.
Про дебилов программистов точно не по адресу — действительно, хаскель является академическим языком, но цели у него скорее философско-исследовательские чем индустриальные. Что впрочем не мешает применять его там, где он оказывается действительно удобен.
Лично я и изучал и эрланг и хаскель, но не собираюсь делать никаких однозначных выводов в пользу того или другого. Все зависит от задачи.
Я вообще не понимаю разговоров вида X лучше/хуже Y. Больше всего воплей обычно от людей, которые ни того ни другого обычно и в глаза не видели, но зато «точно знают» что лучше.
Про дебилов программистов точно не по адресу — действительно, хаскель является академическим языком, но цели у него скорее философско-исследовательские чем индустриальные. Что впрочем не мешает применять его там, где он оказывается действительно удобен.
Лично я и изучал и эрланг и хаскель, но не собираюсь делать никаких однозначных выводов в пользу того или другого. Все зависит от задачи.
У меня просто складывалось такое ощущение, что haskell — про «а давайте все запретим, чтобы дебил-программист не отстрелил себе ногу»
Вот вы хитрите. Как будто Эрланг не про это :) Покажите Эрланг тому же лисперу. Он тоже пожалуется на ограничения — иммутабельность данных, единичные присваивания и падение процесса при сфейлившимся паттерн-матчинге.
Хаскель развивает идею «мощь в ограничениях» дальше, предлагая статическую типизацию и элегантное отделение чистого кода от кода с побочными эффектами. Но он никак не запрещает все, иначе невозможно было бы взаимодействие с нашим императивным миром.
Ограничения в Эрланге и Хаскеле нужны для помощи программисту. Это не значит, что их используют инвалиды ума. Просто человек существо такое — совсем не косячить он не может.
Кстати, а чего мы все про Эрланг? Да это крутой нишевый инструмент, но не более. Телеком, работа с сетью его конек. Написание же на нем вещей типа Wings 3D будет малоинтересным занятием.
Я бы сказал бы, что Erlang разрабатывался инженерами для решения своих задач. На эту тему очень интересна дискуссия: Joe Armstrong and Simon Peyton Jones discuss Erlang and Haskell
Чистота функций — в смысле отсутствие побочных эффектов. Haskell в этом смысле чистый, Erlang и Lisp — нет.
А где в Эрланге и в Лиспе ООП?
Хотя… Для правоверных функциональщиков, '!' может являться признаком ООП ереси.
Хотя… Для правоверных функциональщиков, '!' может являться признаком ООП ереси.
полное отсутствие ООП-парадигмы
Есть мнение, что автор «ниасилил» ООП.
Что-то звучит как реквием…
В индексе TIOBE Haskell находится на 38 месте (появился в 1990г), тогда как:
Lisp — на 31, 1958г
Scheme — 34, 1975г
Scala — 32, 2003г.
Видим, что два языка, появившиеся раньше, являются и более популярными. Как-то это не очень согласуется с термином «общепринятый стандарт». Вот было бы просто «История и перспективы....» и вопросов бы не было. В других двух упомянутых рейтингах относительные позиции у Haskell лучше, но всё же пафос так мешает…
ps: и вообще перспективы так описаны, что действительно пессимизм в отношении Haskell возникают…
Lisp — на 31, 1958г
Scheme — 34, 1975г
Scala — 32, 2003г.
Видим, что два языка, появившиеся раньше, являются и более популярными. Как-то это не очень согласуется с термином «общепринятый стандарт». Вот было бы просто «История и перспективы....» и вопросов бы не было. В других двух упомянутых рейтингах относительные позиции у Haskell лучше, но всё же пафос так мешает…
ps: и вообще перспективы так описаны, что действительно пессимизм в отношении Haskell возникают…
Потому что когда говорят, что всё будет прекрасно, но приводят слабые доводы, то мнение само собой склоняется в другую сторону. А караван пусть идет ))
Видим, что два языка, появившиеся раньше, являются и более популярными.
Ну так Haskell — "чисто функциональный", а другие два языка — нет.
Опять же, некая часть популярности Scala берётся от JVM платформы. В языке намешано всё что угодно и нередко предполагается (поначалу) "писать как на джаве". Не пытаюсь доказать, что Scala "недостаточно функциональна", но не уверен, что (очень) мультипарадигменные языки могут быть "стандартом" в чём-то одном.
Собственно, не удивлюсь, если Clojure популярнее чем Common Lisp. А в рейтинге TIOBE вообще некий "обобщённый" лисп присутствует: вполне возможно, что туда всё лиспо-подобное попало.
1. Ну так как он стал-то стандартом функционального программирования?
2. А точно стал? Как это определяется?
3. И в конце концов, что такое стандарт функционального программирования? «Язык считается стандартом функционального программирования если находится на 38 позиции в индексе TIOBE»?
2. А точно стал? Как это определяется?
3. И в конце концов, что такое стандарт функционального программирования? «Язык считается стандартом функционального программирования если находится на 38 позиции в индексе TIOBE»?
Не очень хорошая формулировка. Я бы сказал, что он «де-факто он самый популярный» и то Ocaml сейчас, вроде бы, быстрее набирает популярность
Очень многие туториалы по функциональному программированию используют именно Haskell для иллюстрации примеров, даже в статьях по другим функциональным языкам типа Scala бывает.
Ох. Не путайте тёплое с мягким. То что Хаскель проедставляет собой эталонный академический язык функционального программирования не имеет никакого отношения ни к его популярности, ни к его применимости в продакшене ни даже к количеству основанных на нём университетских курсов функционального программирования. Это означает только то, что «чистое функциональное программирование — это хаскель».
Лисп изначально основан на теории рекурсивных функций, а не на лямбда исчислении.
От создателя Haskell
Curry — встраиваемый язык программирования общего назначения, реализованный поверх языка Haskell
Чем докажете? Вроде бы Curry делали совсем другие люди, нежели Haskell.
Вообще, статья донельзя обзорная и короткая. Писали чисто ради денюжки?
APL все-таки имеет живых потомков — J и K.
А Scheme — динамически типизированный язык, как и большинство Lisp-ов.
А Scheme — динамически типизированный язык, как и большинство Lisp-ов.
Статья довольно интересная, хотелось бы прокомментировать Козлова в конце.
В то время как с самими выводами о плюсах и минусах хаскеля я согласен, аргументация местами довольно странная. Возможно, дело в неточности формулировок.
Нет ООП поэтому нет проблем с приведениями
ничего не мешает сделать ООП-язык и запретить в нём downcasting на уровне компилятора. Сила типов хаскеля не в «отсутствии ООП».
Например, нельзя перепутать применение функции и ссылку на функцию, как в Scala, так как в Haskell функции являются объектами первого класса.
Л — логика. На самом деле проблема с предпосылками. В Scala функции также являются объектами первого класса.
В Хаскеле нет проблем с перепутыванием потому, что ленивые вычисления и функция сама вызовется в рантайме когда надо. В коде она всегда в одном виде — как ссылка.
В первую очередь, конечно же чистота языка. Чистота в обоих смыслах: чистота функций и полное отсутствие ООП-парадигмы.
Свойство языка, без которого разговор о Haskell был бы бессмысленным – это полиморфизм.
Подскажите плиз, как полиморфизм может быть без ООП?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
История языков программирования: как Haskell стал стандартом функционального программирования