

Debug Clojure Web Apps over HTTP - swannodette
http://devcenter.heroku.com/articles/debugging-clojure

======
lkrubner
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.

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

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

------
markc
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.

~~~
cemerick
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?

~~~
technomancy
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.

------
CarlHoerberg
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..

~~~
technomancy
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.

