Размышлизмы eao197

среда, 27 января 2010 г.

[comp.prog.humour] Маразм крепчал: объектно-ориентированные аргументы командной строки

Вот такое вот новшество в MPlayerXP 0.7.95:

Renamed command-line arguments to be more object-oriented

Т.е. аргументы командной строки были переименованы чтобы быть более объектно-ориентированными. Это пять!

[comp.prog] Свежее интервью Matz-а в InfoQ

Мне, как бывшему Ruby-исту, было интересно прочитать свежее интервью Якихиро Мацумото (Matz), создателя языка Ruby, в журнале InfoQ.

Если его коротко пересказать, то получается следующее:

в последнее время Matz активно работал над веткой 1.9 языка Ruby, которая гораздо быстрее, чем 1.8. Так же в Ruby пытаются сделать поддержку нескольких виртуальных машин Ruby в рамках одного процесса;
когда Matz начинал разработку Ruby, он имел представление о функциональном программировании в рамках возможностей языка Lisp. И лишь затем познакомился с более продвинутыми средствами, которые доступны в Haskell и OCaml, хотя понимание некоторых из них дается ему с трудом;
если бы Matz разрабатывал Ruby с нуля сейчас, он бы попробовал добавить в Ruby что-нибудь из функциональных языков. Например, какую-то форму ленивых вычислений. Но вот добавление этих возможностей в уже существующий язык представляется очень тяжелым делом – слишком многое придется менять в дизайне языка;
по мнению Matz попытки “подружить” функциональный и объектно-ориентированный подходы в одном языке (вроде того, что делают в Scala) – это очень трудное дело, в котором обязательно чем-то придется жертвовать;
Matz знаком с Haskell, написал несколько маленьких программок и его впечатление о типах и о самом Haskell-е неоднозначное. По поводу типов – с одной стороны, они помогают вылавливать ошибки на ранних стадиях, но с другой – это лишняя головная боль для разработчика, поскольку о них постоянно нужно думать. И даже автоматический вывод типов и компактность языка здесь не сильно помогают, т.к. типы все равно никуда не исчезают и о них нужно думать. Так же в Haskell-е программисту хорошо тем, что он описывает, что он хочет сделать, а не как это делать. Но при этом сам Matz не всегда понимает, как же именно будет работать программа. В языке Ruby с этим проще – его вычислительная модель тривиальнее;
язык Clojure и использование STM кажется Matz-у интересным. Хотя он и не считает, что Clojure является чем-то новым. Скорее хорошо упакованным набором давно известных вещей. А вот внедрение STM в Ruby выглядит маловероятным, поскольку язык изначально не был предназначен для этого;
Matz считает, что Ruby похож на SmallTalk, но является более легковесным. На Ruby проще писать маленькие программки, которые не тянут с собой большие image-файлы. Поэтому Ruby является более практичным языком;
Matz радует наличие портов Ruby для других платформ – JRuby и Iron Ruby. За Iron Ruby он не следит, а вот JRuby ему кажется очень интересным. А то, что программы, написанные специально для JRuby не будут работать на Ruby MRI он не считает проблемой – да, есть такая особенность. Это в точности тоже самое, что и Ruby-программы, заточенные только под Unix или только под Windows;
что касается дизайна языка, то если нужно было делать выбор между удобством языка и скоростью, Matz делал выбор в пользу удобства. Поэтому Ruby MRI не быстр. Но ребята из команды проекта Rubinius напряженно работают, чтобы создать быструю реализацию. Так же Matz сильно озабочен тем, чтобы язык не оказался переусложненным. Чтобы не оказалось как в C++, куда была добавлена относительно не сложная штука – шаблоны, но из-за которой сложность языка C++ слишком увеличилась;
сильно Matz уважает разработчиков языка Python. По его мнению в Python сложился и очень хорошие библиотеки, и хороший дизайн самого языка. И вообще, сейчас выбор динамического языка – это вопрос вкуса. Кому-то нравиться Python, кому-то Ruby. Это точно так же, как кто-то любит собак, а кто-то – кошек.

Еще Matz высказался в том плане, что сейчас доминирующей парадигмой является ООП, которая появилась очень давно – в 50-60 годах. И что в ближайшие несколько десятилетий мы вряд ли увидим какую-то другую настолько же мощную парадигму за исключением функционального программирования (которое само по себе так же далеко не ново).

