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

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

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

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

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

Ну мега понт

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

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

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

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

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

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

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

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

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

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

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

Наткнулся тут на очень интересный рассказ человека, ушедшего из 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 понятна - им невыгодно, чтобы человек прошел игру. Только вот человечно ли это?

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

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

Логика игры, которую мы сейчас делаем (равно как и предыдущей игры) пишется на 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

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

Никогда! Запомните! Никогда не мешайте окемловские эксепшны с плюсовыми объектами. Из-за 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. Спасибо.

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

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

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

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

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

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

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

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

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

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

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

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

Про Functional Hybrid Modeling

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

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

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

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

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

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

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

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

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

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

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