?

Log in

No account? Create an account
Why Haskell - ru_declarative — LiveJournal [entries|archive|friends|userinfo]
ru_declarative

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Why Haskell [Jul. 1st, 2010|02:34 am]
ru_declarative

ru_declarative

[geeks_ru]
Делал для студентов презентацию на тему "Почему Haskell хороший, годный язык программирования", может кому еще для обучения начинающих пригодится (знатоки ничего нового там не найдут). Это попыка ответить на вопрос - почему Haskell, а не Java/C++/Python...?

Ссылка
linkReply

Comments:
Page 1 of 2
<<[1] [2] >>
[User Picture]From: alexandermarkov
2010-06-30 11:11 pm (UTC)
Хорошая, годная презентация.
(Reply) (Thread)
[User Picture]From: lionet
2010-06-30 11:37 pm (UTC)
Замечательно!

Про статическую vs. динамическую типизацию, правда, ты порядком слукавил, не отметив (заметив) state of the art. Особенно пункты 3 и 4 на двенадцатом слайде.

http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html
(Reply) (Thread)
[User Picture]From: cp_poster
2010-07-01 09:55 am (UTC)
Вспотел пока читал.
В общем он там и пункты 1 и 2 критикует.
По пункту 2: Мол когда система растет, то старые типовые абстракции уже могут не подойти, что type system постоянно путается под ногами в этих случаях.
По пункту 1: Уловил мысль плохо, но что-то вроде: это не важно, раньше, позже. Какая разница? IDE, юнит тесты, QA etc.
(Reply) (Parent) (Thread)
[User Picture]From: skiminog
2010-07-01 12:25 am (UTC)
Мелкие пять копеек.
Почему ссылка на F# дана шириною во весь слайд, если достаточно http://fsharp.net?
(Reply) (Thread)
From: pelou
2010-07-01 05:06 am (UTC)
Примеры в слайд про ортогональность.

Всё-таки, думается, главная беда неортогональности это то, что реализация какой-то простой функциональности влечёт за собой целый хвост дополнительных инструкций.

Например, на с++:

string text;
fstream fileStream("file.txt");

while(fileStream >> text)
{
cout << text;
}

Если бы с++ был ортогонален, то можно было сделать что-то подобное:

сout << fstream("file.txt");

(Reply) (Thread)
From: archimag-dev.blogspot.com
2010-07-01 08:54 am (UTC)
> Если бы с++ был ортогонален, то можно было сделать что-то подобное:
> сout << fstream("file.txt");

Не понял, что не так:

cout << fstream("file.text").rdbuf() << std::flush;
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: bik_top
2010-07-01 05:30 am (UTC)
>2.0 (2006) – добавлены анонимные делегаты

http://community.livejournal.com/fprog/12617.html?thread=293193#t293193
(Reply) (Thread)
[User Picture]From: thedeemon
2010-07-01 07:44 am (UTC)
Протестую против неэкивалентных примеров синтаксиса Ocaml vs. Haskell.
Нужно либо
let rec sum list =
  match list with
  | [] -> 0
  | x::xs -> x + sum xs

и

sum list = 
  case list of
    [] -> 0
    x:xs -> x + sum xs


либо

let rec sum = function
  | [] -> 0
  | x::xs -> x + sum xs

и

sum [] = 0
sum (x:xs) = x + sum xs
(Reply) (Thread)
[User Picture]From: geeks_ru
2010-07-01 06:41 pm (UTC)
Да, пожалуй - я просто скопировал из Википедии; какой вариант в OCaml более естественный?
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: xeno_by
2010-07-01 07:49 am (UTC)
На практике чрезмерная приверженность наследованию (а это единственное, что отличает ООП от ФП – инкапсуляция и полиморфизм есть и в Haskell)...
А в Haskell разве можно реализовать рантайм-полиморфизм ака виртуальные методы? На хаскелл-вики я видел, например, гетерогенную коллекцию с типа рантайм-полиморфизмом, который сэмулирован тайпклассами, но там кагбэ полиморфичные вызовы разруливаются в компайл-тайме, а не в рантайме. См. также: http://www.haskell.org/haskellwiki/OOP_vs_type_classes#Downcasting_is_a_mission_impossible.

