![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
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. Но именно поэтому, я думаю, он всё-таки получит гораздо большее распространение, причём довольно скоро.
А пока можете почитать интервью с Армстронгом, в котором он объясняет основные свойства языка.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2007-05-16 08:10 am (UTC)Erlang уже становится популярным языком. Но росту его популярности мешает отсутствие хорошей библиотеки виджетов, идеологически подходящей к языку. Без нее он из телекома не скоро выберется.
no subject
Date: 2007-05-16 08:36 am (UTC)Насчёт Erlanga. Да, хотелось бы, чтобы он становился всё более и более популярным - уж очень он прекрасен. В некоторых областях он мог бы применяться прямо сейчас, без всяких виджетов. Я, например, делаю парсеры на С++. На Erlangе тот же самый парсер я бы написал раз в 10 быстрей и кода там было бы в 100 раз меньше (pattern matching, причём бинарный - вот и всё, что мне на самом деле нужно - и всё это лежит готовое и ждёт использования). Но кто ж даст мне писать парсер на Erlangе!
Я, кстати, думаю, что (как это ни парадоксально) главным препятствием на пути Erlanga в массы является отсутствие IDE. Есть некий Erlide - весьма позорный Eclipse-plugin, который мало того, что не работает, но ещё и завешивает мне Eclipse примерно каждый день.
Я почти уверен - появись завтра мощный и удобный Eclipse-plugin - популярность Erlanga выросла бы в несколько раз.
no subject
Date: 2007-05-16 10:15 am (UTC)IDE, лично мне, не требуется. Но Erlang чем-то неуловимым напоминает Smalltalk, и, IMHO, среду к нему можно разработать в смолтоковском стиле.
no subject
Date: 2007-05-16 02:00 pm (UTC)no subject
Date: 2007-05-16 11:48 pm (UTC)no subject
Date: 2007-05-16 02:02 pm (UTC)no subject
Date: 2007-05-16 02:04 pm (UTC)no subject
Date: 2007-05-16 08:02 pm (UTC)no subject
Date: 2007-05-16 11:51 pm (UTC)Re: Reply to your comment...
Date: 2007-05-17 04:36 am (UTC)Как раз Кеевские объекты должны (по его же определению) не иметь ничего общего с другими и, в идеале, жить параллельно.
Re: Reply to your comment...
Date: 2007-05-17 07:35 am (UTC)Зачем они нужны, не знаю. Но думаю, что чем ближе к реальности, тем лучше. Подробней не отвечу.
Ну вот значит Кеевские объекты как раз и воплощены в Эрланге.
Re[2]: Reply to your comment...
Date: 2007-05-17 07:49 am (UTC)no subject
Date: 2007-05-17 11:54 am (UTC)Кстати, прочел "в 10 быстрей" и вспомнил, хотел вас спросить.
Вы у avva писали что сделать GUI на Java в 10 быстрей чем на С++. Я понимаю что Java более подходящий язык для GUI чем С++, но откуда разница в 10 раз ?
На одной платформонезависимости и защищенности 10 раз не вытянещь. Остается предположить что в Java более удобные библиотеки - но это уже субъективный фактор, а не достоинство языка.
Мой знакомый делавший бизнес-приложениями на Java несколько лет назад говорил, что на .net он бы разработал серьезное приложение раза в 2 быстрее чем на Java (потому что .net появился позже и исправил неудачные моменты), но он будет писать на Java опасаясь непредсказуемости Microsoft.
no subject
Date: 2007-05-17 12:22 pm (UTC)Насчёт GUI говорю из опыта. Я очень долго работал с GUI на C++ под Windows (ещё даже под Windows 3.1). С Borland OWL, потом с MFC. Начинал даже с чистых Windows, без всяких оболочек. Так вот, очень хорошо помню ощущение радости от каждого открытого окна. Вот буквально так: сумел открыть окно - радуюсь. А потом этот кошмар с GDI, когда нужно что-то нарисовать; все эти нелепейшие функции, идиотские параметры у них. В общем, настоящая травма.
Когда я начал писать GUI на Java - это было такое невероятное улучшение жизни, что словами не описать. За час можно сляпать целую программу, которая будет делать что-то полезное, а главное - всё будет работать без всяких проблем.
Конечно, сам язык и платформная независимость здесь ни при чём. Просто хорошо разработанные библиотеки, в которых спрятана вся чёрная работа. Ну и ошибки памяти отсутствуют, что тоже немаловажно.
На .NET я не работал, хотя подозреваю, что там это тоже всё очень удобно. Только я думаю, ваш знакомый имел в виду не их библиотеки (насколько я знаю, они не очень отличаются), а Visual Studio. Это прекрасная среда, ничего не скажешь.
no subject
Date: 2007-05-16 04:18 pm (UTC)http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
no subject
Date: 2007-05-16 11:43 pm (UTC)no subject
Date: 2007-05-17 09:43 am (UTC)We should not replace established languages
Date: 2007-05-18 03:06 pm (UTC)"Alternatives that replace these [established] languages with entirely new syntax, such as Erlang or Ada, have not taken root, and probably will not... The message is clear. We should not replace established languages. We should instead build on them."
Loose Coupling
Date: 2007-05-17 05:38 pm (UTC)Loose coupling - это палка о двух концах. Потому как очень часто под loose coupling понимают не отсутствие зависимости, а загоняние зависимости вглубь и превращение ее в неявную. Скажем, путем удаления статических проверок как в VBScript'е. Или путем создания супер-абстрактных интерфейсов. Типа, давайте будем вызывать всё и вся через методы такого вот рода:
void* DoIt( char* operation, void* data ); // C++
object DoIt( string operation, object data ); // C#
и будет у нас стандартный и всё умеющий интерфейс на все случаи жизни - апофеоз loose coupling. Такого рода идеи встречаются не только среди новичков но и среди достаточно опытных и умных программистов.
В DDJ недавно была статья про такие неявные зависимости: http://www.ddj.org/dept/architect/196802793
За такими штучками надо очень тщательно следить, причем совершенно неясно как это автоматизировать.
> Для этого существует паттерн Inversion of Control -
> почему бы не встроить его в язык ?
Inversion of Control, как и любой другой прием, хорош в меру. Скажем, если использовать IoC средства типа Spring на полную катушку, то объекты становятся очень автономными и loosely coupled, но в результате основная логика программы постепенно перемещается в другое измерение - в "конструктор", который соединяет loosely-coupled объекты между собой. По достижении определенного уровня сложности получаем те же проблемы, что и раньше, но уже на уровне конструктора.
Кроме того, конструктор получается tightly coupled со всей остальной программой - он ведь должен знать про все конструируемые объекты и их взаимосвязи. Если конструктор имеет вид интерпретируемого XML файла как в Spring - то это катастрофа: язык конструктора получается громоздкий, и к тому же интерпретируемый в ран-тайм - его и на ошибки-то никто толком не проверяет.
С другой стороны, никто не мешает писать конструктор прямо на Java/C#, со статическими проверками во время компиляции - все нужные средства уже встроены в язык. Но тогда мы получаем традиционные проблемы компилируемых языков - что-то поменять в программе может только ограниченный круг людей, у которых есть компилятор и IDE. "Встраивание IoC в язык" вряд ли разрешит эту проблему. Или, может, я чего-то не понимаю? Как такое встраивание может выглядеть? Ведь все нужное там уже, по большому счету, есть. Надо что-то автоматизировать? Завести какие-то новые ключевые слова?
Re: Loose Coupling
Date: 2007-05-17 11:58 pm (UTC)Насчёт всего этого я уже довольно долго думал.
Как я и написал, у меня накопились кое-какие идеи насчёт того, что можно было бы сделать в этом направлении. Идеи довольно наивные ещё, но я всё же хочу их как-нибудь изложить. И мне будет очень интересно узнать ваше мнение.