вторник, 3 марта 2009 г.

Из непонятого: превратим программы в криптограммы?

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

==>
-<<
>>-
-<:
&>-

Попробуйте догадаться, какой из них что обозначает. Хотя бы вот в этом примере:

{ a ==> TraceNumber, b ==> TraceNumber } 
   &>- join -<: { GetSum, GetSum } >>- sum;

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

Возможно, причины возникновения таких криптограмм были как-то озвучены Артемием Лебедевым в его Бизнес-линче: “Физики, химики, математики, кибернетики, программисты — все они не в состоянии нарисовать себе приличные логотипы”. Т.е. нет у программистов способностей к графическому дизайну. А, поскольку выбор понятных и простых обозначений для операций – это и есть дизайн, то неудивительно, что что получаются вот такие результаты.

PS. Пользуясь случаем, не могу не бросить еще раз камешек в огород хардкорных функциональных языков. Цитата из статьи про монады:

choose p d1 d2 = Dist {support = s, gen = g, expect = e}
   where
      s = support d1 ++ support d2
      g sg = let (x,sg') = randomR (0.0,1.0) sg in if x < p then gen d1 sg' else gen d2 sg'
      e f = p * expect d1 f + (1-p) * expect d2 f

Попробуйте с ходу сказать, что происходит в выделенной жирным строке ;)

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

4 комментария:

Dmitry Vyukov комментирует...

"==>" могу предположить, что получение сообщения из канала.
А остальные? Ответы будут или только варианты принимаются?
Там ещё должно быть неблокирующее получение сообщения, по направлению стрелочек видимо - ">>-".
"&>-" - судя по амперсанду возможно join из нескольких каналов.
Остальные по-моему просто смайлики.

eao197 комментирует...

==> -- это связывание источника с приемником (source ==> target).
-<< -- это широковещательная рассылка нескольким получателям (source -<< [t1, t2,...]).
>>- -- это завязка нескольких источников на одного получателя ([s1, s2,...] >>- target).
-<: -- отсылка одному из нескольких получателей (балансировка нагрузки).
&>- -- действительно join, за которым следует >>-.

Dmitry Vyukov комментирует...

Да... уж лучше бы сделали методы attach_to, send, broadcast, choice...

eao197 комментирует...

В том-то и дело.