Лаконичность кода или Java vs K или зачем нам JRuby и Groovy
24 апреля 2008
Кто там говорит что perl-код не читабелен? Вот вам реализация soundex на языке K:
sdx:"bfpvcgjkqsxzdtlmnr"!(4#1),(8#2),(3 3 4 5 5 6)
nn:{d2:x where x > 0;r:d2 where d1:0w<>':d2}
soundex:{(x[0],(nn (sdx@1 _ x)),l:4#0)[til 4]}угу, именно так... Похоже что клавиатуру протирали.
Теперь запускаем:
>soundex "hellomyfriends"
("h";4;5;1)А оно работает даже!
На самом деле из меня пока еще никакой специалист по K, и в действительности саму функцию (т.е. последние 2 строки) наверняка можно переписать укоротив раза в 2-3, вообще для такой мелочи должно 1 строки кода хватать, так что мой пример нифига не лаконичен. Но идея думаю понятна. На Java тоже самое было бы гораздо длиннее, я приводить алгоритм soundex не буду, но можете посмотреть на другие сравнения синтаксиса Java и K
Честно говоря вся фишка языка K вовсе не в том что он такой компактный, а в Kdb+ и их совместных возможностях, но все же, я именно о синтаксисе. Для Java кода, при кодревью, я всегда помечал записи вида:
x += isEmpty(s) || isDigit(s) ? 1 : 2;и требовал что то вроде:
if (isEmpty(s) || isDigit(s)) {
x++;
} else {
x += 2;
}Что первый что второй вариант одинаковы понятны, хотя визуально второй прозрачней. K на самом деле тоже понятен, ну если его конечно изучить 
Вот только порог вхождения тут повыше, во многом из за того что сходу не получается читать примеры кода. Ну и опечатки гораздо менее заметны.
Так вот для человека, который не знает программирования, а тем более уж Java и K, оба языка покажутся «китайской грамотой», и лишь для специалиста будет понятно, причем лишь тот пример на языке которого у него есть реальный опыт.
Еще в Java есть куча людей непонимающих вовсе как работает компьютер и что именно они пишут, а в K сплошь хакеры, поэтому для первых и делается попытка как можно больше упростить синтаксис, чтобы достаточно было знать даже не язык программирования, а английски язык. В результате получается что исправить ошибку или продолжить проект на java гораздо проще, возможно что даже если и опыт владения языками одинаков. Также на практике много раз убеждался что вполне можно сказать тестеру, аналитику или админу что и где нужно исправить, если возникла проблема а у вас нет возможности исправить в данный момент, и он исправит без проблем. В случае K объяснить будет на порядок сложнее, да даже слушать никто не станет, придется ехать и самому лезть в код, даже если надо всего лишь повернуть слэш в другую сторону
С другой стороны когда реализуешь алгоритм немного раздражает что пишешь сотни строк не относящихся напрямую к алгоритму (конечно постоянные Ctrl+Enter немного облегчают, но все же это не панацея), а после не можешь его окинуть взглядом и чтобы понять как оно работает появляются уродцы типа UML диаграмм. Ну и вообще пока описываешь эти бесконечные иерархии начинаешь забывать что собственно пишешь. Кстати, а может устроить программирование как в шахматных партиях: 8 машинисток и идти вдоль ряда, лишь парой фраз указывая каждой что ей нужно писать? В случае Kdb+/K ходит история что некоторые, совсем уж хакеры, на ходу, собственно в процессе получения ТЗ от зрителей, за 1-1,5 часа пишут небольшую ERP.
Так вот, к чему я, если отвлечься от «java разработчика без проблем найти, а под K замучаешься», то возникает вопрос: а все же как лучше? С одной стороны простота, с другой скорость реализации. Весь этот синтаксический overhead уже заставляет java разработчиков искать себя в ruby, python, groovy. Этакая золотая середина?
апреля 24, 2008 в 16:48
У меня тут оказывается на блоге уже долгое время комментарии отключены, со спамерами боролся, сейчас включил обратно.
апреля 28, 2008 в 14:50
Интересная тема...
мая 1, 2008 в 16:15
>>Ну и вообще пока описываешь эти бесконечные иерархии >>начинаешь забывать что собственно пишешь.
Да, очень похоже и на мои ощущения. Иногда просто задалбывает. Только вот не ясно куда таки податься(поближе к Java) — JRuby, JPython, Groovy?
Перепробывать всё не хочется, да и времени жалко. Но вот проблема выбора сдерживает... (Ни python, ни ruby отдельно не знаю)
мая 1, 2008 в 19:02
Есть еще scala, это еще ближе к java.
Ну а из этих скорее jruby или groovy. jython почти мертв.
jruby хорош тем что всегда можно переключится на чистый ruby, что пригождается и при написании простеньких утилитных скриптов, а groovy же изначально к java относится, и говорят что пока достаточно тормозной.
Что выбрать это все же дело вкуса, и придется действительно все попробовать. Хотя я, даже попробовав все это, не могу сказать что что-то из них явно лучше, везде свои плюсы и минусы.
мая 13, 2008 в 16:38
> Только вот не ясно куда таки податься(поближе к Java) — JRuby, JPython, Groovy?
Предлагаю радикальный вариант: pure CPython )
мая 20, 2008 в 11:15
Ну CPython геморойней интегрировать с Java, нежели чем указанные. А интегрировать нужно, все таки весь энтерпрайз на java и чистый Python тут вообще бесполезен.
июля 23, 2008 в 09:03
Это смотртя с чем сравнивать — если с Java и Scala — то Groovy проигрывает в производительности.
Если же сравнивать с JRuby или Jython — то тут он качественно выигрывает.
Что же касается K, то насколько я понял он является функциональным языком (originally developed in 1993, is a variant of APL and contains elements of Scheme) — а следовательно сравнивать его синтаксис с синтаксисом императивной статической Java чревато заранее известным результатом.
октября 13, 2008 в 18:03
Если кому-то охото сломать мозг — не тратьте время на K — изучайте BrainFuck.
Вот пример программы на BrainFuck, печатающей «Hello World!»:
++++++++++[>+++++++>++++++++++>+++>+<<<++ .>+.+++++++..+++.>++.<.+++. ------.--------.>+.>.Все интуитивно понятно...
октября 13, 2008 в 18:52
вот только BrainFuck он лишь «for fun», а K имеет практическое применение и множество реализованных на нем коммерческих проектов
февраля 28, 2009 в 13:31
я как-то апллаился в вашу компанию и предлагал перейти на мой любимый хаскел
проблема с записью 5 стррчек вместо одной в том, что каждая строчка конечно становится понятней, но программа в целом-то становится в 5 раз длиннее! и на экран/листок бумаги уже влезает небольшой огрызок. фактически, для текста программы увеличивается локальная читаемость — «могу понять то, что могу окинуть одним взглядом», но при этом страдает глобальная — «могу понять как устроена эта функция»
плюс чем больше мастерство, чем более лаконичной становится программа — в том числе программа, которую можно прочитать, не задумываясь. у вас самого 5-строчный вариант не вызывает чувства «они бы здесь ещё комментарии дописали!»?
моё лично мнение — что код должен быть лаконичным (на уровне lowest common denominator для квалификации участвующих в проекте программистов), но конечно не шифрованным, и для повышения читабельности гораздо важнее подробные комментарии, описывающие к чему выполняется каждое действие (для алгоримически сложного кода я пишу комментарии к каждой строчке)