Обсуждение:Язык Haskell: О пользе и вреде лени

Hello from en!

I just wanted to wave a friendly hello from the English Haskell wikibook. Note that some of our images have been uploaded to commons:Category:Haskell so you should be able to use the directly in this book if you want. Also, we have a mailing list wikibook at haskell dot org, which might be of interest. No messages yet, but that will come. -- (Kowey) 152.81.9.218 08:24, 5 февраля 2007 (UTC)

Thanks! Our functional programming specialists seem to be away, though. Note also that this page is only a high school-level magazine article; we also have a course of undergraduate-level lectures and a few other articles in the functional programming category; they are all concerned with Haskell, of course. Ramir 09:01, 5 февраля 2007 (UTC)

Критика

В тах местах, где Haskell сравнивается с другими языками, статья составлена некомпетентно и предвзято. Начиная с примера, в котором для haskell использована сортировка с доп. памятью а для С - in-place(это я уже подправил) и заканчивая незнанием авторами других языков программирования, описанных в статье (из чего делаются выводы что те чего-то не могут). С чего вдруг в качестве противника Haskell выбран С, может лучше было assmebler для 8008 взять? Там вообще было-бы строк так под 200. Использованный пример показывает только то что в Haskell, в отличии от С, есть средсва работы со списками/массивами и возможности определять ф-ции "на месте". Обе они
в С не включены т.к. это НИЗКОУРОВНЕВЫЙ ЯЗЫК предназначенный для полного контроля того что происходит (и ,как следствие, для высокой скорости, малого потр. ресурсов, написания OS,etc). Для примера С-Like воспользуйтесь C++ + STL( + Boost, если хотите) и получите тот-же результат.

Почему не указаны отрицательные стороны? Скорость исполнения, наличие(точнее отсутствие) такого спектра библиотек как у С,С++,Paskal,Python, потребление памяти. Можно тут еще написать, но я думаю уже понятно что я хотел сказать. Жду неделю и правлю статью. 18.06.2007

Про скорость и потребление памяти я нашел, вычеркнул.

Здравствуйте и добро пожаловать в Викиучебник! Эта статья была написана преподавателем МФТИ по информатике Артёмом Викторовичем Ворожцовым и опубликована в журнале «Потенциал», и впоследствии шибко не изменялась. Прежде чем править статью, настоятельно советую связаться с автором — Участник:Greck и уточнить как свои собственные, так и его познания и соображения насчёт языков программирования. И ещё: пожалуйста, представьтесь. Ramir 23:10, 18 июня 2007 (UTC)

Хотя… можете, конечно, выправить статью, как Вам кажется нужным, и если замечания окажутся неверными, мы учтём это непонимание и допишем статью. Ведь статью должны верно понять и школьники. Ramir 23:50, 18 июня 2007 (UTC)

Будем считать что фраза про школьников ко мне не относилась.
Так сложилось на постсоветском пространстве что, как правило, преподаватели информатики(собирательное слово), в том числе в весьма уважаемых вузах (могу по МГУ судить, где учился), крайне слабо разбираются в практической применимости сколь-нибудь современных технологий, впрочем как и в их состоянии(а иногда и в старых то-же). Я вполне могу предположить что Артём Викторович Ворожцов к ним не относится, но само указание его должности никоим образом не делает выраженные им в статье мысли более правильными/компетентными (взять хотя-бы бывший вариант примера на С, автор даже попутал два варианта сортировки in-place и в дополнительной памяти).

Я, на всякий случай, укажу на правила википедии, а именно "Чем не является википедия", особо на разделы [1] и [2]. Викиучебник не википедия. Но являсь дочерним проэктом, и не имея своего свода правил, очевидно подпадает под действие большей части общих правил википедии.

Теперь собственно "по делу".

* Функциональное программирование позволяет реализовать давнюю мечту программистов:
«Я описываю, что мне нужно получить, а уж компьютер сам должен догадаться, как это сделать».

  
  Эта фраза не имеет никакого отношения к Haskell и к функциональному программированию вообще.
  Она из научно-фантастической саги про искуственный интелект. Картинка из той-же саги.
  Не один из существующих языков такого делать не умеет(ну разве что Пролог совсем чуть-чуть).
  
  В Haskell Вы точно так-же как и на assembler описываете ПОЛНУЮ последовательность действий
  необходимых для достижения результата. Все принципиальное отличие от императивных языков заключается 
  в том что у Вас отобрали переменные, а для борьбы с полученными в итоге проблемами выдали расширенные
  средства управления функциями. Всё. Остальные возможности Haskell не являются следствиями этой и успешно
  реализовываются имеперативными средствами других языков/трансляторов (например: ленивые вычисления, вывод типов,etc).
  Причем переменные никуда в итоге не делись. Просто вместо переменных у Вас функции, которые их по 
  запросу возвращают. 

