Веб-дневник Владимира Шабанова

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

2008-07-03T02:33:00.003+04:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Concepts, Techniques, and Models of Computer Programming

2008-05-29T22:42:00.002+04:00

Вот я и стал счастливым обладателем 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, особенно для тех, кто еще совсем не знаком с изложенными в ней идеями и не собирается учить десять языков, чтобы в них разобраться.

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

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

2007-12-17T01:45:00.000+03:00

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

В чем суть.

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

Краткое ТЗ.

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

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

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

Главное.

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

Детали.

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

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

Звоните: +7 926 536-27-96
Пишите: <vshabanoff@gmail.com>

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

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

Correct by construction

2007-10-12T22:32:00.000+04:00

Существует много приемов, способов и методологий разработки программ. Один из них, не самый заезженный, но очень полезный — это 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.

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

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

2007-09-26T00:54:00.000+04:00

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

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

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

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

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

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

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

2007-08-24T03:10:00.000+04:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2007-07-30T18:31:00.000+04:00

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

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

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

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

2007-07-30T03:06:00.000+04:00

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

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

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

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

Ищем программиста

2007-04-26T22:07:00.000+04:00

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

Обязательные требования:

желание разрабатывать игры;

умение пользоваться GNU toolchain;

знание Linux на уровне опытного пользователя;

хороший алгоритмический базис;

знание C++ на хорошем уровне;

скриптовые языки (желательно, python).

Желательно:

знание OpenGL, GLSL, OpenAL, wxWidgets;

умение собирать линукс с нуля (gentoo, lfs, etc.);

простое администрирование серверов (apache, backup);

огромным плюсом является знание Haskell или Ocaml (мы пишем на OCaml, если возможно, и на C++, если необходимо).

Обязанности:

написание инструментария для создания и тестирования игр;

сборка Linux-а, работающего в игровом автомате;

администрирование внутреннего сервера разработки (по мелочи);

и, конечно же, разработка игр.

Условия:

з/п от $800;

офис рядом со ст. м. Южная (г. Москва);

оформление по ТК;

график работы с 12:00 до 20.00, возможно гибкий;

возможен прием студента последних курсов.

Контакты:

E-Mail: <vshabanoff@gmail.com>;

Телефон: +7 926 536-27-96 (Владимир Шабанов);

PS: Комментарии приветствуются.

UPD: вакансия закрыта, желающие программировать на Haskell или OCaml по прежнему интересуют (на будущее), есть желание, скидывайте резюме на мыло, в будущем посмотрим.

Корректность, типизация и Erlang

2007-04-21T00:21:00.000+04:00

В последнее время все чаще встречаю упоминания об использовании Erlang на просторах ex-USSR.

Судя по всему, возрастающее применение Erlang оправдывается достаточно большим количеством success stories. К тому же Erlang поддерживается не только группой исследователей и community, как это происходит с Haskell и OCaml, но и такой немаленькой фирмой, как Ericsson. Это позволяет легче убедить менеджмент в пригодности Эрланга для серьезной разработки.

Но, как и в предыдущем посте, я хочу поговорить о корректности программ.

С Эрлангом наблюдается очень забавная картина: с одной стороны он предназначен для написания fault-tolerant программ и обладает замечательной runtime системой, хорошо подходящей для написания распределенных пуленепробиваемых non-stop приложений. С другой стороны — это язык с динамической типзацией, что, по моему мнению, противоречит написанию корректных программ.

Как можно написать корректную программу, если язык позволяет допустить практически любую опечатку? А как я поправлю ВСЕ места, где использовался модуль, принцип работы которого я только что поменял? Возможно, у Эриксон и есть столько денег на тестеров, но что делать более экономным людям?

А вы подумали о времени и нервах, потраченных на поиск несчастной опечатки? Конечно, в Эрланге пытаются поправить существующее положение: создана специальная тулза dialyzer. Однако, никакие тулзы не заменят полностью качественной, теоретически обоснованной, статической типизации.

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

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

