[comp.prog] Вдогонку ко вчерашней заметке о фокусах распределенного программирования

В комментариях ко вчерашней заметке Дмитрий Вьюков поделился несколькими ссылками. Ссылки ценные, поэтому выношу их в отдельную заметку.

Time, Clocks, and the Ordering of Events in a Distributed System. Статья Лесли Лампорта от 1978-го года, в которой он описывает такие вещи, как понятие “happened before”, частичное упорядочение, логические метки времени, полное упорядочение и т.д.

Оттенки FIFO. Статья самого Дмитрия Вьюкова, в которой он сравнивает различные типы FIFO (Causal FIFO, Per-producer FIFO, Best-effort FIFO, No FIFO).

От себя рекомендую книгу Распределенные системы. Принципы и парадигмы.

Ну и в качестве шутки юмора хочу рассказать анекдот, который, по-моему, попадает в тему комментария ув.тов.Skynin:

Я прикладник, всю эту распределенность-асинхронность наблюдаю сверху. И нередко - да какой угодно дай ЯП, платформу - я просто понять не могу, как же увязать такую-то схему работы.
Ну а после того как придумал - начинается подбор - UUID не UUID, иерархическая, или анархическая :) и т.д.
А когда платформа не дает возможности, начинается заталкивание в иерархию анархии, и создание иерархии в анархии :)

Вобщем нравится мне моя область. А вот то о чем ФПшники говорят - скукота. Им наверное наоборот

Так вот, анекдот:

Лето, пляж. На пляже культурист демонстрирует свое тело – накачанные руки, ноги, спина, пресс. Вдруг к культуристу подбегает маленький толстенький мужичок и говорит:
-- Парень, у тебя шишки на руках, тебе лечиться нужно!
-- Это не шишки дядя! Это мускулы, это бицепсы, трицепсы. Это девушкам нравится. Отвали!
-- Парень, да у тебя на животе шишки, тебе лечиться нужно!
-- Это не шишки дядя! Это мускулы, это пресс. Это девушкам нравится.
Тут мужичок достает толстенную пачку долларов, демонстрирует ее культуристу и говорит:
-- Вот это пресс, вот это девушкам нравится. А у тебя шишки, тебе лечиться нужно!

Почему анекдот в тему? Ну, пока ФПники прокачивают свой мозг, все остальные зарабатывают :)

[comp.prog.thoughts] Фокусы распределенности: ответ приходит раньше, чем уходит запрос ;)

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

Представим себе, что есть покупатель (система P), магазин (система M) и склад (система S). Покупатель делает заказ в магазине, магазин выдает заказ на склад, а склад выдает покупателю информацию о сроках поставки заказа. Грубая схема такова:

• от P в M идет синхронный запрос pay;
• M выполняет у себя какие-то действия и возвращает P ответ pay_ack;
• от M в S идет запрос deliver, в котором лежат координаты P;
• S отсылает P запрос deliver_schedule.

Так вот, если M связывается с S до того, как отошлет pay_ack в P, то P может получить deliver_schedule еще до того, как М отправит в P pay_ack. Более того, даже если M отсылает в S запрос deliver после отсылки pay_ack в P, все равно deliver_schedule может придти к P раньше, чем pay_ack!

Что в этом фокусе страшного? Страшное начинается при попытке понять, к какому именно заказу относится deliver_schedule :)

В самом плохом случае в pay_ack может лежать некий уникальный ID заказа от M. Этот же ID заказа будет и в deliver_schedule. Но для P он окажется неизвестным, т.к. pay_ack до него еще не дошел.

Получается картинка: P инициировал pay и ждет ID заказа, тут к нему приходит deliver_schedule с неизвестным ID заказа. Что же с ним делать? Логировать сей печальный факт и выбрасывать. Потом получать pay_ack, фиксировать ID заказа в БД и ждать deliver_schedule. Который не больше не придет :)

