Clojure действительно заинтересовал меня, и я начал читать учебник по нему: http://java.ociweb.com/mark/clojure/article.html
Рассмотрим эти две строки, упомянутые в разделе «Set»:
(def stooges (hash-set "Moe" "Larry" "Curly")) ; not sorted
(def more-stooges (conj stooges "Shemp")) ; -> #{"Moe" "Larry" "Curly" "Shemp"}
Моей первой мыслью было, что вторая операция должна занимать постоянное время; в противном случае функциональный язык может иметь мало преимуществ перед объектно-ориентированным. Можно легко представить себе необходимость начать с [почти] пустого набора, а затем заполнять и уменьшать его по ходу дела. Таким образом, вместо того, чтобы назначать новый результат большему количеству марионеток, мы могли бы переназначить его самому себе.
Теперь, благодаря прекрасным обещаниям функциональных языков, о побочных эффектах можно не беспокоиться. Таким образом, наборы stooges и more-stooges никогда не должны работать друг над другом. Таким образом, либо создание more-stooges является линейной операцией, либо они имеют общий буфер (как StringBuffer в Java), что кажется очень плохой идеей и конфликтует с неизменяемостью (впоследствии stooges может удалить элемент один за другим).
Я, наверное, заново изобретаю колесо здесь. кажется, что hash-set будет более производительным в clojure, когда вы начинаете с максимального количества элементов, а затем удаляете их по одному до тех пор, пока не станет пустым набором, в отличие от запуска с пустого набора и увеличения его по одному за раз.
Приведенные выше примеры могут показаться не очень практичными или иметь обходные пути, но объектно-ориентированный язык, такой как Java/C#/Python/и т. д. не имеет проблем ни с увеличением, ни с уменьшением набора по одному или нескольким элементам за раз, при этом делая это быстро.
[Функциональный] язык, который гарантирует (или просто обещает?) неизменность, не сможет так быстро увеличивать набор. Есть ли другая идиома, которую можно использовать, чтобы как-то избежать этого?
Для тех, кто знаком с Python, я бы упомянул понимание множества в сравнении с эквивалентным циклическим подходом. Время работы этих двух немного отличается, но это связано с относительными скоростями C, Python, интерпретатора, а не из-за сложности. Проблема, которую я вижу, заключается в том, что понимание множества часто является лучшим подходом, но НЕ ВСЕГДА лучшим подходом, поскольку удобочитаемость может сильно пострадать.
Дайте мне знать, если вопрос не ясен.