Много Matz говорил о поддержке конкурентного программирования. С упором на модель актеров. По его мнению, лучший подход к этой проблеме – это сосредоточение всех модификаций состояния внутри агентов и взаимодействие агентов между собой посредством сообщений. И что эта штука в языке будет перспективнее, чем STM. Хотя он не знает, будут ли актеры частью языка или же просто Ruby-овой библиотекой (коих для Ruby существует уже пара-тройка штук).

eao197: ёптыть, очень приятно осознавать, что коллектив, в котором мне повезло работать в конце 90-х, додумался до этого уже тогда. И что мы уже давно именно так программы и разрабатываем, только называем актеров агентами. Данная ремарка является откровенной рекламой SObjectizer-а ;)

Disclaimer: я рассказал то, что воспринял из интервью Matz-а. Далеко не все я пересказал. И я далеко не уверен, что все рассказал правильно. Так что переадресую всех интересующихся к первоисточнику ;)

вторник, 26 января 2010 г.

[life] Маразм крепчал: любо учи, либо лечи

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

В очередной раз вспоминается анекдот “…но ехать надо!” И не в Россию.

[comp.prog] Новая конструкция across в языке Eiffel

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

Вот так теперь может записываться обход всех элементов контейнера:

across s as c loop print (c.item) end

А вот так подсчет суммы всех элементов контейнера:

across s as c from sum := 0 loop sum := sum + c.index * c.item end

Раньше нужно было писать так:

from
   sum := 0 ; s.start
until
   s.after
loop
   sum := sum + s.index * s.item
   s.forth
end

В качестве s может использоваться объект любого класса наследника ITERABLE. В качестве c будет использоваться объект того типа, который возвращает метод new_cursor объекта s. По умолчанию это тип ITERATION_CURSOR, но конкретный контейнер может использовать и наследников от этого класса.

Вот так можно обойти контейнер в обратном порядке:

across s.new_cursor.reversed as c loop print (c.item) end

Мейер говорит, что в Eiffel встраивается некоторая защита от модификации контейнера, по которому идет итерация посредством across. В этой защите каким-то образом задействовано постусловие и новое свойство контейнеров is_valid. Вроде бы, когда контейнер модифицируется, его свойство is_valid возвращает false вместо true и это останавливает цикл. Но как это реально работает я не понял, а сама новая версия библиотеки EiffelBase с поддержкой is_valid еще не готова.

Однако, самое интересное в across то, что эта конструкция может использоваться не только в качестве цикла, но и в качестве предиката. Например, выражение:

across s as c all c.item > 0 end

будет истинным только если все элементы контейнера s больше нуля. А выражение:

across s as c some c.item > 0 end

будет истинным если хотя бы один элемент контейнера s больше нуля.

Забавный все-таки язык Eiffel. И развивается забавно.

[comp.prog.thoughts] “Изучали XYZ прямо по ходу проекта. Несмотря на это…” Несмотря или благодаря?

Довольно часто евангелисты какой-нибудь технологии приводят примеры следующего рода: “Когда мы начинали проект большинство разработчиков даже не знали XYZ и учились по ходу работы. И даже несмотря на это проект был сделан качественно и в срок…” Об этом упоминают, когда говорят о разработке софта для AXD301, об использовании Erlang-а в Facebook. Да и я говорил (говорю и буду говорить) подобные вещи о библиотеках Qt, ACE и SObjectizer. Ибо очень удобно: мол, ну такая хорошая технология, что берешь новичка, он ее влет осваивает и пишет качественный код, так что не тормози – бери сразу два и будет тебе щасте ;)

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

Не так все просто, поскольку есть фактор новизны. Вот что об этом говорят ДеМарко и Листер в книге “Человеческий фактор” (русское издание 2005 года, стр.135):

Весной 1932 года эксперты по производительности провели ряд испытаний в Hawthorne Western Electric Company, чтобы определить влияние различных параметров среды на производительность. Они пробовали увеличивать освещенность и заметили, что производительность увеличилась. Затем они попробовали снизить освещенность и заметили, что производительность увеличилась еще больше. Они предположили, что если отключить свет совсем, производительность выбьет потолок. Было похоже, что влияние оказывает не изменение, но сам его факт. Людям было приятно, что на них обращали внимание, их интриговала новизна. Явление получило название эффекта Готорна (Hawthorne Effect). Грубо говоря, люди работают лучше, когда пробуют что-то новое.

