Debug Clojure Web Apps over HTTP | Hacker News Reader

Debug Clojure Web Apps over HTTP

devcenter.heroku.com

74 pointsswannodette9 comments

This is partly off-topic, but I think it is interesting to rewind the clock to the year 2000 and remember the reasons why people, at that time, found PHP so interesting. I recall I was drawn to PHP at that time because it made it so easy to make a change to the code and see the change instantly. Not much else offered that, at that time (other than Perl). The world of the JVM seemed burdensome: you had to recompile to see a change. Only Perl and PHP allowed almost live editing of your code, and instant refresh. It is interesting to think about how much tools have advanced, and especially tools in the JVM world. Some of the advantages that Perl and PHP seemed to have in 2000 are advantages that no longer exist.

One can argue that PHP is easier to learn than any language in the JVM ecosystem, but still, I think it is important to think about how much things have changed. The JVM eco-system has largely caught up to script languages in offering ease of editing/ease of seeing one's changes.

Can you run Netty with Aleph (https://github.com/ztellman/aleph) on Clojure/Heroku, or only Jetty?

Sure; Netty works fine as does Tomcat or any other JVM HTTP server. Jetty is popular because it's the simplest without sacrificing performance.

Very cool! Is there any hope of a slime / nrepl unification? I think a lot of people would like to be able to slime-connect to this remote repl from Emacs.

Well, SLIME is the UI; swank is its protocol. I'm by no means an emacs user (and therefore no authority on the subject), but AFAICT SLIME and swank are probably tied at the hip forever.

There is nrepl.el, which looks to be working towards emacs support for nREPL via its standard bencode transport; I don't know anything about it, but I'd hope it's structured such that it's as flexible about transports as nREPL itself is, so that things like an HTTP client can be slipped underneath:

https://github.com/kingtim/nrepl.el

It is on top of this that a SLIME-esque UI could be built that targets nREPL. Who knows, maybe a ton of the "chrome" and non-swank parts of SLIME could be repurposed?

Yeah, in the long run I would like to see SLIME replaced by nrepl.el, but it's going to take a lot of work for that to happen. I think a basic REPL would not be very far off, but the nicer SLIME features like the debugger and the inspector are a long ways off still unfortunately.

Why would you need this? Who store states in-memory in a web app? It will always limit you to one app instance, and it's not like there's a shortage of state saving alternatives..

The in-memory state is a simplified example for the purposes of demonstration, but there are plenty of debugging scenarios where you're trying to track down a problem and for whatever reason have a hard time reproducing it locally. This lets you sidestep the whole issue.

if you want to change configuration data remotely without a restart, and don't want to use jmx. you'd still need to persist the change or else it wouldn't when the service restarts.

Reply on news.ycombinator.com