PS: Ни в коем случае не хочу сказать, что эрланг — плохая платформа. Если ваша программа на 90% состоит из сетевого трафика, то, возможно, Эрланг вам и подходит. Но вот как язык...

PPS: Еще одна, несколько другая, жалоба на отсутствие статической типизации в Эрланге.

Немного по OCaml и Haskell

2007-04-20T03:57:00.000+04:00

От людей, пишущих программы на OCaml и Haskell часто слышно о том, что они в 10 строках описали то, что на C++/C#/Java занимало 100 строк, или за 2 недели написали то, что другие делали 2 месяца.

Это — всем известные факты. Программы на любом более менее вменяемом языке, будь то erlang, lisp, python, и т.д., в среднем занимают в 5-10 раз меньше места и, по личному опыту, пишутся в 3-5 раз быстрее.

Однако сейчас я хочу сказать про другую черту — корректность программ. Как часто вам приходится пользоваться отладчиком? Можете ли вы себе представить, что отладчик — вещь ненужная? В OCaml и Haskell это действительно так!

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

Не могу сказать, что мои OCaml-программы никогда не падали. Было такое, но виновата была только C++ часть.

А в целом в OCaml и Haskell вы никогда не встретите:

access violation — нет pointer arithmetics;

NullPointerException — нет NULL :), а на любые места, где возможен None, компилятор вам укажет;

SIGSEGV или BSOD — ну нельзя тут загадить память.

Если вы, как и я, пишете программы, работающие 24 часа в сутки 7 дней в неделю, то такие языки как OCaml или Haskell могут стать очень хорошим подспорьем.

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

SICP: Впечатления от прочтения

2007-03-30T02:21:00.000+04:00

Не прошло и полгода с момента закупки SICP, и я наконец-то ее прочел!

Сразу скажу: SICP — это не учебник по Lisp, это книга по Программированию. Если вы просто хотите изучить Lisp или Scheme, то SICP не для вас, лучше попробовать что-нибудь попроще.

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

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

В отличии от обычных книг, SICP не учит синтаксису (его у лиспа почти нет), а учит базовым вещам, необходимым для понимания того, как надо программировать. Причем, выбор этих базовых вещей и уровень их объяснения поистине шедеврален.

Уже на 20-й, 30-й странице мы узнаем о нормальном порядке вычислений, lexical scoping, рекурсивных и итеративных процессах, функциях высших порядков, lambda-выражениях, замыканиях и прочих вещах, о которых я узнал гораздо позже, чем надо. А к концу второй главы знаний хватает на то, чтобы писать 90% встречающегося кода. И мы еще не дошли до изменяемого состояния, модулей и объектов!

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

И вот мы доходим до модулей, объектов, потоков, параллелизма, распространения ограничений. Вы думаете, сейчас вам будут рассказывать, как пользоваться готовыми фреймворками или специально заточенными элементами языка программирования? Фигушки! Вам объяснят, как это сделать с нуля, из тех самых базовых кирпичиков, изученных в первых двух главах. Ничего больше не нужно! Это потом, в других языках (или на следующем курсе), вы увидите, как это можно сделать короче и запутаннее. Сейчас вы должны понять основы, как это сделать самому. И что самое приятное, все это сопровождается общими объяснениями, жизненными примерами и интересными упражнениями.

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

Что, скилл в вычислениях прокачан и карма аж светится? Но ведь вы все это время были далеки от железа и не знаете, как все это работает уровнем ниже Scheme! Тут то (в заключительной главе) вам и расскажут про регистровые машины, даже парочку-троечку спроектируют. Чтобы было на чем их проверять, вам опишут имитатор регистровых машин. Вы узнаете про стек. Вам расскажут про сборку мусора (и конечно покажут, как ее сделать с нуля ;). Чтобы прокачать понимание регистровых машин, вы напишете интерпретатор Scheme на своеобразном ассемблере. Но ведь интерпретатор — это медленно, надо написать компилятор! А компилятор сам по себе не очень удобен (нет интерактивной разработки), так что скрестим его с интерпретатором. Страшно? Ничего, ребята действительно хорошо все объясняют.

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