В этом все и дело. Люди работают лучше, когда пробуют что-то новое. Новый проект, новый инструмент – отсюда и его успех. Поэтом фразы “…учились по ходу работы. И даже несмотря на это…”, наверное, стоит воспринимать как “…учились по ходу работы. И благодаря этому…” ;)

понедельник, 25 января 2010 г.

[comp.prog] Ссылки от читателей: OCaml в Jane Street

Ув.тов.Rustam дал в комментарии к одной из предыдущих заметок ссылку на сайт компании Jane Street Capital, в которой активно используется OCaml: http://www.janestreet.com/technology/ocaml.php

На этой странице перечислены три PDF-ки с описанием того, как Jane Street пришла к использованию OCaml, что хорошего в OCaml, что плохого, чем им OCaml помог.

Первая PDF-ка, Caml Trader: Adventures of a functional programmer on Wall Street (2006 год) – это слайды презентации с конференции Commercial Users of Functional Programming. Такой небольшой, в виде тезисов, рассказ. Кроме того, там приведен объем написанного в Jane Street OCaml-овского кода – на 2006 год это 250KLoc (учитывая, что OCaml-овский код в 1.5-2.5 раза компактнее C++ного, это вполне внушительная цифра).

Две следующие PDF-ки, Caml Trading: Experiences in Functional Programming on Wall Street (2007 год) и Caml trading: experiences with functional programming on Wall Street (2008 год), по сути, являются раскрытием тезисов из первой презентации. Причем обе настолько похожи между собой, что при беглом просмотре не понятно, чем они друг от друга отличаются.

В кратце, суть такова: была маленькая, никому не известная трейдинговая компания Jane Street, у которой в 2003 году даже не было клиентов. Софт у нее был написан, в основном на Excel-е и VB (плюс еще что-то на C#, Java и C++). Поскольку Excel+VB не справлялись с возрастающим объемом торгов, то нужно было переходить на что-то более быстрое. Попытки использовать C# не увенчались успехом, зато OCaml эпизодически применялся в Jane Street с 2002-го года и в 2005 руководство дало добро на его широкомасштабное применение. С тех пор OCaml является основным языком разработки.

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

Я же заострю внимание на двух вещах.

Во-первых, как OCaml проник в Jane Street. Как я понял, основным “разносчиком заразы” ;) стал Yaron Minsky. Который получил PhD в области распределенных систем в Cornell, потом около года работал консультантом (в том числе и на Jane Street), а затем перешел в Jane Street на постоянную работу. OCaml он использовал еще в Cornell-е, потому и подвинул его в Jane Street. Но важнее как раз сам факт наличия PhD – я давно подозревал, что для успешного использования функциональных языков нужна ученая степень ;)

Во-вторых, в каждой из трех перечисленных работ подчеркивается один и тот же важный момент: OCaml помогает им набирать хороших программистов. Мол, Java-разработчиков полно и среди них есть отличные ребята, но вот как толковых найти среди толпы посредственностей – вопрос без ответа. А с OCaml все просто – раз человек программирует на OCaml, значит он уже по факту не может быть бестолковым (грубо говоря).

Так что я еще раз повторю мысль, которую озвучивал уже неоднократно: сейчас функциональное программирование выглядит очень привлекательно потому, что его применяют очень умные люди в очень ограниченных контекстах. Как только ФП проникнет в широкие массы и на OCaml/Haskell/Erlang начнут писать толпы обычных программистов, то мало никому не покажется. Если не верите – посмотрите на то, что мы уже сделали с ООП ;)

PS. Еще одно соображение не могу не высказать. OCaml в 2003-2005 действительно был вне конкуренции по сравнению с VB и C#. Тогда ведь в C# даже дженериков не было. Сейчас, возможно, преимущества OCaml над C# не так очевидны. Хотя практика показывает, что .NET для биржевых приложений – это как-то не очень… ;)

воскресенье, 24 января 2010 г.

[life.photo] Природа на фотографиях Юрия Бондера

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

«DUNE 3.00 pm»