Более читаемы функциональный Clojure или обязательный Groovy?

править: может больше не иметь отношения

Clojure для меня запутан. Он содержит больше абстракций, которые необходимо понять. Это цена использования функций высшего порядка, вы должны знать, что они означают. Так что в единичном случае императив требует меньше знаний. Но сила абстракций в их способах сочетания. Каждый императивный цикл должен быть прочитан и понят, тогда как абстракции последовательностей позволяют избавиться от сложности цикла и комбинировать мощные операции.

Я бы также сказал, что версия Groovy, по крайней мере, частично функциональна, поскольку она использует сбор, что действительно map, функция высшего порядка. В нем также есть некоторое состояние.

Вот как я бы написал версию Clojure:

(defn positions2 [coll]
  (let [current (atom 1)
        if-same #(if (= %1 %2) @current (reset! current (inc %3)))]
    (map if-same (cons (first coll) coll) coll (range (count coll)))))

Она очень похожа на версию Groovy в том, что в ней используется изменяемый "

Я тоже изучаю Clojure, и мне он очень нравится. Но на этом этапе моей разработки версию Groovy было легче понять. Что мне нравится в Clojure, так это то, что я читаю код и говорю "Ага!" опыт, когда вы, наконец, «поняли», что происходит. Что мне действительно нравится, так это то, что происходит через несколько минут, когда вы понимаете все способы, которыми код может быть применен к другим типам данных без каких-либо изменений в коде. Я сбился со счета, сколько раз я работал с каким-то числовым кодом в Clojure, а затем, немного позже, подумал о том, как этот же код можно использовать со строками, символами, виджетами, ...

Я использую аналогию с изучением цветов. Помните, когда вас познакомили с красным цветом? Вы поняли это довольно быстро - в мире есть вся эта красная фигня. Затем вы услышали термин пурпурный и на какое-то время заблудились. Но опять же, после некоторого большего воздействия, вы поняли концепцию и получили гораздо более конкретный способ описания определенного цвета. Вы должны усвоить концепцию, держать в голове немного больше информации, но в итоге вы получите что-то более мощное и краткое.

Я согласен с Тимоти: вы вводите слишком много абстракций. Я переработал ваш код и закончил так:

(defn positions [coll]
  (reductions (fn [[_ prev-score :as prev] [_ score :as curr]] 
                (if (= prev-score score) prev curr))
    (map vector (iterate inc 1) coll)))

Что касается вашего кода,

(defn use-prev [[a b]] (= a b))
(defn pairs [coll] (partition 2 1 coll))
(map use-prev (pairs coll))

можно просто рефакторировать как:

(map = coll (rest coll))

Clojure на первый взгляд более запутанный; хотя может быть и более элегантно. ОО - это результат, позволяющий сделать язык более "понятным" на более высоком уровне. Функциональные языки кажутся более "алгоритмическими" (примитивными / элементарными). Это именно то, что я чувствовал в данный момент. Возможно, это изменится, когда у меня будет больше опыта работы с clojure.

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

У меня две проблемы:

1. Насколько легко с первого взгляда понять, что делает код ?. Это важно для тех, кто сопровождает код.

2. Насколько легко угадать логику кода? Слишком многословен / многословен ?. Слишком кратко?

«Делайте все как можно проще, но не проще».

Альберт Эйнштейн

Groovy также поддерживает различные стили решения этой проблемы:

coll.groupBy{it}.inject([]){ c, n -> c + [c.size() + 1] * n.value.size() }

определенно не переработан, чтобы быть красивым, но не слишком сложным для понимания.