Выводы

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

А если Вы программист со стажем, то следует почитать хотя бы для наведения порядка в голове.

PS: Paul Graham сказал про SICP:

„Я впервые прочел ее 15 лет назад и до сих пор не уверен, что усвоил все, чему эта книга может научить.“

StarDict: Кросплатформенный словарь

2007-02-04T23:22:00.000+03:00

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

Однако, случайно я обнаружил замечательный словарик StarDict, open source альтернативу Lingvo.

StarDict работает и под windows и под linux, умеет переводить слова в других программах при наведении на них мышкой, умеет осуществлять нечеткий поиск (по словам с опечатками), а главное — бесплатен.

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

Так что я уже пользуюсь StarDict и не чувствую себя пиратом, а вы? :)

И немного про LaTeX

2007-01-20T02:49:00.000+03:00

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

Спасибо LaTeX-у за то, что я теперь реже ругаюсь матом.

Небольшой обзор персональных wiki-систем

2007-01-19T20:35:00.000+03:00

На работе давно пользуюсь wiki, входящей в состав Trac. Wiki — это дико удобная вещь для создания заметок и их дальнейшего связывания друг с другом. Можно начать с маленького черновика, и дорасти до настоящей проектной документации. Или даже до чего-то большего, например, до Wikipedia.

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

Конечно, можно завести себе доменное имя, сервак, и установить на него Trac, а лучше MediaWiki, но возиться не хочется. И решил я поискать — что же мне предложит старик интернет?

И вот, что я нашел и попробовал:

http://stikipad.com/ — выделяет 30 MB для фришного аккаунта, что для обычного текста без картинок более чем достаточно; позволяет делать приватные вики (вход только по паролю); форматирование textile или markdown или WYSIWYG, т.е. не такое, как привычное мне форматирование в Trac или форматирование в MediaWiki (см. также тут); позволяет делать примитивные TODO-шки (не Trac, конечно); есть теги.

http://pbwiki.com/ — простая, как peanut butter sandwich — утверждает сайт; действительно простая; выделяет 10 MB для фришного аккаунта; также позволяет приватность; лично мне не очень понравился внешний вид; формат pbwiki тоже простой (не такой как у всех остальных wiki, нечто среднее).

http://serversidewiki.com/ — очень своеобразная штука — все прыгает и бегает (ajax & ruby on rails, основан на TiddyWiki), стоит посмотреть поприкалываться, может кому-нибудь понравится (я сам прикололся, но потом подумал, что для меня статичные сайты лучше — на этом даже ссылку не сделаешь); в сентябре станет платным, и фришным аккаунтам будет выделяться не более 10-ти страниц-tiddler-ов, т.е. система только на посмотреть; есть мега-удобные TODO-шки; теги; приватность делается постранично, через тег private (который неудобно вставлять каждый раз); форматирование textile.

http://wikispaces.com/ — выдают 2 GB и говорят, что можно расширить (Just drop us a line); приватным делается за 5$/мес; форматирование WYSIWYG или как у pbwiki; поиск почему-то через google, а не свой (как у всех остальных wiki); теги.

http://wetpaint.com/ — симпатичный сайт; есть только WYSIWYG редактор; система заточена на community и соответственно никакой приватной wiki; ограничения на объем пока нет; пожалуй, самая простая wiki — для домохозяек :).

http://wikia.com/ — все прелести википедии (MediaWiki), но надо делать открытый, идейный коммьюнити-проект, т.е. это вообще не персональная wiki-система.

http://www.google.com/notebook/ — очень простая система, даже не вики, а так просто раскидывать текстовые заметки по блокнотикам. Стоит посмотреть — возможно вам будет достаточно.

