Лаконичность кода или Java vs K или зачем нам JRuby и Groovy

Кто там говорит что 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. Этакая золотая середина?

  • http:// igor

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

  • http:// yaх

    Интересная тема...

  • http:// and

    >>Ну и вообще пока описываешь эти бесконечные иерархии >>начинаешь забывать что собственно пишешь.

    Да, очень похоже и на мои ощущения. Иногда просто задалбывает. Только вот не ясно куда таки податься(поближе к Java) — JRuby, JPython, Groovy?

    Перепробывать всё не хочется, да и времени жалко. Но вот проблема выбора сдерживает... (Ни python, ни ruby отдельно не знаю)

  • http:// igor

    Есть еще scala, это еще ближе к java.

    Ну а из этих скорее jruby или groovy. jython почти мертв.

    jruby хорош тем что всегда можно переключится на чистый ruby, что пригождается и при написании простеньких утилитных скриптов, а groovy же изначально к java относится, и говорят что пока достаточно тормозной.

    Что выбрать это все же дело вкуса, и придется действительно все попробовать. Хотя я, даже попробовав все это, не могу сказать что что-то из них явно лучше, везде свои плюсы и минусы.

  • http:// Grigoriy Petukhov

    > Только вот не ясно куда таки податься(поближе к Java) — JRuby, JPython, Groovy?

    Предлагаю радикальный вариант: pure CPython )

  • http:// igor

    Ну CPython геморойней интегрировать с Java, нежели чем указанные. А интегрировать нужно, все таки весь энтерпрайз на java и чистый Python тут вообще бесполезен.

  • http:// Vadim Voituk

    [о Groovy] и говорят что пока достаточно тормозной

    Это смотртя с чем сравнивать — если с Java и Scala — то Groovy проигрывает в производительности.

    Если же сравнивать с JRuby или Jython — то тут он качественно выигрывает.

    Что же касается K, то насколько я понял он является функциональным языком (originally developed in 1993, is a variant of APL and contains elements of Scheme) — а следовательно сравнивать его синтаксис с синтаксисом императивной статической Java чревато заранее известным результатом.

  • http:// Александр Нуйкин

    Если кому-то охото сломать мозг — не тратьте время на K — изучайте BrainFuck.

    Вот пример программы на BrainFuck, печатающей «Hello World!»:

    ++++++++++[>+++++++>++++++++++>+++>+<<<++ .>+.+++++++..+++.>++.<.+++. ------.--------.>+.>.

    Все интуитивно понятно... 😉

  • http:// igor

    вот только BrainFuck он лишь «for fun», а K имеет практическое применение и множество реализованных на нем коммерческих проектов

  • http:// Bulat

    я как-то апллаился в вашу компанию и предлагал перейти на мой любимый хаскел 🙂

    проблема с записью 5 стррчек вместо одной в том, что каждая строчка конечно становится понятней, но программа в целом-то становится в 5 раз длиннее! и на экран/листок бумаги уже влезает небольшой огрызок. фактически, для текста программы увеличивается локальная читаемость — «могу понять то, что могу окинуть одним взглядом», но при этом страдает глобальная — «могу понять как устроена эта функция»

    плюс чем больше мастерство, чем более лаконичной становится программа — в том числе программа, которую можно прочитать, не задумываясь. у вас самого 5-строчный вариант не вызывает чувства «они бы здесь ещё комментарии дописали!»?

    моё лично мнение — что код должен быть лаконичным (на уровне lowest common denominator для квалификации участвующих в проекте программистов), но конечно не шифрованным, и для повышения читабельности гораздо важнее подробные комментарии, описывающие к чему выполняется каждое действие (для алгоримически сложного кода я пишу комментарии к каждой строчке)