Причем здесь распределенность? При том, что P в современных условиях может быть реализован в виде нескольких (десятков, сотен) автономных процессов, работающих на разных компьютерах. Поэтому простые схемы, когда P не обрабатывает deliver_schedule из-за того, что он заблокирован на ожидании pay_ack, уже не пройдут. Се ля ви.

PS. Простое решение здесь состоит в том, чтобы P мог отказываться принимать deliver_schedule с неизвестным ID. И чтобы в этом случае S перепосылал deliver_schedule через какое-то время. Но, если S не может этого делать, то P придется что-то предпринимать самому (скажем, фиксировать неизвестные ему deliver_schedule и при получении pay_ack проверять их).

PPS. А еще в распределенных системах pay_ack может просто теряться из-за сбоев оборудования или рестартов компонентов. Так что простые двухфазные обмены вроде pay/pay_ack, deliver_schedule/deliver_schedule_ack не есть хорошо. А многофазные схемы снижают пропускную способность и увеличивают время обработки, что так же не есть хорошо.

PPPS. Схема с покупателем, магазином и складом приведена просто для иллюстрации.

[life.photo] Парит? Плывет?

Полное впечатление, что человек парит в воздухе:

В действительности он плывет. Но из-за снегопада воды не видно.

Найдено в очередном выпуске WSJ’s Picture of the Day.

[comp.prog] Начал было делать обзор языка Go…

…но забабахался.

Хотел сделать краткий обзор на русском языке, на манер того, что я написал для Zimbu. Для этого прочитал разделы Tutorial, Effective Go и Go for C++ Programmers в документации на сайте языка Go. Самыми толковыми мне показались как раз Effective Go и Go for C++ Programmers. По крайней мере какое-то целостное впечатление о языке у меня сложилось именно после них. Поэтому решил просто пересказать Effective Go и, метами, Go for C++ Programmers своими словами, но с чужими примерами.

Однако, кавалерийского наскока не получилось. На половине Effective Go я сдался. Слишком много и слишком неинтересно. Не зацепил меня язык. Поэтому желание рассказывать о нем сильно поубавилось. То, что получилось, выложил на своей народной страничке. Если кому-то интересно – можно посмотреть.

