Clojure REPL философия и полезные приложения

Question

Извините за длинный пост, но этот форум всегда просит варианты использования: -).

Мне часто приходится писать служебные приложения (GUI и командную строку) для моей организации.Я чаще всего пишу их на Java, а в последнее время на Scala.

«Философия» в Clojure (и других Лиспах), кажется, сосредоточена вокруг REPL, и я должен согласиться, что это создает хорошую среду разработки, ноЯ, очевидно, не могу создать утилиты, которые требуют от пользователей «Установить Clojure и Clojure-contrib, затем разархивировать утилиту в каталог на жестком диске, запустить Clojure из командной строки, используя следующий путь к классу, ...».Пользователям все равно, что утилита написана на Clojure.Они просто хотят указать и щелкнуть или, самое большее, набрать "java -jar Utility.jar -?"в командной строке.

Мой вопрос касается компиляции и разделения приложения на множество пространств имен / файлов.

Я знаю, что метод main должен находиться в файле Clojure, который включает (gen-class...) команда (или предложение :gen-class в команде ns).Я делаю то же самое для дополнительных файлов Clojure, или они должны быть оставлены как исходный код, который упакован в JAR и загружен файлом main?Как насчет тестирования дополнительных файлов из REPL во время разработки?

Я использую leiningen, cake и maven для создания автономных JAR-файлов (содержащих распакованный clojure.jar, clojure-contrib.jar и commons-файлы cli.jar), но до сих пор я писал свой код в том же файле, что и метод main.

Answer 1

Когда дело доходит до разделения, я бы держал их в отдельных пространствах имен / файлах:

• Один для пространства имен :gen-class, содержащий -main и все другие подобные Java вещи.
• Другое пространство имен для всех функций.

В идеале ваш main должен содержать только вызов функции из другого пространства имен или, возможно, некоторую логику для оценки или перепаковки args.

Ваш вопрос кажется очень похожим на разделение между кодом логики и кодом пользовательского интерфейса. Вы могли видеть пространство имен с :gen-class как просто интерфейс, предоставленный вашей программой для Java-кода, ничего более.

---

Когда дело доходит до утилит (таких как командная строка, приложения Swing и т. Д.), Проблема с Java в целом возникает из-за времени запуска JVM.

Теперь вы можете решить эту проблему, заставив серверное приложение постоянно выполнять REPL в фоновом режиме и, скажем, каким-то образом получать s-expr для оценки и возвращать результат. Это можно сделать как простое веб-приложение, которое получает s-expr в качестве параметра URL и возвращает результат. Теперь вы можете использовать все утилиты на старой Java или использовать bash с помощью wget, поскольку все, что вам нужно сделать, - это получить доступ к URL (при условии, что сервер с repl работает в фоновом режиме).

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

Да, и еще одна вещь, порт, на котором выставлено repl webapp, вероятно, должен быть закрыт для внешнего мира, чтобы предотвратить инъекции Clojure: D

Answer 2

Вам решать, будете ли вы AOT-компилировать свой .clj в .class или позволить Clojure делать это динамически во время выполнения. В целом, я считаю, что во время разработки проще избежать AOT и просто использовать AOT для повышения производительности в тех случаях, когда стоимость компиляции вашего .clj на лету не имеет смысла (ограниченные среды, такие как Google App Engine или утилиты, где время запуска является критическим). Для серверных процессов, которые будут работать долго, AOT-компиляция не дает больших преимуществ.

Существует множество сложностей, связанных с использованием классов AOT во время разработки, которые характерны для различных сред разработки.

Недостатком AOT является то, что ваши скомпилированные классы могут быть несовместимы с будущей версией Clojure, и это более вероятно, чем несовместимость ваших clj-файлов. Это может стать более важным с течением времени.