• Ух, как тут много всего понаписали. Придётся отвечать. Многое подмечено верно (включая комментарии ниже). Но я писал образно и не совсем точно вполне сознательно, чтобы выработать правильные ассоциации. Я действительно считаю, что образ мышления программста на Haskel и других ФЯ сильно отличается от образа мышления программста на С++. И мне кажется, что данная фраза лучше всего подходит для того, чтобы дать читателю такую первую ассоциацию, которая будет первым шагом к пониманию, пусть даже она не точна. Я считаю, что допустимо писать не совсем верные утверждения -- точность утверждение приносится в жертву яркому запоминающему образу, который больше ориентирован на понимание сути, нежели на передачу эциклопедически точного определения. Это касается и всех остальных утверждений, которые вам не понравились. И еще я считаю, что "наукой [программированием, образованием, написанием статей, ...] не нужно заниматься со звериной яростью, это надо делать весело и красиво, иначе нечего в неё соваться" (c). Но в принципе, правьте, если действительно считаете, что это принесёт пользу. Под пользой я вижу --- большее количество школьников будет привлечено аннотацией/прочтёт статью до конца и многое извлечет/поймет суть. Я часто сталкиваюсь с ситуацией, когда человек вызубрил точное определение, но не знает сути. Лучше когда наоборот -- детали можно не знать, главное иметь в голове понимание и образы, которые могут работать на пользу мымли. Умение читать учебники и документацию восполнит незнание точных деталей. Длинные предложения с неизвестными терминами могут увеличить точность, но отдалить нас от целевой аудитории. Greck 20:14, 10 января 2008 (UTC)

• Артём, Ваше стремление разрешить непонятки у читателей — благородно. Но в случае, когда «критика» не направлена на улучшение собственно статьи и исходит от безликого анонима (при этом не содержит ссылок на авторитетные источники), — не чувствуйте себя обязанным на неё отвечать. Легче всего отвечать инструкцивно: «Представьтесь.» «Прочтите текст внимательнее.» «Прочтите литературу для 3-го курса.» «Используйте поисковую систему.» «Пейте рыбий жир.» Я вот даже люблю поёрничать над анонимами. «Пожалуйста, объясните подробнее.» «Не могли бы вы дать наглядный пример?» «Вовка, ты, что ли? Полтинник когда вернёшь?» Ramir 11:22, 11 января 2008 (UTC)

• Участник Ramir, я согласен с вами! В споре самое главное - личность. Если с вами говорит аноним, то его можно даже не слушать. Он говорит 2+2=4, и не предоставляет авторитетного источника? Гнать в шею! Спрашивать про полтинник. Мы, которые зарегистрированы в википедии больше года, правы по определению. И этот предпоаватель очень классно сделал, википедия как раз для того и есть чтобы привлекать школьников к хаскель монадам, а не чтобы предоставлять людям объективную информацию (хотя нет, он не виноват, он всего лишь написал статью для школьников. Виноват тот, кто пихнул это в википедию). 91.77.4.33 10:03, 22 июня 2008 (UTC)

* В языках Паскаль, Бейсик, Си, Питон(Python)... — везде есть понятие функции,и везде мы можем 
определять свои функции. Но не торопитесь делать выводы. 
Речь идёт   не только о формальных возможностях языка, но и о стиле 
составления программ. В функциональных языках программирования с функциями можно работать так же, 
как с числами или строковыми переменными.

  

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

• С критикой ниже согласен. Но обратите внимание на то, что я писал о стиле, и не о том, что что-то невозможно делать на других языках, а о том что это не принято. В функциональных языках программирования с оперирвание функциями выглядит естественно. Очень сложно подобрать фразу, понятную школьнику, которая дала бы ему это понимание. Как сюда попал Питон -- не знаю, либо я допустил ошибку, либо кто-то вписал. Greck 20:14, 10 января 2008 (UTC)

  Я не буду рассматривать в дальнейшем такие языки как С,Paskal,Basik ( BTW Delphy не язык а среда разработки
  - язык ObjectPaskal). С-низкоуровневый язык, не предназнач. для таких задач, а Basik и Paskal 
  просто недоразвитые. Говоря о "других языках" я буду иметь в виду C++,Java,Python,Ruby.
  

