Обсуждение:Язык Haskell: О пользе и вреде лени: различия между версиями
Содержимое удалено Содержимое добавлено
Ramir (обсуждение | вклад) Нет описания правки |
Greck (обсуждение | вклад) |
||
Строка 58:
Причем переменные никуда в итоге не делись. Просто вместо переменных у Вас функции, которые их по
запросу возвращают.
:::* Ух, как тут много всего понаписали. Придётся отвечать. Многое подмечено верно (включая комментарии ниже). Но я писал образно и несовсем точно вполне сознательно, чтобы выработать правильные ассоциации. Я действительно считаю, что образ мышления программста на Haskel и других ФЯ сильно отличается от образа мышления программста на С++. И мне кажется что данная фраза лучше всего подходит для того, чтобы дать читателю такую первую ассоциацию, которая будет первым шагом к пониманию, пусть даже она не точна. Я считаю, что допустимо писать не совсем верные утверждения -- точность утверждение приносится в жертву яркому запоминающему образу, который больше ориентирован на понимание сути, нежели на передачу эциклопедически точного определения. Это касается и всех остальных утверждений, которые вам не понравились. И еще я считаю, что "наукой [программированием, образованием, написанием статей, ...] не нужно заниматься со звериной яростью, это надо делать весело и красиво, иначе нечего в неё соваться" (c). Но в принципе, правьте, если действительно считаете, что это принесет пользу. Под пользой я вижу --- большее количество школьников будет привлечено аннотацией/прочтёт статью до конца и пногое извлечет/поймет суть. Я часто сталкиваюсь с ситуацией, когда человек вызубрил точное определение, но не знает сути. Лучше когда наоборот -- детали можно не знать, главное иметь в голове понимание и образы, который могут работать в мыслительном процессе. Умение читать учебники и документацию восполнит не знание точных деталей. Длинные предложения с неизвестными терминами могут увелисть точность, но отдалить нас от целевой аудитории. [[Участник:Greck|Greck]] 20:14, 10 января 2008 (UTC)
* '''В языках Паскаль, Бейсик, Си, Питон(Python)... — везде есть понятие функции,и везде мы можем <br />определять свои функции. Но не торопитесь делать выводы. <br />Речь идёт не только о формальных возможностях языка, но и о стиле <br />составления программ. В функциональных языках программирования с функциями можно работать так же, <br />как с числами или строковыми переменными.'''<br />
'''Например, представьте себе функцию, которая в качестве аргумента принимает некоторую<br />функцию, а в качестве результата возвращает другую функцию.'''
:::* С критикой ниже согласен. Но обратите внимание на то, что я писал ''о стиле'', и не о том, что что-то невозможно делать на других языках, а о том что это не принято. В функциональных языках программирования с оперирвание функциями выглядит естественно. Очень сложно подобрать фразу, понятную школьнику, которая дала бы ему это понимание. Как сюда попал Питон -- не знаю, либо я допустил ошибку, либо кто-то вписал. [[Участник:Greck|Greck]] 20:14, 10 января 2008 (UTC)
Я не буду рассматривать в дальнейшем такие языки как С,Paskal,Basik ( BTW Delphy не язык а среда разработки
- язык ObjectPaskal). С-низкоуровневый язык, не предназнач. для таких задач, а Basik и Paskal
просто недоразвитые. Говоря о "других языках" я буду иметь в виду C++,Java,Python,Ruby.
:::* К сожалению, статья уже многократно редактировалась разными людьми. Я сам удивлен насчет Delphi. [[Участник:Greck|Greck]] 20:14, 10 января 2008 (UTC)
Из первой цитаты можно сделать вывод что в остальных языках нет возможности работать
'''с функциями ... так же, как с числами или строковыми переменными'''.
Строка 95 ⟶ 102 :
Опять-же совершенно неверно. Для С++ - смотрим STL,Boost. Про Python/Ruby вообще молчу.
:::* Товарищ, но причем здесь Python/Ruby. Зачем вы бьете мимо? Фраза верная. Возьмите исходники линукса и оцените процент переменных типа функция. Или возьмите исходники того же STL. С чем вы спортите? Фраза "переменных функций в таких то языках существенно меньше, чем переменных не функций" мне ненравиться. Поэтому предлагаю оставить как есть. [[Участник:Greck|Greck]] 20:14, 10 января 2008 (UTC)
'''Перечисленные языки процедурные, и они не приспособлены для того, чтобы писать<br />программы в функциональном стиле.'''
Наполовину верно для С++, совершенно неверно для Python/Ruby.
:::* Я и не писал про Python/Ruby. [[Участник:Greck|Greck]] 20:14, 10 января 2008 (UTC)
'''А сейчас мы перейдём к вещам, пугающим и шокирующих «императивных» программистов.<br />Хотите верьте, хотите — нет, но в Haskell есть возможность оперировать бесконечными объектами.<br /> Можно завести функцию, которая возвращает бесконечную последовательность натуральных<br /> чисел или бесконечную последовательность чисел Фибоначчи, или какую-нибудь другую<br /> бесконечную последовательность.'''<br />
Строка 115 ⟶ 124 :
if i > 10000 : break
</source>
:::* Все верно. Я писал это для своеобразного журнала Мурзилка для школьников. И в том то все и дело. что этот стаьтья написанная в таком стиле. И если не нравиться стиль, ее нужно проосто изъять отсюда, либо переписать заново на 100%. [[Участник:Greck|Greck]] 20:14, 10 января 2008 (UTC)
:::* Не нужно писать про Python/Ruby -- я их обоих знаю, люблю, уважаю и пользую. [[Участник:Greck|Greck]] 20:14, 10 января 2008 (UTC)
'''А самое важное (но сложное для понимания) достоинство Haskell заключается в том, в трансляторы языка Haskell со временем можно<br />будет добавить алгоритмы, которые по данным определениям функций смогут сами находить наиболее эффективные алгоритмы их <br />вычисления,....и «научить» трансляторы функциональных языков программирования «видеть их» в определениях функций и применять <br />известные эффективные алгоритмы вычисления.'''
Строка 123 ⟶ 135 :
в плане их(методик) применимости к компиляции не получит. Впрочем ничего подобного за 60 лет
усиленных стараний не появилось и близко.
:::* Не согласен. Детерминированность действий конкретного интерпретатора Haskel ничего не означает. Я говорил о потенциальных возможностях функциональной парадигмы. [[Участник:Greck|Greck]] 20:14, 10 января 2008 (UTC)
'''Подобным образом на Haskell многие алгоритмы можно записать гораздо короче,<br />нежели на Си, Паскале,… да и, вообще, любом императивном языке.'''
Строка 138 ⟶ 152 :
Впрочем там-же видно что Haskell(GHC) не такой уж и медленный (в среднем в 1.6 - 2 раза медленнее С и
значительно(до десятков раз) быстрее динамических языков).
:::* Не согласен. Когда открывался этот раздел, я специально консультировался у Рамира. Субъективность допускалась.
'''Кроме того, отмечается, что благодаря строгой типизации языка, в программах на Haskell не<br />случается системных ошибок и не бывает аварийных ситуаций (сore dump).'''
Строка 149 ⟶ 165 :
обстоятельств, будет именно SIG_SEGV и "сore dump". В Haskell нет таких ошибок из-за проверок границ
на этапе исполнения и отсутствия указателей.
:::* Фраза нормальная. Оставить как есть. Вы почему то споря с одним верным утверждением A, высказываете другое верное утверждение B. Не понятно, с чем вы спорите. Вы хотите, чтобы в статье было утверждение B? Но зачем для этого удалять A? Причина, по которой в Haskell не бывает SIG_SEGV и "сore dump" известна: <<В Haskel не бывает SIG_SEGV и "сore dump", так как это интерпретируемый язык>>. Но я не захотел такое писать в популярной статье. [[Участник:Greck|Greck]] 20:14, 10 января 2008 (UTC)
'''Мощь, которую предоставляет это исчисление, ещё не до конца осознана программистами,<br />и не в полной мере используется на практике.'''
Строка 154 ⟶ 171 :
Да - вокруг одни кретины(с). Мощь lambda исчислений давно осознана и используется по назначению
(и потому так редко) всеми развитыми языками.
:::* Отчего так яростно и против чего собственно боритесь? Это художественная гипербола, а данная статья -- популярная статья по инфрматике для МОТИВАЦИИ изучения функционального программирования. Я много изучал промышленного кода написанного профессиональными программистами (Python, Ruby). Осмысленное и умелое использование lambda встречается крайне редко. Пока я оценил это только в RubyOnRails.
'''Именно поэтому многие разработчики языков программирования в качестве одного из важных<br />достоинств языка указывают его близость к естественному языку (обычно английскому).'''
Строка 161 ⟶ 179 :
любой императивный. А если серьезно то где ссылки на слова этих самых программистов?
Желательно не разработчиков языка. Фраза совершенно не очевидна.
:::* За всех не говорите. У вас уже не может быть опыта изучения Haskell как первого языка программирования. Иперативные стереотипы давят. Ваше мнение субъективно, как и любое другое. [[Участник:Greck|Greck]] 20:14, 10 января 2008 (UTC)
'''Во многих сложных программах возникает необходимость динамического выделения памяти.<br />...выделить нужное количество байт.....Программист ответственен за возвращение этой памяти обратно системе<br />. Когда потребность в выделенной памяти отпадает, он должен послать запрос возвращения (освобождения) памяти....'''<br />
Строка 170 ⟶ 189 :
Как и почти все остальные.
:::* Хорошо. Я открою вам тайну. На самом деле я боролся c Pascal и Basic в школах. И, опубликовав данную статью в школьном журнале, небольшой шаг для достижения это маленькой, но конкретной цели, я сделал. Все ваши замечания, к сожалению, откомментировать не могу. Не хочу разводить большую дискуссию. [[Участник:Greck|Greck]] 20:14, 10 января 2008 (UTC)
'''Пользователи с огромным удовольствием пишут для этой системы свои приложения.'''
| |||