http://www.wiki-site.com/ — персональная MediaWiki; никакой приватности — ваши страницы могут смотреть и изменять (хотя можно защищать отдельные страницы от правки); сайт открылся где-то полгода назад и несколько сырой; ограничений на объем нет, но советуют швырять всякую мультимедию на youtube.com и imageshack.us. Т.к. это единственная персональная MediaWiki-система, которая мне попалась, я забил на открытость и пока остановился на ней.

Практически все эти системы живут за счет рекламы. См. сюда, чтобы узнать, как от нее избавиться.

Дополнительную информацию по некоторым из этих wiki-систем можно узнать в статье Сделай собственную Wiki.

Надеюсь, обзор вам хоть чуть-чуть помог, и вы сможете быстрее попробовать и выбрать себе wiki-систему. Рекомендую выбирать между stikipad, wikispaces, wetpaint и wiki-site.

PS: Если вы знаете какой-нибудь еще бесплатный wiki-хостинг (особенно, если это MediaWiki-хостинг), напишите мне. Буду благодарен.

Эпиграммы в программировании

2006-11-20T19:13:00.000+03:00

Натолкнулся на сборник цитат Алана Перлиса Epigrams in Programming. Ну очень понравились. Не смотря на то, что написаны они были еще в 1982-м году, почти все они актуальны и сегодня. Всячески рекомендую для прочтения программистам.

Структура и интерпретация компьютерных программ

2006-11-08T01:50:00.000+03:00

Сбылась мечта идиота ;) Наконец-то приобрел эту потрясающую книгу.

Для тех кто не в курсе: „Структура и интерпретация компьютерных программ“ вышла в июле этого года на русском языке. К сожалению, тиражом всего в 1000 экземпляров и во всех магазинах она уже давно раскуплена. Однако не стоит отчаиваться, можно попробовать сделать где-нибудь заказ и подождать следующего завоза. По крайней мере у меня получилось.

Для тех, кто совсем не в курсе: SICP — одна из лучших книг по программированию из когда либо изданных. Прочесть ее от корки до корки — абсолютный MUST для любого уважающего себя программера.

Потрясает то, что эта книга — изначально всего лишь вводный курс по информатике в MIT. Метода для первокурсника, так сказать. Однако материал, который она охватывает, далеко не всегда вообще преподается в ВУЗе. Книга начинается с описания абстракции процедур и данных (рассматриваются функции высших порядков и даже символьная алгебра), плавно переходит к рассмотрению модульности, объектов и состояния (в частности: параллелизм, имитация цифровых схем, распространение ограничений). Затем начинается описание металингвистических абстракций (например, строится интерпретатор пролога, имитация ленивых вычислений, недетерминистское вычисление). А заканчивается книга вообще чудесно — строится эмулятор регистровой машины и пишется компилятор под нее.

Вот так надо учить программированию!

Безумно жалко, что 12 лет назад, когда я только начинал изучать программирование, я тратил время на всякую ерунду и на горьком опыте или путем долгих ковыряний в инете находил то, что в этой книге описывается „на пальцах“.

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

PS: также доступны видеозаписи лекций.

PPS: после того как прочту книгу для первокурсников, закажу себе книгу для второкурсников :)

UPD: можно попробовать купить SICP в издательстве.

Клевые комиксы :)

2006-10-31T21:47:00.000+03:00

Случайно наткнулся на архив комиксов Hackles. Ну очень порадовали.

А когда дошел до этого, то вообще прикололся - буквально пару дней назад втирал нашему "пингвину", что емакс мощнее, чем gvim :)

Про культы языков программирования

2006-10-25T03:02:00.000+04:00

Заметил интересную вешь. Практически вокруг любого языка программирования имеется свой культ. "С++ rulezzz", "LISP rulezz", "Haskell rulezzz", и т.д. Однако после продолжительного использования любого из "культовых" языков ощущение его культовости у меня проходит.