Не очень приятно, что выкладываю в свободный доступ незаконченную работу :(
Но, боюсь, в вялотекущем режиме я закончу эту пересказ не скоро, когда этот язык уже никому не будет интересен. Так что лучше я буду обновлять описание по мере его написания.

PS. Кстати, Zimbu меня торкнул гораздо круче, чем Go.

[comp.prog] Python таки заморозили

В продолжение темы “Заморозят ли развитие языка Python”: заморозили таки! Принят документ PEP 3003, объявляющий мораторий на любые изменения в синтаксисе, семантике и встроенных функциях языка Python. Мораторий начнется с выхода Python 3.1 и продлится не менее двух лет (в течении которых планируется выпустить Python 3.2). Т.е. следующие изменения в языке возможны только с Python 3.3.

Оперативно работают, респект!

[comp.prog.thoughts] Язык с GC – это уже платформа?

Неожиданно подумалось: код с ручным управлением памятью можно внедрить практически в любой язык с GC. Например, биндинги к C-ным и даже C++ным библиотекам есть для большого количества языков с GC (см., например, биндинги к libcurl). Тогда как объединение в одном приложении нескольких языков с GC – это уже сложнее. Скажем, часто ли вам приходилось видеть комбайны, в которых в рамках одного процесса работали Java, C, Python и Ruby? Сколько клея (glue code) нужно написать, чтобы на объект из Ruby-новой части можно было ссылаться из Python и Java частей и наоборот?

Получается, что для эффективного использования нескольких языков с GC в одном процессе необходимо, чтобы все эти языки делили общий GC. Т.е., чтобы они работали на общей платформе. Каковыми сейчас являются, пожалуй, только JVM и .NET.

PS. Вспоминается старый афоризм: Java – это не кроссплатформенный язык, Java – это платформа.

[comp.prog.humour] Хорошая шутка про язык Go

Уже появилась на LOR-е:

Пишущие на нём будут, я так полагаю, Goпниками?

Классно: С-шники, C++ники, Ruby-исты, Lisp-еры, Go-пники!

[comp.prog.thoughts] Поиграю в оракула по отношению к новым языкам программирования

В недавних обсуждениях появилось несколько комментариев, которые достойны того, чтобы поговорить о них отдельно. Особенно в свете появления новостей о языке Go от Google (документацию о котором я изучаю, чтобы затем высказать свои впечатления).

Комментарий ув.тов.breezsea:

Думаю, что языкам программирования уделяют слишком много внимания. С ужасом наблюдаю, как на форумах/в блогах и т.д. начинаются священные войны/многостраничные срачи и т.д. в попытках найти несуществующий идеал. Еще более смешным выглядит объявление о создании еще одного нового и никому не нужного языка программирования (последний пример - Zimbu от Брана Мулинара). Проблема в том, что в языках программирования всё уже придумано. Изобрести что-то действительно новое и полезное крайне трудно. Меня всегда интересовал и интересует вопрос: какими соображениями руководствуются очередные велосипедисты при создании своих поделок?

Комментарий ув.тов.Quaker:

Я считаю, что в языках программирования гораздо важнее даже не сам язык, а большое количество готовых библиотек, кроссплатформенность, полноценная IDE с графическим интерфейсом, интеграцией с CVS/SVN и т.д. В общем, вспомогательные вещи, не имеющие к синтаксису языка прямого отношения.

Оба комментария, на мой взгляд, затрагивают один важный вопрос: “Поскольку сами по себе фичи языка и его синтаксис не столь уж и важны, но почему же появляется такое количество новых языков программирования?” Но интересен не только этот вопрос, но и его логическое продолжение: “Что ждет новые языки?” или, в более интересной для программиста формулировке, “Какой из них станет Next Big Language?” Однако, пойдем по порядку.

Насколько я понимаю, новые языки программирования делятся на две категории. Первая категория – это экспериментальные языки, которые создаются своими авторами для проверки каких-то идей. Например, таковыми языками были Pizza и Funnel, на которых обкатывались идеи, впоследствии реализованные в Java и Scala. Вторая категория – это языки, которые создаются своими авторами как рабочие инструменты. Например, языки C, C++, Eiffel, Perl, Java, Python, Ruby, C#.

Полезность языков из первой категории, по-моему, очевидна. Это прототипы для обкатки новых идей или новых сочетаний ранее известных вещей. Такие языки не претендуют на переход в разряд “рабочих лошадок”, их авторы не заботятся разработкой большой стандартной библиотеки, необходимых разработчику инструментов (редакторов, отладчиков, профайлеров и пр.), им не важен размер сообщества пользователей языка.

Единственная опасность, связанная с экспериментальными языками – это горячие головы, которые решают продвигать экспериментальный инструмент в качестве рабочего. Собственно, это не проблема языка. Это проблема тех, кто попадается на такую удочку.

Полезность языков из второй категории должна была быть очевидной. По идее должна быть. Ведь рабочий язык предназначен для того, чтобы было легче, дешевле и быстрее решать какие-то практические задачи, стоящие перед обычными программистами. Понадобился эффективный язык, уровнем повыше ассемблера – появился C. Понадобился еще чуть более высокоуровневый язык, чем C – появился C++. Потребовался безопасный C++ – появился язык Java. Потребовалась заточенный под Windows вариант Java – появился C#. И т.д.

Казалось бы, все здорово, больше языков – хороших и разных! Однако, если появление новых экспериментальных языков – это действительно хорошо, то появление новых рабочих языков, особенно универсальных языков общего назначения – это штука неоднозначная.

С одной стороны, существующие рабочие языки не идеальны. В каждом из них есть изъяны, которые хотелось бы устранить, но нельзя этого сделать, т.к. нельзя терять совместимость. А вот новый рабочий язык мог бы взять лучшие качества из уже существующих, но оказаться лишенным их недостатков. Вот тот же Zimbu – когда читаешь мотивацию принятия тех или иных решений, то все получается складно. Zimbu мог бы стать вполне хорошей заменой C, C++ и D. Мог бы, если бы не одно но.

Очень большое “но”, которое является обратной стороной новых рабочих языков программирования. Рабочему языку нужны инструменты (начиная от библиотек, заканчивая различными анализаторами и “украшателями” исходного кода), нужны информационные ресурсы, нужно большое и живое сообщество. Все это не возникает просто так. На создание библиотек и инструментов нужны огромные ресурсы и время. На создание сообщества нужно время и еще что-то. И все это при том, что в языке будет что-то, что зацепит пользователей (что бывает очень далеко не всегда).

В современных условиях создание нового рабочего языка, для которого стандартная библиотека будет разрабатываться с нуля, для которого будут писаться новые IDE, новые отладчики, новые профайлеры и т.п. – это утопия. Слишком много всего нужно иметь современному разработчику “здесь и сейчас”. Не будет никакого толку от языка, защищающего от обращения по нулевым указателям и гарантирующим не выход индексов за пределы массивов, если для этого языка нет Regexp-ов или средств построения GUI.

Такой язык может стать флагом какой-то группки энтузиастов, для которых целью является использование именного этого языка, а не какого-то другого. Или же язык может занять какую-то узкую нишу, где его качества будут решающим преимуществом, а маленькая стандартная библиотека не будет проблемой (как сейчас происходит с Modula-2, Ada и Eiffel). Но мейнстримом он не станет. А посему, лично для меня такой язык представляет чисто академический интерес – пролистать документацию и посмотреть примеры интересно, но использовать я его не буду.

Совсем другое дело, когда новый рабочий язык позволяет бескровно и бесплатно использовать уже существующие библиотеки и средства разработки для других языков. Например, как C++ в свое время позволил использовать C-шные библиотеки. Как Scala сейчас позволяет использовать JVM, как Nemerle позволяет использовать .NET Framework. Тогда для нового языка все не так плохо. Тогда разработчик действительно может получить выгоды и от тщательно отобранных языковых возможностей, и от унаследованного кода.

Но! Такой новый рабочий язык должен дать разработчику что-то такое, что действительно оправдает переход на него с мейнстримового языка. Например, был интересный язык Nice, который предоставил возможности обобщенного программирования и мультиметоды для JVM еще до того, как в Java появились generic-и. Но Nice не выстрелил. Даже не смотря на очень простую интеграцию с Java. Видимо, преимущества языка не оправдывали отказа от Java. Тогда как Scala потихонечку набирает популярность. Поскольку функциональные возможности Scala, имхо, оправдывают переход на Scala.

Еще один фактор: новые рабочие языки не могут появляться слишком часто. Существует мнение, что мейнстримовый язык меняется раз в десять лет. Поэтому, если новый рабочий язык для какой-то платформы (JVM или .NET) появляется, когда основной язык этой платформы “на коне”, то шансов привлечь к себе внимание и пользователей у него не много. Ведь основной язык пока справляется со своими задачами, его недостатки пока не набили оскомину, у многих пользователей еще не прошло восхищение неофитов. Тем более, что в это время сам язык еще активно развивается и пополняется новыми возможностями. Опять можно вспомнить Nice, который появился в начале 2000-х, как раз когда Java был близок к своему пику. И вскоре после рождения Nice в Java были добавлены generic-и. Совсем другая ситуация сейчас для Scala.

Так вот, пора подводить итог. На мой взгляд, у новых рабочих языков, которые не привязаны к какой-то платформе, нет шансов стать хоть сколько-нибудь заметными игроками. Если только какая-нибудь мегакорпорация не захочет вбухать N сотен миллионов долларов в создание большой стандартной библиотеки и инструментов для разработки (что маловероятно).

Значит, новые рабочие языки должны появляться для распространенных сейчас платформ. К коим можно отнести, в первую очередь JVM и .NET. Но не только. Не следует списывать со счетов C/C++ наследие – т.е. потенциально возможно(?) создать “улучшеный С++”, который сможет использовать мегатонны уже существующего С/C++ кода (что-то типа D или Vala). Так же, наверное, не исключено создание новых языков и для Erlang VM (например, Reia). А может быть, и для Ruby или Python (хотя смысла в этом я не вижу), или даже для OCaml с Haskell-ем :)