upd. Ага, дальше по тексту вы утверждаете, что наследование реализации создает проблемы, поэтому и от наследования и от полиморфизма в смысле Симулы надо отказаться, а, следовательно, ADT >> OOP. Мне кажется, здесь, во-первых, недостаточно аргументов для доказательства посылки, а, во-вторых, не совсем честное следствие. Насчет первого, вы не рассматриваете трейты/миксины, поэтому аргументация получается неполной. А насчет второго - ведь полиморфизм Симулы (т.е. виртуальные методы) совсем не исчерпывает динамический диспатч в реализации ООП в смысле Смолтока.

upd2. Ленивые вычисления: значения аргументов не вычисляются, аргументы передаются в виде невычисленных thunk'ов, которые форсируются по мере необходимости (call-by-need)...
А вы точно уверены, что в Хаскелле юзаются именно санки? Мы когда-то имели разговор с nponeccop, и он мне объяснял, что нет никаких санков, а есть только вывернутые наизнанку вычисления. Я не спец тут, но, по-моему, эту тему нужно еще поисследовать, прежде чем паблишить презентацию.

Edited at 2010-07-01 08:10 am (UTC)
(Reply) (Thread)
[User Picture]From: thesz
2010-07-01 08:22 am (UTC)
В Хаскеле "юзаются" именно "санки".

Во всех реализациях Хаскеля.

Поэтому это не основание не "паблишить" "презентацию".
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: thedeemon
2010-07-01 07:56 am (UTC)
Слайд 61:
запускаю ghci, ввожу приведенный пример (sum [1..1000000], но лучше еще нолик добавить) и вижу, что про O(1) все враки. В данном случае проблема в определении sum, она на ровном месте создает цепочку санков глубиной с весь список. Такой чудный подарок ленивости. И без переписывания sum фиг исправишь, ведь.
(Reply) (Thread)
[User Picture]From: geeks_ru
2010-07-01 06:45 pm (UTC)
Да, ленивость - зло, конечно :)
Хотя оптимизация (анализ строгости) иногда помогает - как в случае sum.
(Reply) (Parent) (Thread)
From: gds
2010-07-01 08:03 am (UTC)

Светлое будущее
[...]
• Гибридизация ФП и ООП – язык Scala объединяет в себе
обычные классы, алгебраические типы данных (в виде case
classes), traits


Это не будущее, это уже давно прошлое -- см. Objective Caml.
(Reply) (Thread)
[User Picture]From: thedeemon
2010-07-01 09:38 am (UTC)
Думаю, имелось в виду, что в Скале классы и АТД не отдельные независимые фичи, как в окамле, а одна универсальная.
(Reply) (Parent) (Thread)
[User Picture]From: xeno_by
2010-07-01 08:29 am (UTC)
Хотел обновить предыдущий камент, но на него уже ответили. Еще мне кажется, что слишком большой акцент сделан на иммутабельность и чистоту, в то время как аргументы в их пользу сводятся к общим словам - ну там про закон Мура или про то, что кагбэ проще отлаживать.

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

upd. Ну и конечно, спасибо за действительно интересный контент!

Edited at 2010-07-01 08:41 am (UTC)
(Reply) (Thread)
[User Picture]From: geeks_ru
2010-07-01 06:52 pm (UTC)
Совершенно согласен - мутабельность в нужных местах очень помогает, и лично мне хотелось бы иметь что-то поудобнее монад для выражения эффектов.

Акцент сделан в первую очередь потому, что это для студентов, которые до этого были знакомы только с императивными языками.
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: hdima
2010-07-01 09:13 am (UTC)

Теория против практики

Это все, конечно, хорошо, но я бы в данном случае использовал понятие "теоретическое программирование". Что бы кто-то начал использовать Haskell на практике нужна хотя бы парочка реально работающих проектов в той же области. Иначе это все из области "теоретического программирования": "ой, смотри как в этом языке можно классно переделать такую конструкцию". Насчет Haskell я пока слышал только про реальные проекты разного рода "эмуляторов" и "конверторов" - довольно специфическая ниша.