Каждый раз, сталкиваясь с культом, я вижу как люди торчат от того, что на некоем языке можно делать что-то, что было невозможно раньше. Я сам торчал от плюсовых темплейтов, лисповских макросов, хаскельной красоты (а также ассемблерной крутизны, окемловских first class functions, питоновского форматирования кода, Tk-ного описания интерфейсов, erlang-овского межпроцессного взаимодействия и много от чего еще).

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

Интересно только, почему у многих людей культ и торч не проходят? Смотришь на некоторые посты и думаешь... пока еще думаю... :)

Ну мега понт

2006-10-25T01:09:00.000+04:00

Почитал тут мега пафосный пост про то, что Хаскел - это Роллс-Ройс языков программирования.

Красиво, конечно. Хаскел - аристократический язык. Он не будет опускаться до серых нужд обычных людей :) Пока серые люди возятся со своими серыми языками, хаскел третий раз подряд выигрывает самое сложное соревнование в мире.

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

Для окемла есть потрясающая книжка Developing Applications With Objective Caml. А где такая книжка для хаскела? Куча введений в ФП c примерами a-la сферический конь в вакууме, описаний монад с очень "нужными" обычному программеру monad laws, куча разрозненных статей для Ph.D. people. А вот конкретного тьюториала для среднего программиста, с описанием разработки реальных приложений нет.

В итоге мы знаем, что хаскел крут, но не знаем как на нем сделать что-нибудь настоящее. С такими понтами хаскел рискует навсегда остаться уделом "аристократов". А ведь хочется применения его в мейнстриме.

Про окемл я могу сказать человеку, чем он крут и знаю, куда отослать человека для дальнейшего изучения. А как внедрять в массы хаскел? Как его самому-то изучать в конце концов :)

Пара полезных ссылок для разработчиков игр

2006-10-21T22:59:00.000+04:00

Возможно, многие уже видели и знают. Но приведу пару ссылок:

Записи докладов на КРИ - огромная куча очень интересных докладов.

Семинары на Chaos Constructions'2006 - кучка заметно меньше, но не менее интересна.

Впечатления человека, ушедшего из WoW

2006-10-19T17:34:00.000+04:00

Наткнулся тут на очень интересный рассказ человека, ушедшего из MMORPG World of Warcraft.

Пара выдержек:
...Why did I leave? Simple: Blizzard has created an alternate universe where we don't have to be ourselves when we don't want to be. From my vantage point as a guild decision maker, I've seen it destroy more families and friendships and take a huge toll on individuals than any drug on the market today, and that means a lot coming from an ex-club DJ...

...Blizzard created a game that you simply can not win. Not only that, the only way to "get better" is to play more and more. In order to progress, you have to farm your little heart out in one way or another: either weeks at a time PvPing to make your rank or weeks at a time getting materials for and "conquering" raid instances, or dungeons where you get "epic loot" (pixilated things that increase your abilities, therefore making you "better"). And what do you do after these mighty dungeons fall before you and your friend's wrath? Go back the next week (not sooner, Blizzard made sure you can only raid the best instances once a week) and do it again (imagine if Alexander the Great had to push across the Middle East every damn week)...

Мне и до этого особенно не нравились все эти MMORPG. Теперь я понимаю, что производство таких игр имеет очень много общего с производством наркотиков.

Любая интересная игра захватывает и отнимает кучу времени. Но стоит задуматься: может ли человек выиграть, играя в твою игру? Получит ли он удовольствие или красные глаза?

Позиция Blizzard понятна - им невыгодно, чтобы человек прошел игру. Только вот человечно ли это?

Через тернии к звездам

2006-10-17T01:50:00.000+04:00

На работе пришел к немного странному, на первый взгляд, решению: из окемловского приложения вызываю питовский код, который, в свою очередь, вызывает плюсовый. Казалось бы - что за изврат? Ан нет.

