Что общего у Haskell и Apple

Посетило вдохновение, написал пост. Милости просим:
http://vshabanov.livejournal.com/845.html

RSS-читалка с комментариями

Как часто вы, читая RSS-подписки, переходите на страницу поста, чтобы посмотреть комментарии?

Дискуссии в комментариях нередко оказываются интереснее самого поста. Однако почти все современные RSS-читалки не уделяют комментариям никакого внимания.

Чтобы исправить эту ситуацию, я решил сделать свою читалку (с блекджеком и всем остальным ;)

BazQux Reader — RSS-читалка с комментариями.

Работает с блогами, имеющими rss-потоки для комментариев (т.е. wordpress, blogspot и многие другие). Поддерживает ЖЖ (с аватарками и тегами). И даже RSDN деревцем выводит ;)

Управляется с клавиатуры (нажмите 'h', чтобы посмотреть список клавиатурных сокращений), мышкой кликать тоже можно.

Умеет искать, группировать результат поиска по постам, выводит найденные комментарии деревом, а не плоским списком вперемежку.

15 подписок бесплатно, неограниченное число подписок $30 в год.

В процессе использования BazQux Reader, я обнаружил много интересных обсуждений в комментариях, которые врядли бы прочитал, щелкая каждый раз по постам в обычной RSS-читалке.

Попробуйте, вам понравится ;)

Всячески приветствую ваше мнение по поводу читалки.

(Кросспост в ЖЖ, для тех, кому удобнее)

Язык имеет значение

Все мы слышали, что есть Хаскел. Все мы знаем, что он крут. Крут настолько, что многие его даже боятся.

Все мы знаем, что программы на Хаскеле короче и быстрее пишутся. Те, кто писал на Хаскеле, уже с трудом могут заставить себя использовать другой язык.

Так какого черта мы пишем на чем-то другом?

Мне кажется, мы просто ссым!

Почему? Чем мы себя обманываем? Почему боимся «рисковать», когда риск заключается как раз в неиспользовании Хаскела?

Лично я сыт по горло от собственных же отмазок. Проведя анализ ВСЕХ своих проектов, сделанных за последние 9 лет, я пришел к выводу, что ВСЕ они (кроме драйверов и прошивок микроконтроллеров) могли бы быть сделаны на Хаскеле.

Но это не самое страшное. Самое страшное — это сколько времени было потеряно на низкоуровневые языки.

В проектах, написанных на C++, можно было бы сэкономить 30-40% времени разработки (а при наличии готовых библиотек, еще больше). Страшно вспомнить, сколько я их отлаживал, и, все равно, раз в месяц программа таки падала.

В проектах, написанных на C++, питоне и окемле, можно было бы срезать до 20-25% времени, только за счет отказа от С++ и питона. Переход на Хаскел дал бы еще минимум 10%.

Кстати, запомните — C++ и питон нужны только для того, чтобы подняться уровнем выше C. Если вы уже используете более высокоуровневый язык (окемл или хаскел), то за использование чего-либо, кроме C для самых критичных мест, надо сильно бить себя по рукам — вы просто тратите время зря. Все, что выше C надо писать на Хаскеле, а не С++.

Даже учтя, что последние 9 лет я не только работал, но еще и ходил в техникум и институт, все равно я потерял минимум 1.5 года жизни из-за ничем не оправданного применения С++ (и еще пару месяцев из-за питона). Я идиот. Не повторяйте моей ошибки, и не ссыте применять то, что действительно удобно, приятно и позволяет решать задачу, а не проблемы.

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

А пока, если вам дорога ваша жизнь, и не хочется тратить ее попусту, используйте Хаскел. Точка.

PS для менеджеров: вам дороги сроки сдачи проекта? Уже догадались, что надо использовать, а чему сказать нет?

Concepts, Techniques, and Models of Computer Programming

Вот я и стал счастливым обладателем CTM.

Володя, что это за книжка? — спросите вы.

Отвечаю: “Concepts, Techniques, and Models of Computer Programming” — пожалуй, самый полный набор самых полезных идей в программировании.

Все мы знаем, что есть функциональное программирование, логическое, объектно-ориентированное. Есть ленивые вычисления, строгие. Есть concurrency с message passing, есть с shared state. Бывает недетерминизм, бывает программирование в ограничениях, да чего только не бывает.

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

Вот для наведения порядка в голове и нужны такие книги.

Авторы поставили перед собой задачу последовательно, шаг за шагом, изложить самые распространенные и полезные концепции в программировании.