Плюс, надо учитывать, что в реальных проектах участвую разработчики совершенного разного уровня и нужно что бы язык более-менее понимали все, иначе весь проект разваливается. Обычно чем менее понятен язык, тем проще написать на нем ужасный код. Статическая типизация тоже не спасает в данном случае, т.к. ребята первым делом отыщут как определить AnyPossibleObjectType и он будет везде использоваться. Когда проект нужно с нуля запустить в продакшен через две недели (а это, кстати, реальные сроки из давних проектов с Python), то никто не будет искать лучшие подходы.
(Reply) (Thread)
From: gds
2010-07-01 09:19 am (UTC)

Re: Теория против практики

> Статическая типизация тоже не спасает в данном случае, т.к. ребята первым делом отыщут как определить AnyPossibleObjectType и он будет везде использоваться.

жжоте.
(Reply) (Parent) (Thread)
[User Picture]From: zam0th
2010-07-01 09:28 am (UTC)

ща опять холивар начнется Т.Т

имхо "хорошесть и годность языка программирования" определяется в первую очередь не присущими ему свойствами, а применимостью его к задачам реального мира. поэтому "вопрос - почему Haskell, а не Java/C++/Python" - изначально порочен (потому что практика показывает - джава и питон, а не хаскел). его надо сформулировать несколько по-другому: "выбор между Haskell, Java, C++, Python, etc".

студенты должны понять простую вещь: дрочить на X и заранее отбрасывать Y, Z и W "потому что они не Ъ" - упадничество. нужно уметь выбирать между X, Y и Z исходя из требований, а для этого надо знать сильные и слабые стороны.
(Reply) (Thread)
[User Picture]From: geeks_ru
2010-07-01 06:56 pm (UTC)

Re: ща опять холивар начнется Т.Т

Хе-хе, так в том-то и суть, что Haskell закладывается в неокрепшие студенческие мозги! Так мы захватим мир :)
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: alexott
2010-07-01 09:35 am (UTC)
на первый взгляд более-менее хорошо, но есть замечание по оформлению - слишком много текста на слайдах. Длинный текст лучше вынести в notes, доступные для преподавателя
(Reply) (Thread)
[User Picture]From: geeks_ru
2010-07-01 07:24 pm (UTC)
К сожалению, лекция на эту тему не состоялась, так что пришлось писать подробно.
(Reply) (Parent) (Thread) (Expand)
(Deleted comment)
[User Picture]From: geeks_ru
2010-07-01 07:02 pm (UTC)
Преимущество он будет иметь тогда, когда Haskell будет популярен; а популярным он может стать, только если такие вопросы заметать под ковер :)
(Reply) (Parent) (Thread) (Expand)
[User Picture]From: nikita_timofeev
2010-07-01 10:32 am (UTC)
На 4ом слайде какой-то совсем не натуральный пример с фильтром.
Утверждение о том, что вывод типов спасает, мне показалось несколько лукавым в виду того что сигнатуры всё равно пишутся для повышения читабельности.
Не увидел на 9ом слайде ничего плохого, это нормально?
На 14ом слайде говорится очень много не разумного про C/С++: вопреки расхожему заблуждению в C нет массивов (только хитрые указатели на память), а обсуждение синтаксис C++ автоматически превращает любую умную сентенцию в троллинг.
На 60ом слайде имеется утверждение что ленивый язык обязан быть чистым, что несколько противоречит оставшейся презентации.
Кроме того для слайдов можно было осилить типографскую раскладку и ставить ударение соответствующим символом.
(Reply) (Thread)
[User Picture]From: alll
2010-07-01 11:06 am (UTC)
> вопреки расхожему заблуждению в C нет массивов (только хитрые указатели на память)

sizeof() негодуе :)

если что-то выглядит как утка, плавает как утка и крякает как утка, то это и есть утка
(Reply) (Parent) (Thread) (Expand)
Page 1 of 2
<<[1] [2] >>