Итого: языки типа Zimbu и Go обречены оставаться экзотикой. Языки типа Scala или Fan, или Cobra – вполне могут стать широковостребованными рабочими лошадками (может и не вытеснят основные языки Java/C#, но свое место под солнцем отвоевать смогут). Другой вопрос – нужно ли использовать их? Scala вместо Java я бы рискнул попробовать. Но тут уж каждому предстоит решать самому.

[life.humour] Happiness hat

Не могу не перепостить:

happiness hat from Lauren McCarthy on Vimeo.

Найдено у Кодт-а.

[comp.prog.thoughts] Маленький прием, позволяющий идентифицировать reusabe-кода

По мотивам обсуждения заметки Code reuse в блоге Алёна C++.

Повторное использование кода – это сложный вопрос. Он сложен даже для маленьких команд. Еще сложнее он в больших командах и больших организациях с развитой бюрократией. Но здесь у меня мало опыта. Поэтому я расскажу всего об одном простом приеме, который позволяет выявить повторно используемый код.

На мой взгляд, повторно используемый код бывает двух типов. Первый тип – это код, для которого с самого начала понятно, что он может использоваться в нескольких местах. Как правило, это библиотеки, решающие какие-то четко определенные задачи: алгоритмы сортировки, генераторы случайных чисел, регулярные выражения, средства работы с БД и даже большие фреймворки вроде MFC, Qt или wxWidgets. С этим типом кода все понятно.

Второй тип – это код, о котором изначально не думали как о повторно используемом. Но который затем распространяется между проектами посредством copy-and-paste и, тем самым, приводит к дублированию.

Такой код пишется для решения какой-то конкретной прикладной задачи. Например, в модуле приема данных по сети возникает необходимость залогировать фрагмент сбойного пакета. Для чего разработчик пишет несколько вспомогательных процедур, возможно, завязывая их на конкретный тип логгера.

Если потом в другом модуле потребуется выполнить аналогичное логирование, то другой разработчик может взять процедуры логирования, написанные первым разработчиком. В лучшем случае они заработают без изменений (все-таки в рамках одного коллектива вряд ли будут использоваться разные логгеры), в худшем – потребуют небольшой доработки напильником.

По хорошему, уже на этой стадии было бы разумным выделить скопированный из другого проекта код в повторно используемый компонент (библиотеку или сниппет). Но это в идеале, на практике все может быть сложнее. Особенно, когда ты берешь код из чужого проекта, из его зафиксированной версии.

Итак, фрагмент чужого кода взят к себе. Потенциально, он может потребоваться еще раз, но об этом пока не известно. Имеет смысл специальным образом пометить этот фрагмент. Ведь когда он потребуется еще раз, то разработчик будут знать, что код уже был скопирован ранее. Я помечаю такой код комментарием:

//FIXME: данный код взят из проекта XYZ.
...

И, когда мне приходится копировать его еще в одно место, данный комментарий напоминает мне, что однажды я уже поленился или не смог выделить его в повторно используемый компонент. Значит, если сейчас для этого есть шанс, я должен этот шанс реализовать.

Примечание 1. По хорошему, аналогичный комментарий следовало бы ставить еще и в месте, откуда фрагмент кода был взят. Но это не всегда возможно.

Примечание 2. Наверное, кроме метки FIXME, стоило бы снабжать такой код еще какой-то легко запоминающейся меткой. Например, REUSE. Но у меня эта практика не прижилась, т.к. есть привычка помечать код, подлежащий дальнейшей доработке маркером FIXME (он, кстати, выделяется в ViM-е другим цветом), а дополнительные маркеры я забываю ставить.

Примечание 3. Опыт показывает, что если код был скопирован один раз, то не обязательно он окажется повторно используемым. Зачастую бывает, что в дальнейшем как оригинальный, так и результирующий несколько раз меняется и развивается в противоположных направлениях. Поэтому лучше дождаться, пока код будет скопирован без значительных изменений в третий раз.

Примечание 4. Для того, чтобы найти исходный фрагмент кода для copy-and-paste, нужно знать, что он есть :) В собственных проектах с этим еще как-то можно разобраться. А вот с чужими как быть? Временами спасает процедура code review. После того, как выполнишь рецензию чужого кода в голове останутся воспоминания о его содержимом. В нужный момент они могут сработать.