• К сожалению, статья уже многократно редактировалась разными людьми. Я сам удивлен насчет Delphi. Greck 20:14, 10 января 2008 (UTC)

  Из первой цитаты можно сделать вывод что в остальных языках нет возможности работать
  с функциями ... так же, как с числами или строковыми переменными.
  В случае с С++&Java это просто неверно, а в случае Python вызывающе неверно.
  Во всех этих языках есть средства функционального программирования. В С++ для этого
  есть шаблоны - типичный пример boost, в Python просто родной динамизм. Более
  того в питоне есть декораторы - синтаксичесткая конструкция, которая значительно 
  упрощает(делает наглядным) использование функций, модифицирующих другие 
  функции. В итоге, начиная с Python2.4, без декораторов не обходится ни одна сколь-нибудь
  серьезная программа. Далее во всех этих языках есть функторы - объекты с перегруженным
  методом вызова т.е. "instance(params)", что позволяет реализовать даже такое:
  

import math
c = Functor(math.log)
e = Functor(math.sin)
m = e + c
m(12) => math.sin(math.log(12))

  Или так
  

(Functor(math.log) + Functor(math.sin))(12)

  На С++ то-же делается на шаблонированных классах на этапе компиляции.
  
     Возможность создавать переменные
типа функций в языках Си/Си++, Паскаль, Delphi есть[1], но ею пользуются крайне редко.
  
  Опять-же совершенно неверно. Для С++ - смотрим STL,Boost. Про Python/Ruby вообще молчу.

• Товарищ, но причем здесь Python/Ruby. Зачем вы бьете мимо? Фраза верная. Возьмите исходники линукса и оцените процент переменных типа функция. Или возьмите исходники того же STL. С чем вы спорите? Фраза "переменных функций в таких то языках существенно меньше, чем переменных НЕ функций" мне ненравиться. Поэтому предлагаю оставить как есть. Greck 20:14, 10 января 2008 (UTC)

  Перечисленные языки процедурные, и они не приспособлены для того, чтобы писать
программы в функциональном стиле.
  
  Наполовину верно для С++, совершенно неверно для Python/Ruby.

• Я и не писал про Python/Ruby. Greck 20:14, 10 января 2008 (UTC)

  А сейчас мы перейдём к вещам, пугающим и шокирующих «императивных» программистов.
Хотите верьте, хотите — нет, но в Haskell есть возможность оперировать бесконечными объектами.
   Можно завести функцию, которая возвращает бесконечную последовательность натуральных
   чисел или бесконечную последовательность чисел Фибоначчи, или какую-нибудь другую
   бесконечную последовательность.

  
  Сама фраза и ее конструкция(впрочем как и во многих других местах этого текста) больше подходит
  для журнала "Мурзилка", чем для википедии. Я не знаю кого данная возможность должна шокировать.
  В С++/Java есть итераторы в Python/Ruby есть генераторы. Это и есть "бесконечные объекты".
  Например так:
  

   from itertool import 
   m = itertools.count(10) # здесь "живут" все числа больше 10, "появляться" они будут по мере необходимости.
   squares = imap(lambda x : x ** 2,m)
   for i in squares:
       print i
	   if i > 10000 : break

• Все верно. Я писал это для своеобразного журнала Мурзилка для школьников. И в том-то всё и дело. Это статья, написанная в таком стиле. И если не нравиться стиль, то её нужно проосто изъять отсюда, либо переписать заново на 100%. Greck 20:14, 10 января 2008 (UTC)

• Не нужно писать про Python/Ruby -- я их обоих знаю, люблю, уважаю и пользую. Greck 20:14, 10 января 2008 (UTC)

  А самое важное (но сложное для понимания) достоинство Haskell заключается в том, в трансляторы языка Haskell со временем можно
будет добавить алгоритмы, которые по данным определениям функций смогут сами находить наиболее эффективные алгоритмы их 
вычисления,....и «научить» трансляторы функциональных языков программирования «видеть их» в определениях функций и применять 
известные эффективные алгоритмы вычисления.

Это так-же из области домыслов автора. Повторюсь - на Haskell(как и почти всех остальных языках) описывается полная последовательность действий, необходимых для достижения результата. Так что если подобные методики появятся то никаких преимуществ Haskell перед C(== всеми императивными языками) в плане их(методик) применимости к компиляции не получит. Впрочем ничего подобного за 60 лет усиленных стараний не появилось и близко.

• Не согласен. Детерминированность действий конкретного интерпретатора Haskel ничего не означает. Я говорил о потенциальных возможностях функциональной парадигмы. Greck 20:14, 10 января 2008 (UTC)

  Подобным образом на Haskell многие алгоритмы можно записать гораздо короче,
