catpad: (Default)
[personal profile] catpad

Долго думал и, наконец, решил изучить два языка программирования - Haskell и Erlang.

Причины такие. В принципе, Haskell мне уже просто надоело не знать, надо раз и навсегда решить этот вопрос. Но самое главное здесь то, что изучить его просто невозможно за один день (как в случае с каким-нибудь Пайтоном или Руби), что и делает весь процесс интересным.
Вторая причина состоит в том, что я хочу в конце концов понять, что такое монады. Так часто слышишь, что монады понять невозможно и что нужны они только для того, чтобы неким извращённым образом работать с IO, потому что обычным способом чистый функциональный язык не разрешает - и тому подобное, что я решил положить всему этому конец (для себя). И кроме того, даже после очень поверхностного знакомства с ними, я понял, что монады - это далеко не только IO, а нечто гораздо более важное. Монады позволяют управлять побочными эффектами: они дают возможность создавать свои собственные правила flow of control и указывают, каким именно образом распространяются побочные эффекты. Эти правила потом можно комбинировать, создавая из них ещё более сложные правила.
Если я правильно понимаю, усвоив монады, можно практически создавать внутри Haskell'а свои собственные мини-языки.

Эта идея мне очень, очень нравится. Я вообще последнее время думаю над новой парадигмой (в смысле, какова могла бы быть эта новая парадигма) и вот к какому выводу пришёл. Самая большая беда существующих mainstream-языков состоит в том, что практически все "ортогональные" понятия в них перемешаны. Самый вопиющий пример - это multithreading. То, что поддержка multithreading в программе перемешана с внутренней логикой программы, которая никакого отношения к механизмам синхронизации (например) не имеет - это на самом деле довольно-таки вопиющее обстоятельство. (Именно поэтому я стараюсь его хотя бы частично избежать и вот тут даже кое-что для этого сделал. Кстати, это как раз и является причиной того, что следующим языком для изучения я выбрал Erlang, в котором используется та же самая архитектура, только гораздо "чище", чем в моей джавовской библиотеке - вообще без всяких побочных эффектов и destructive updates).

Aspect-Oriented подход делает ещё один шаг к решению проблемы разделения ортогональных составляющих; в случае AOP это cross-cutting concerns, то есть, попросту говоря, схожее поведение в одинаковых ситуациях на мета-уровне - всякий раз делать нечто при вызове метода, делать ещё что-то на выходе из метода и т.д.) Но и это решает только часть проблемы.
А как быть с preconditions, postconditions и invariants ? (Здесь на помощь приходит Eiffel). А что, если попробовать отделить намерения от кода ? (Есть такое intentional programming, но оно что-то совсем не внушает доверия). Можно, конечно, ещё программировать на интерфейсах, но это в чистом виде невозможно.
А как вообще быть с design patterns ? Ведь это, по сути дела, тоже ортогональная составляющая программы - к логике происходящего паттерны отношения не имеют. Как отделить их ?

И ещё большая проблема - добиться loose coupling. Для этого существует паттерн Inversion of Control - почему бы не встроить его в язык ?
И, наконец, вездесущие side effects. Возвращаясь к началу: я думаю, что монады - это и есть путь к управлению side effects.

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

И, наконец, ещё одна причина, которая побудила меня взяться за Haskell. Я наткнулся на замечательный блог, в котором автор довольно много уже написал о Haskell'е (и ещё собирается писать). Он сам не так давно начал его изучать, и язык этот его сильно поразил. В общем, он там делится своими наблюдениями, и читать всё это крайне интересно.
(Лучше всего начать читать с поста Liberating Myself from the von Neumann Style).

Кстати, пока я это писал, в блоге появилось следующее сообщение: автор блога будет писать книгу "Pragmatic Haskell" для Pragmatic Programmers! Это замечательная новость, потому что объясняет он всё очень хорошо, а Pragmatic Programmers - это чудесное издательство, о другой книге которого я тут же сейчас и напишу.

Так вот, Pragmatic Programmers скоро (в июле) выпустит книгу об Erlang'e, написанную его создателем Джо Армстронгом. После этого я и собираюсь изучить Erlang, который, конечно, несравнимо проще, чем Haskell. Но именно поэтому, я думаю, он всё-таки получит гораздо большее распространение, причём довольно скоро.
А пока можете почитать интервью с Армстронгом, в котором он объясняет основные свойства языка.

Date: 2007-05-16 11:51 pm (UTC)
From: [identity profile] catpad.livejournal.com
Вот именно. А ещё - эрланговские "процессы-объекты" гораздо более настоящие объекты, чем просто объекты ООП. Потому что каждый такой объект 1) живёт в своём процессе и 2) не имеет ничего общего с другими объектами - в точности как в реальном мире.

Re: Reply to your comment...

Date: 2007-05-17 04:36 am (UTC)
From: [identity profile] migmit.livejournal.com
Ни фига не понял. Что такое "настоящие объекты" и нафига они в программировании?
Как раз Кеевские объекты должны (по его же определению) не иметь ничего общего с другими и, в идеале, жить параллельно.

Re: Reply to your comment...

Date: 2007-05-17 07:35 am (UTC)
From: [identity profile] catpad.livejournal.com
Настоящие объекты - это те, которые по своим свойствам наиболее близки к физической реальности.
Зачем они нужны, не знаю. Но думаю, что чем ближе к реальности, тем лучше. Подробней не отвечу.
Ну вот значит Кеевские объекты как раз и воплощены в Эрланге.

Re[2]: Reply to your comment...

Date: 2007-05-17 07:49 am (UTC)
From: [identity profile] migmit.livejournal.com
Дык настоящие объекты постоянно наблюдают массу общих переменных и очень сильно зависят друг от друга.
Page generated Feb. 6th, 2026 07:32 pm
Powered by Dreamwidth Studios