[comp.prog] Статья “On Iteration” от Андрея Александреску

Большая статья на английском On Iteration в informIT, в которой Андрей Александреску описывает свой взгляд на итераторы (который он активно пытается претворить в жизнь в стандартной библиотеке языка D).

[comp.prog] Презентация Message-Passing Concurrency in Erlang от Ulf Wiger

27-ми страничная PDF-ка на 6Mb: Message-Passing Concurrency in Erlang.

Предупреждение. Для знакомых с Erlang-ом людей она может оказаться повторением уже известных вещей. Для не знакомых с Erlang-ом – малопонятной.

Меня впечатлила в презентации диаграмма производительности на 64-х ядерном процессоре Tilera Pro (это процессор той компании, которая недавно анонсировала 100-ядерный процессор).

PS. Чем больше смотрю на примеры Erlang-овых программ, тем больше меня терзает мысль, что это такой write-only язык: уж очень гремучей смесью выглядит функциональное программирование на динамически-типизированном языке.

PPS. Кстати, чтобы получить еще большее представление о специфике задач, для которых создавался Erlang (и о сложных конечных автоматах на Erlang), можно посмотреть еще и эту презентацию: Structured Network Programming того же автора.

[life.science_vs_religion] О какой борьбе с лженаукой может идти речь?