нежели на Си, Паскале,… да и, вообще, любом императивном языке.
  Создатели языка Haskell очень гордятся тем, что в нём используется чистая
функциональная парадигма. Они утверждают, что на Haskell .....
  Создатели также утверждают, что программы на Haskell получаются более модульные ....
  
  Все эти фразы не соответствуют указанным правилам и духу википедии. Нас мало интересует 
  что по поводу этого языка думают другие, особенно если это такие предвзятые люди,
  как его авторы. Нас интересуют факты. А за фактами по поводу скорости,потребления памяти и
  размера программ принято ходить сюда - http://shootout.alioth.debian.org/.
  Хочу предостеречь от несерьезно отношения к данному ресурсу. Так примеры для Python/C там однозначно
  очень быстрые. Для haskell, точнее для GHC, похоже тоже, т.к. ему удалось на дву тестах заметно
  обогнать по скорости GCC. Из него мы можем легко сделать вывод что сколь-нибудь серьезные программы
  на Haskell далеко не всегда короче программ на С\С++\Java и заметно длиннее программ на Python\Ruby.
  Впрочем там-же видно что Haskell(GHC) не такой уж и медленный (в среднем в 1.6 - 2 раза медленнее С и
  значительно(до десятков раз) быстрее динамических языков).

• Не согласен. Когда открывался этот раздел, я специально консультировался у Рамира. Субъективность допускалась.

  Кроме того, отмечается, что благодаря строгой типизации языка, в программах на Haskell не
случается системных ошибок и не бывает аварийных ситуаций (сore dump).
  

   int c[10];
   c[-10000] = 0;

  В этом куске программы типизация соверщенно строгая, но ошибка все-же будет, и, при определенном стечении
  обстоятельств, будет именно SIG_SEGV и "сore dump". В Haskell нет таких ошибок из-за проверок границ
  на этапе исполнения и отсутствия указателей.

• Фраза нормальная. Оставить как есть. Вы почему-то споря с одним верным утверждением A, высказываете другое верное утверждение B. Не понятно, с чем вы спорите. Вы хотите, чтобы в статье было утверждение B? Но зачем для этого удалять A? Причина, по которой в Haskell не бывает SIG_SEGV и "сore dump" известна: <<В Haskel не бывает SIG_SEGV и "сore dump", так как это интерпретируемый язык>>. Они могут возникнуть лишь в случае ошибок в реализации интерпретатора. Но я не захотел это писать в популярной статье. Greck 20:14, 10 января 2008 (UTC)

  Мощь, которую предоставляет это исчисление, ещё не до конца осознана программистами,
и не в полной мере используется на практике.
  
  Да - вокруг одни кретины(с). Мощь lambda исчислений давно осознана и используется по назначению
  (и потому так редко) всеми развитыми языками.

• Отчего так яростно и против чего собственно боритесь? Это художественная гипербола, а данная статья -- популярная статья по инфрматике для МОТИВАЦИИ изучения функционального программирования. Я много изучал промышленного кода написанного профессиональными программистами (Python, Ruby). Осмысленное и умелое использование lambda встречается крайне редко. Пока я оценил это только в RubyOnRails.

  Именно поэтому многие разработчики языков программирования в качестве одного из важных
достоинств языка указывают его близость к естественному языку (обычно английскому).
   
  12 лет программирую. Lisp после Paskal и Basik освоил за неделю. Ruby и Python понятны сразу.
  Ни одного примера на Haskell "с налета" "неасилил". IMHO язык не более(== гораздо менее) понятен чем 
  любой императивный. А если серьезно то где ссылки на слова этих самых программистов? 
  Желательно не разработчиков языка. Фраза совершенно не очевидна.

• За всех не говорите. У Вас уже не может быть опыта изучения Haskell как первого языка программирования. Иперативные стереотипы давят. Ваше мнение субъективно, как и любое другое. Greck 20:14, 10 января 2008 (UTC)

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

  
  Опять-же для почти всех других языков есть сборщики мусора (или встроенные в язык, или внешние). Есть
  "умные" и "ведущие" указатели, средства подсчета ссылок, мощные внешние аллокаторы. Многое из этого есть даже для С и Fortran.
  
  Функциональные языки освобождают программиста от этой непростой обязанности. 
  
  Как и почти все остальные.

