Определенно, у программистов есть и желание, и способность изобретать нечитаемый синтаксис для своих программных творений. Ранее я об этом уже говорил в юмористической форме. Вчера, читая блог команды разработчиков 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 комментария:
"==>" могу предположить, что получение сообщения из канала.
А остальные? Ответы будут или только варианты принимаются?
Там ещё должно быть неблокирующее получение сообщения, по направлению стрелочек видимо - ">>-".
"&>-" - судя по амперсанду возможно join из нескольких каналов.
Остальные по-моему просто смайлики.
==> -- это связывание источника с приемником (source ==> target).
-<< -- это широковещательная рассылка нескольким получателям (source -<< [t1, t2,...]).
>>- -- это завязка нескольких источников на одного получателя ([s1, s2,...] >>- target).
-<: -- отсылка одному из нескольких получателей (балансировка нагрузки).
&>- -- действительно join, за которым следует >>-.
Да... уж лучше бы сделали методы attach_to, send, broadcast, choice...
В том-то и дело.
Отправить комментарий