Вчера случайно посмотрел по каналу РТР передачу Марии Ситтель о лженауке. О том, как в России сейчас процветает массовое надувательство с использованием “торсионных полей”, “вихревых двигателей” и прочей лабуды. В студии присутствовали двое пожилых ученых, входящих в совет по борьбе с лженаукой. Они жаловались, что пытаются писать разоблачительные статьи, но статьи оказываются публиковать в СМИ. Что они пытаются наладить экспертизу предлагаемых к внедрению в народном хозяйстве технических “чудес” в Академии Наук, но на это никто не идет. О том, что люди массово ходят на сеансы к “целителям” и “парапсихологам”, но нет возможности публично разоблачать подобных шарлатанов.

А я не понял одной штуки: о какой борьбе с лженаукой, да и вообще о борьбе с мракобесием, может идти речь если религия в России уже является чуть ли не государственным институтом. Первые лица государства не скрывают, что они верующие люди. Государственные чиновники посещают церковные праздники и это показывают по центральным телеканалам. В школах вводят преподавание чуть ли не “Слово Божие”.

О какой борьбе с лженаукой может тогда идти речь, если религия, фактически, поддерживается государством? Грубо говоря, зачем учить людей вещам, типа числа “пи” или “е”, объяснять, откуда они взялись и какое значение имеют, если на все “воля Господа”? Если все сотворено Богом, то почему бы синусу 90 градусов не принимать значение 2 или 3, или даже, в период особо важных праздников, 4?

