Martin, Thank you for the pushback. :-)
On Mar 19, 2011, at 8:30 PM, Martin Blais wrote: > Hi, > > After Rich's suggestion at the recent NYC meetup, I had a > detailed look at inferior-lisp vs. Slime, and nREPL, read > Chas' document, wrote a bit of code, tried to figure out the > issues for myself; here are my conclusions on nREPL: > > > - In the Slime/Swank model, there is a single IDE that > connections to N possible types of LISPs via a rich > protocol (and a lot of corresponding work on the > workflow/GUI side in Emacs in the various fancy Slime > functions I discussed at the meetup). > > Emacs/Slime -> Clojure, sbcl, clisp, Allegro, etc. > > My understanding of nREPL is that it inverts the problem > by making M different IDEs able to connect to one type of > LISP VM (Clojure). > > Emacs, Eclipse, NetBeans, whatever, etc. -> Clojure > > One of the assumptions is that by keeping nREPL simple the > various clients will send whatever necessary Clojure code > they want in order to perform the same common tasks that > the Swank protocol already describes. I think that this is > touted to be "powerful" because you can eval anything you > like, i.e., "just send it some clojure expression you > want". But from my POV, it only serves to move the > complexity from the server/VM (currently in swank-clojure > and the protocol) to the client/IDE. > > I think this is wrong, because every single IDE client > will have to adapt itself to the various changes occurring > in the Clojure VM as it evolves. This is just creating M > times the amount of porting problems (for each client). By > keeping the complexity on the server, every IDE that > speaks a common protocol (*) works between versions. There's no reason why the server couldn't provide a standard set of introspection / tooling utilities available -- it would be as easy as adding a proper dependency e.g. in your web project's pom/project.clj. A few people have been discussing the desired capabilities, and have started documenting desired semantics, and where each capability has already been implemented. > One could argue that a rich client library could be > included that provides similar functionality that is > currently provided by swank-clojure, i.e. the problem is > lessened, because all the clients now share the same > client library, so you port over the client lib and > recompile and that should be enouhg. But what language do > you do this in? Clojure itself? Pure Java? What about the > Emacs-LISP client? Then you have a problem of having > multiple client libraries that need be ported. If you want to load in the aforementioned standard set of utilities from the client side (perhaps if the nREPL server doesn't have them available already), doing so from any client should be straightforward. It's just loading Clojure code, after all. No porting. > - I take another issue at nREPL: if someone is going to > implement a request/response protocol that supports only > generic requests (because the complexity should live in > the client), why bother at all, why not instead just make > it a really, really simple network REPL, without any > protocol at all? e.g. all input means "eval", output is > just output, no ids no nothing.... just a socket that you > could connect to with telnet and have a repl right there, > no protocol. telnet localhost 4005, type "(+ 2 2)" at the > terminal, see "4" appear. That's it. > > I think it would be pretty straightforward to extend > Emacs' inferior-lisp-mode to support talking to a socket > like that instead of having to start a subprocess. This > would give you "vanilla" communication with a live Clojure > VM without having to start the VM from a parent process. I > rather like this idea; it's the simplicity you currently > enjoy with inferior-lisp, but over a socket; simple, can't > break. Because a synchronous client is unsuitable for REPL tasks that require or desire asynchronous evaluation of expressions. > IMHO if people will bother implementing a request/response > protocol, why not just stick with a rich protocol like > Swank's? It'll just be reinventing the wheel otherwise. Swank is fundamentally emacs-only, and is defined outside of the Clojure community. I discuss the issues with swank in the readme here: https://github.com/clojure/tools.nrepl > - Another problem with Slime that turns people off is the > weirdness in where the output goes. To detail the > weirdness: How SLIME works (or its problems) is entirely orthogonal to network REPL design IMO. nREPL breaks up *err*, *out*, and a printed representation of expression results into separate slots in its responses, so clients can display response data however is appropriate for their environment. Note that I'm planning on adding optional multiplexing of System/out and System/err (much like is done in Cake) to nREPL so that clients can subscribe to those streams as desired. > (*) Please note: I am aware that only Emacs supports the > Swank protocol right now but I don't see why other IDEs > couldn't support it too--it's just made up of LISP forms > after all; in other words, if someone wants to replace > the swank protocol by an equivalent one with a different > encoding I don't really see the point. Anyway, for this > discussion I'll assume emacs-rex is a suitable enough > protocol; in fact, I think it probably is, because it > has already proved itself with a large number of LISP > environments, it has "history". In any case, that's a > separate discussion. I think of emacs-rex as just "the > protocol" and that other IDEs could implement it to talk > with swank-clojure. Again, the nREPL readme goes into the motivation for discounting swank. As far as I can tell, its big advantage is that it is what SLIME uses. I've said this before at ClojureNYC, in irc, and elsewhere…I'm not an emacs/SLIME user, so I'm perhaps the last person those who do use those tools should listen to. That said, it seems to me that moving away from SLIME and putting together an emacs toolchain for Clojure that is *built for Clojure* could yield a lot of benefits, assuming compatibility with Common Lisp environments is unimportant to you. Clojure isn't just another Lisp -- while it's great that emacs users have been able to use pre-existing Lisp tooling with Clojure, that's surely not an optimal situation (even leaving aside what, from an outside observer, seems to be a lot of pain associated with breakage due to upstream changes and such). If you were to consider what a dedicated Clojure toolchain for emacs would look like, I'd be very surprised if it involved swank. Cheers, - Chas -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