• Хорошо. Я открою Вам тайну. На самом деле я боролся c Pascal и Basic в школах. И, опубликовав данную статью в школьном журнале, небольшой шаг для достижения это маленькой, но конкретной цели, я сделал. Все ваши замечания, к сожалению, откомментировать не могу. Не хочу разводить большую дискуссию. Greck 20:14, 10 января 2008 (UTC)

  Пользователи с огромным удовольствием пишут для этой системы свои приложения.
  
  Где ссылки на документальные описания уровня удовольствия пользователей. Фраза не для википедии.
  
  слишком универсальном языке программирования типа Си++
  
  Пока еще не видел не одну программу сложнее tee, для которой C++ слишком универсален.
  Ссылки на исследования в которых показано как универсальность C++ мешала его использованию.
  
  Для прототипирования используют языки высокого уровня абстракции (Java
  
  Ссылки на примеры прототипирования на Java. Haskell используется для прототипирования
  (собственно сама идея прототипировать на haskell что-бы потом переписать на С++, как написано в статье,
   выглядит очень странно, т.к. языки слишком разные)
  __гораздо__ реже чем остальные языки в этом списке(я думаю не чаще чем FORT) == ему не место в этом списке.
  
  Универсальность языка не всегда является плюсом...
Есть множество забавных примеров — коротких программ
на Си и Си++, в которых не могут разобраться даже специалисты, пока не скомпилируют их,
   не запустят и не проведут часок-другой за их исследованием.
  
  Равно как и на любом другом языке. И я не верю что Haskell тут является исключением( == хочу видеть доказательство
  невозможности написания таких программ на Haskell).
  
  И на последок - в статье постоянно путают две вещи: функциональный стиль программирования
  и функциональный язык программирования. Все развитые мультипарадигменные языки
  (а именно сюда относятся C++,Python,Ruby,...) или давно переняли или от рождения имели большую
  часть положительных сторон функциональных языков.  И на всех них можно писать в функциональном стиле
  (на одних проще - на других нет ( иногда с библиотеками типа boost)). И используется в них настолько
  обширно насколько он того заслуживает(так например в Python и Ruby - достаточно широко).
 

Koder

Уважаемый Koder! Не могу судить о правильности или ложности Вашей критики самой статьи (ибо не учился в вузе информатике, даже на постсоветском пространстве), но повторяю: к Вашим услугам — автор статьи, контактные сведения он указывает на своей странице. Более того, Вы можете связаться с Романом Душкиным (Участник:Dark_Magus) — одним из ведущих русских авторов по ФП вообще и Haskell’у в частности (если Вас смущает, что он был-таки преподавателем в постсоветском вузе — успокойтесь, он также публикует книги и применяет свою экспертизу на рабочей практике) — и попросить у него рецензию на эту статью. Ramir 01:56, 20 июня 2007 (UTC)

Что же насчёт «дочернего проекта Википедии» — Вы неправы. Ссылки на конкретные разделы «чем не является Википедия», данные Вами, не работают. Впрочем, ни в коей мере руководства Википедии не относятся к Викиучебнику; общие у нас только серверы и лицензия распространения. Ramir 02:00, 20 июня 2007 (UTC)

http://ru.wikibooks.org/wiki/Справка : "Википедийские «правила» применительны и к Викиучебнику, но по мере их осмысленности в отношении учебных текстов....". Я указывал на следующие правила википедии - "Википедия — не средство для распространения новых идей" и"Википедия — не трибуна". Это, в частности, требует обязательных ссылок на компетентные источники(и не просто на www.xxxxx.org, а на конкретную страницу) и непредвзятого отношения к материалу. Ссылки действительно не работают, точнее указывают на заглавную страницу правил. Koder(koder_dot_mail_at_gmail_dot_com)

А, если вы об этом, то разумеется: Викиучебник — образовательный проект, и этим определяются требования к помещаемым материалам. Но в данном случае, кажется, никакого продвижения новых идей нет: некоторые преимущества ФП над Имп.П, и их важность — пусть идеологически спорная, но всё же распространённая в академической среде идея. Ramir 00:39, 21 июня 2007 (UTC)

map (add 10) [1, 2, 3] ) $\Rightarrow$ [11, 12, 13]. здесь в коде по всей видимости не хватает открывающейся круглой скобки.  217.150.60.5 22:08, 5 апреля 2008 (UTC)

Все развитые мультипарадигменные языки (а именно сюда относятся C++,Python,Ruby,...)

Ну если про питон и руби можно согласиться, то писать на с++ в функциональном стиле - головная боль. И не надо про бусты, функторы и прочее... Это смешно... чесслово. 91.193.126.104 19:28, 19 марта 2009 (UTC)

Да и питон тоже. Отсутствие оптимизации хвостовой рекурсии очень часто создает проблемы. 91.193.126.104 17:01, 20 августа 2009 (UTC)