Маразм крепчал, короче.

PS. Вспоминаю одну историю, которая произошла где-то в 1991. Лето, пора вступительных экзаменов. Еду в троллейбусе, рядом со мной разговаривают две девушки-абитуриентки:
-- Завтра же экзамен, ты что-нибудь учила?
-- Нет.
-- И я нет. Значит сегодня в церковь пойдем!

PPS. Статья в тему: Мысли о науке, религии и современной культуре.

[comp.wow] Супертонкий ноутбук Dell Adamo XPS – меньше 10 мм толщиной

1.4GHz Intel® Core™ 2 Duo ULV, 4Gb RAM, 128Gb SSD, 13.4” (1366x768), Wi-Fi a/g/n. Толщиной от 9.7 до 10.3мм.

А вот как эта штука выглядит на видео:

Как же эта штука не падает? ;)

[comp.prog] Впечатления от интервью Джона Хьюза

На RSDN дали ссылку на интервью Джона Хьюза (вот прямая ссылка на интервью) – одного из разработчиков языка Haskell и автора инструмента QuickCheck.

Дядька явно умный, представитель т.н. академических кругов. Местами здравомыслящий:

Например, если вы посмотрите на Haskell, то есть определенные области программирования, в которых Haskell по настоящему превосходен, и есть другие области, в которых он совершено не подходит. Так, я не думаю, что Haskell полностью заменит C.

С другой стороны, он говорит:

…когда я начинал, мейнстримом были, наверное, Fortran и COBOL, и даже C был довольно новой штукой в то время. Пионеры функционального программирования говорили об увеличении производительности на порядок и я думаю, что функциональное программирование это обеспечило.

Если вы сравните Haskell-программы с C-кодом или даже C++ то часто они на порядок меньше и проще. Тоже самое и для Erlang, что сейчас находит подтверждение в индустрии.

Как-то это не очень согласуется между собой. Разве что во второй цитате он говорит об областях, где у Haskell/Erlang нет конкурентов. Что свойственно ученым: из всех имеющихся фактов ученым свойственно упоминать лишь те, которые доказывают их гипотезу ;) (старая шутка).

Хьюз говорит, что Haskell очень хорошо позволяет создавать DSL-и и это является одной из сильных сторон языка. Как по мне, так DSL-и (особенно internal DSL-и) не есть хорошо. Да, сейчас вокруг них существует много шума. И в каких-то областях DSL-и действительно очень полезны и важны (те же Regexp-ы или IDL-описания). Но это эпизодические случаи, которые имеют очень четкие границы применения. Однако, имхо, мало кто знает, во что превратиться программирование, когда большие программы будут собирать из десятков и даже сотен разношерстных DSL (как сейчас это происходит с библиотеками). Lisp-ы вот так же были хороши в DSL-естроении…

Довольно смешно было читать про то, как перейдя к программированию в среде с побочными эффектами (коей является Erlang), ему пришлось вспомнить, как же тяжело выискивать баги, вызванные побочными эффектами. Мол, столько лет я писал на чисто функциональном Haskell-е, а тут в Erlang-е приходится по нескольку часов заниматься отладкой, чтобы найти багу…

Да, кстати, приходится программировать на Erlang-е Хьюзу потому, что у Erlang-овской версии QuickCheck есть пользователи. Тогда как на Haskell-е в индустрии не больно-то заработаешь ;)

Вот чего я не понял в его рассказе, так это следующего фрагмента:

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

Не представляю я, как над кодом, задачей которого является производство побочных эффектов, можно построить интерфейс без побочных эффектов? Туп-туп. Буду признателен, если кто-нибудь сможет разъяснить мне это на пальцах или хотя бы выскажет идею на этот счет.