Логика игры, которую мы сейчас делаем (равно как и предыдущей игры) пишется на ocaml. Низкоуровневая работа с OSG, OpenGL, OpenAL и пр., ведется на С++. Окемловских байндиногв для OSG нет, есть питоновские. А писать окемловкие байндинги для С++ гимор тот еще.

В итоге, все плюсовые дела через boost::python (очень удобная библиотека, кстати) выводятся в питон. В питоне пишется тонкий слой, переводящий работу с объектами в примитивные функции. А в кемле написан небольшой код на полстранички, который позволяет легко и type-safe-но вытаскивать функцию из питона. Например:

  let fun1 = f "module" "fun1"
    (type1 **-> type2 **-> ret_type)

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

  (**->)

определяет функцию

  (f : type1 -> type2 -> ret_type)

Ну где вы еще такое напишите, кроме окемла или хаскела :)

За счет этого, я с минимальными усилиями получаю из ocaml доступ к плюсовому коду.

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

Ocaml exceptions & C++ destructors

2006-10-17T01:10:00.000+04:00

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

Никогда! Запомните! Никогда не мешайте окемловские эксепшны с плюсовыми объектами. Из-за longjmp(), который вызывается внутри caml_failwith, caml_invalid_argument или caml_raise*, ни один деструктор плюсового объекта не будет вызван и вы получите memory leak.

Также не мешайте обработку плюсовых эксепшнов и вызов окемловских эксепшнов, т.к. плюсовые эксепшны - это те же классы с деструкторами. Т.е. в данном коде

  try
  {
      bla-bla;
      throw std::runtime_error( "oh, shit!" );
  }
  catch ( std::runtime_error& e )
  {
      caml_failwith( e.what() );
  }

деструктор std::runtime_error не будет вызван и строчка "oh, shit!" навсегда останется в памяти. gcc пофиг на __attribute__ ((noreturn)).

Объекты отдельно, failwith отдельно. Запомните это, пожалуйста, и тогда вам не придется две недели анализировать логи mtrace или valgrind. Спасибо.

Немного рекламы антирекламного софта

2006-10-14T04:12:00.000+04:00

Все ненавидят рекламу. Залез в инет что-то найти - а там куча говна и ничего нужного. Как бороться с мигающей помойкой и "релевантной" гуглевской рекламой?

А очень просто. Есть две программы:

1. Ad Muncher - фильтрует рекламу в любой программе (т.к. перехватывает все обращения в инет и отрубает то, что попадает под рекламный фильтр, а фильтров у Muncher-a очень много). Программа платная, но кряк найти не проблема (хотя ЭТУ программу стОит купить).

2. CustomizeGoogle - дополнение к Mozilla Firefox, которое убирает ВСЮ текстовую рекламу из гугля, гмайла и прочих гуглевых служб. Программа бесплатная.

Даю гарантию, через пару дней Вы будете в ужасе от вида браузера других людей. А через полгода будете с удивлением говорить: "Фига, оказывается на этом сайте столько рекламы".

Короче, хватит читать - бегите скорее, устанавливайте себе и другим это чудо. И да будет с вами чистый инет.

О пользе тестеров (и вреде Anything Beta)

2006-10-11T03:12:00.000+04:00

Залез тут на Blogger и увидел, что гугль предлагает переключиться на обновленный вариант Blogger Beta - вроде как теги появились и прочие вкусности.

Переключился. И не смутился, что переключение безвозвратное. И не смутился, что Beta (Gmail ведь тоже Beta, однако работает). Только вот настолько все это сырое и глюкавое, что аж жуть берет. Теже функции, что и в обычном блоггере, почему-то работают через раз. Новые функции вообще через два. С горем пополам подправил темплейт, но сколько сил и времени на это ушло.

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

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

Про Functional Hybrid Modeling

2006-10-09T21:48:00.000+04:00

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