Начинают с декларативного программирования (в их варианте чуть больше, чем чисто функциональное или prolog без поиска), переходят к concurrency (сначала message passing), потом добавляют состояние, объекты, shared state concurrency, доходят до логического программирования, а дальше и до распределенного программирования и программирования в ограничениях. И все это только концепции (можете называть их парадигмами, хотя авторы предпочитают более строгое «вычислительная модель»). А к каждой концепции прилагается еще и куча техник.

В отличии от SICP, в CTM не дается реализация всех моделей с нуля, что несколько расстраивает, т.к. не достигается такой уровень понимания. В книге используется kernel language подход, где для объяснения очередной вычислительной модели выбирается минимальное подмножество языка и объясняется семантика этого подмножества. Из-за такого подхода иногда появляется ощущение, что читаешь лекционный материал, а не семинарский (как SICP). С другой стороны CTM — учебник для 2-го курса — тут надо не только кодить учить. А чтобы рассказать обо всех идеях, используя подход SICP (interpreter approach, по их классификации), пришлось бы раздуть 900 страниц (в формате 20х25 см) тысяч до 3-х.

В качестве языка авторы используют собственную разработку — язык Oz. Но как SICP не является учебником по Scheme, так и CTM — не учебник по Oz. Это книги по Программированию.

В общем, книга явно must read, особенно для тех, кто еще совсем не знаком с изложенными в ней идеями и не собирается учить десять языков, чтобы в них разобраться.

Пойду читать дальше, чего и вам желаю.

Требуется программист на удаленную работу

Здравствуйте, уважаемые читатели! А вот кого из вас интересует удаленная работа на Erlang-е? (не откажусь и от OCaml или Haskell, хотя они, скорее всего, меньше подходят для задачи).

В чем суть.

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

Краткое ТЗ.

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

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

И нужен еще отдельный клиент для забивания информации в базу (для начала тоже консольный, впоследствии может дорасти до веб-интерфейса).

Главное.

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

Детали.

Работа удаленная. Бюджет $4-5k (обсуждаемо). На разработку дается 3 месяца (желательно, конечно, быстрее). Далее поддержка (за отдельные деньги).

Желательно, чтобы кандидат уже имел опыт создания клиент-серверных приложений. Не обязательно на Erlang.

Звоните: ...
Пишите: ...

Вопросы и комментарии приветствуются.

А кросс-постинг в заинтересованные сообщества приводит в восторг ;)

Correct by construction

Существует много приемов, способов и методологий разработки программ. Один из них, не самый заезженный, но очень полезный — это Correct by construction. Суть его проста до безобразия: корректную программу можно построить только из корректных частей, корректно соединяя их друг с другом.

Заметьте, в этой фразе, слово корректную можно заменить на практически любое положительное прилагательное, а слово программу — на любое существительное (попробуйте: надежный автомобиль, точный станок, хороший дом).

И если про корректные части более менее понятно (они должны быть корректными и все тут), то момент корректного их соединения является несколько туманным. Попробуем разобраться.

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

Здесь я говорю не о «защите от дурака», когда система не реагирует на неверное использование, а о том, чтобы вообще не допустить этого «дурака» к системе. А если нет дурака, то не нужна и защита от него.

Кстати, под интерфейсом я понимаю не только набор методов в классе, или функций в модуле, но еще и элементы языка программирования, ведь они тоже соединяют элементы программ (кстати, ни один из известных мне языков программирования не поддерживает полностью принцип Correct by construction, хотя некоторые и стремятся).

Что же подразумевается под корректными интерфейсом? Да собственно такой интерфейс, который физически нельзя использовать не по назначению. Примеры:

• Если функция, в случае ошибки, возвращает -1, NULL, или любое другое магическое значение, то когда-нибудь это значение не будет обработано. А если функция возвращает опциональный тип (option, Maybe, или как он называется в вашем языке), то возможность забыть обработать ошибку отпадает сама собой.




• Прямая работа с указателями или массивами в принципе не может дать гарантий безопасной работы с памятью. Но если к массивам можно достучаться только через функции вроде map, fold, iter, то no problemo: нет индексов — нет ошибок с индексами (а в будущем, надеюсь, проблема безопасного доступа к массивам по индексам решится при помощи dependent types).




• Наличие явных функций open/close, create/destroy, alloc/free всегда оставляет возможность не освободить занятый ресурс. А если использовать RAII или функции типа with_resource, то у потенциального «дурака» в принципе не получится что-то забыть &mdash ведь не он теперь заведует ресурсом.




• У вас много изменяемого состояния. Боитесь, что кто-то изменит его не в том порядке? Разбиваем на кусочки, делаем функциональный интерфейс, и уже ни у кого не получится перепутать вкл. и выкл.




