Clojure действительно пробудил во мне интерес, и я начал изучать его: http://java.ociweb.com/mark/clojure/article.html
Рассмотрим две строки, упомянутые в разделе «Набор»:
(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, интерпретатором и не имеет корней в сложности.Проблема, которую я вижу, состоит в том, что понимание набора является часто лучшим подходом, но НЕ ВСЕГДА лучшим подходом, поскольку читаемость может сильно пострадать.
Позвольте мнезнать, если вопрос не ясен.