Предыдущую игру я сделал на основе Functional Reactive Programming (FRP от Conal Elliot). Оказалось очень даже ничего, только вот всплыли пара проблем: малая производительность (вся игра - один большой continuation, который каждый фрейм пересоздается заново, спасает только то, что игра не особо большая), и не совсем удобное описание логики в некоторых местах (причем, как грамотно описывать, сам пока не знаю).

Так вот - полез я посмотреть: какие-же продвижения в области FRP произошли за последнее время? И нашел я очень интересную статью, про Functional Hybrid Modelling. Моих вопросов оно не решает (хотя и дает некоторые направления). Но, в целом, крайне рекомендую для прочтения тем, кто хочет узнать, как надо делать симуляции физических и игровых систем.

Основная фича, которые придумали авторы - неявная связь между сигналами (signal relation), как основной строительный кирпичик. Т.е. мы больше не описываем, что из чего следует, а только описываем взаимосвязи. Из этих хреней можно автоматически выводить систему диффференциальных алгебраических уравнений (DAE), что является гораздо более мощным средством описания физических задач, нежели относительно низкоуровневые ODE.

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

Конечно реализация всего этого пока что не просто хромает, а вообще отсутствует. Почитал отчет их студента о языке Hydra - пробной реализации задуманных фич и не увидел там ничего нового, кроме описания семантики и примера перевода этой семантики в тупое FRP на continuation-ах.

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

Заброшенный блог, млин

2006-10-09T21:30:00.000+04:00

Ох, и давненько же я сюда ничего не писал. Спрашивается - зачем блог создавал?

Хотел мега мысли писать: как надо CAD-системы делать, как сам их делаю. А в итоге - как сессию сдал, так и забил и на работу научную и на SpindleCAD. И вроде блог есть, а писать нечего. Ведь на CAD-ы-то я малость подзабил. А блог изначально вроде как для них делался.

И решил я теперь, что буду я писать сюда все, что в голову взбредет. И не важно - интересно это Вам или нет. Относится ли это к CAD или нет. Пофиг. Мой блог - что хочу, то и ворочу.

Ограничения как база CAD системы

2006-06-12T00:10:00.000+04:00

На моем сайте появился черновик статьи Ограничения как база CAD системы, в которой рассказывается о том, как ограничения могут решить проблему отсутствия интеграции в CAD системах.

Отрывок статьи:
"Современные CAD системы страдают от недостатка интеграции – мы чертим в одном месте, считаем в другом, оформляем документацю в третьем. Если в одном месте что-то изменилось, то в других местах все приходится менять вручную. Данный недостаток вызван тем, что CAD/CAM/CAE/PDM системы не имеют общей базы, которая могла бы их связать. В роли такой базы может выступать система ограничений, описывающих инженерную задачу и различные взаимосвязи, существующие в задаче."

Полный текст >>

Если у Вас есть какое-либо мнение по поводу этой статьи, пожалуйста оставьте здесь свой комментарий или напишите мне письмо.

До встречи...

Обо мне и об этом блоге

2006-06-11T21:46:00.000+04:00

Здравствуйте. Как можно уже догадаться, меня зовут Владимир и я хочу рассказать вам кое-что обо мне и об этом блоге.

Обо мне

На данный момент я являюсь студентом 5-го курса МГТУ им. Н.Э. Баумана. Кафедра МТ1 «Металлорежущие станки».

Параллельно с этим я работаю программистом - разработчиком игр. Если очень интересно и не лень читать по-английски, можете посмотреть краткое резюме здесь.

Мои интересы

Интересов много. Расскажу о некоторых.

Разработка игр является моим профеcсиональными интересом, т.к. последние пару лет именно этим зарабатываю на жизнь.

Как любого ленивого программиста, интересуют "продвинутые" языки программирования и технологии разработки ПО, которые помогают мне сберечь время и нервы.

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

О блоге

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

До встречи...