• Нельзя нажать на эту кнопку — так может ее вообще убрать или сделать disabled?

Список можно продолжать долго.

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

Система будет истинно корректной только тогда, когда ее нельзя некорректно использовать. И только из таких систем можно создавать еще большие корректные системы. Это и есть Correct by construction.

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

И еще немного про скрипты

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

Но есть еще одна причина, по которой люди используют скрипты — расширяемость программ. И эта проблема уже больше психологическая. Программист, как и любой умник, хочет написать что-то клевое и универсальное (движок), чем потом можно будет как угодно рулить из скрипта: «Смотрите, вот вам exe-шник, а работать он будет так, как мы ему напишем в скриптах» (вернее, «Смотрите, какой я умный, умею создавать гибкие решения»). Внимание, вопрос! А не является ли ваш скрипт, по сути, очередным exe-шником или dll-кой? Не добьетесь ли вы такой же гибкости просто написав модуль к программе?

Неужели разделения на модули и библиотеки является недостаточным для создания гибких и расширяемых программ? Неужели действительно надо городить всю эту обвязку, вставлять в программу интерпретатор, экпортировать/импортировать функции/классы/данные? Вам очень нужен этот модный abstraction barrier, о который можно потом и разбиться? Я думаю, что нет.

Soft coding — не лучшая замена hard coding-у. Чем отличается код скрипта в отдельном файле от обычного модуля программы? Тем, что красивше? Значит у вас недостаточно выразительный основной язык. Тем, что его можно динамически загрузить в рабочую программу? А разве обычный модуль нельзя?

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

PS: еще рекомендую почитать (не столько про скрипты, сколько про липовую расширяемость за счет «правильной» архитектуры): The Mythical Business Layer.

Скриптовые языки — оно вам надо?

Вот Вы, да, Вы. Зачем Вы используете скриптовые языки? У Вас есть большая программа и хочется добавить в нее гибкости, сделать расширяемой, менять что-то отдельно, не трогая основы? А как это сделать — конечно же, добавить скриптовую обвязку: Lua, Python, Tcl, Lisp, да что угодно. Некоторые даже придумывают собственные языки.

Что характерно — скриптовый язык практически никогда не является языком, на котором написана основная программа. Правильно, зачем делать скрипты сложными. Нужен язык попроще, специально заточенный под нашу задачу.

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

Тем не менее, скрипты «со скрипом» прикручиваются. Ведь на них все пишется короче и быстрее, а программа становится расширяемой — игра стоит свеч!

СТОП. А теперь задумаемся. Не потому ли мы используем скриптовые языки, что наш основной язык (например, С++) является слишком сложным и низкоуровневым для простых, «скриптовых» задач?

Не только — скажете Вы:

• скрипты экономят время на компиляцию;




• скрипты можно хранить отдельно от основной программы;




• и, наверное, еще что-то.

Только вот время, сэкономленное на компиляции, с лихвой потратится на отладку. А хранить отдельно от основной программы можно многое. Как минимум OCaml и Haskell умеют загружать отдельные модули в основную программу. Причем модули, скомпилированные в нативный, а не в байт-код.

Более того, практически на любом языке можно сделать динамически загружаемый модуль (.dll или .so), который хранится отдельно от основной программы. А если не использовать в качестве языка С++ с морем template-ов, то время компиляции такого модуля становится несущественным.

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

Может быть, стоит сменить основной язык разработки? И тогда Вы забудете про множество глупых проблем (ошибки в скриптах и обвязке; тормоза при загрузке и работе), а заодно начнете использовать гораздо более продуктивные инструменты.

Поверьте, OCaml и Haskell — лучшие скриптовые языки, которые я знаю. А уж то, что они хороши и как основной язык, думаю знают все.

Короче. К черту скрипты, пишем все на одном мощном, удобном, кратком и продуктивном языке.

Маленький совет

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

И будьте осторожны на воде. На 5-й минуте человека еще можно откачать, а дальше уже нет. Даже если вы хороший пловец, но у вас плохое самочувствие — не лезьте в воду! Это может закончится очень плохо.

Спасибо, надеюсь вы будете больше думать о своем здоровье.

Дима Макеев. 26.10.1971—21.06.2007

Вот и прошло 40 дней с момента, как оборвалась жизнь очень дорогого мне человека, моего двоюродного брата Димы Макеева. До сих пор не верится, что это произошло.

Дима был отличным музыкантом, светлым, веселым и очень жизнерадостным человеком.

Мы всегда будем помнить твою музыку, твой голос и все то время, когда ты был с нами.

Царствие тебе небесное, и пусть земля тебе будет пухом.