5 ms·
I have used both in production setting and can say that the tooling for most CL implementations is just plain light years ahead of Clojure, and there is no sign
by Guthur 10y ago
I have used both in production setting and can say that the tooling for most CL implementations is just plain light years ahead of Clojure, and there is no sign of it really improving.
For Clojure the interactive debugging experience is just plain dreadful and for a dynamic language this is pants on head crazy imo. For me a dynamic language has to have a good interactive debugging experience because you have foregone the support of a static compilation and instead wish to reason about your program at runtime. But with the JVM stack traces and lack of interactive debugger Clojure just does not support you in this regard. And as a side note the lack of an identity print is annoying as well e.g. (+ (print 4) (print 4)) "4" "4" 8 (yes, it's easy to add...)
Clojure's decision to use persistent data structures is good but it's really the only standout thing for me other than some syntax sugar like hash maps.
- Royalaid 10y agoHave you tried out recent versions of CIDER? I find it works good for that I need. But I have to say that the big problem I have is Emacs and its inability to handle long strings.
- Guthur 10y agoI may be missing some massive leap but until it does this http://malisper.me/2015/07/07/debugging-lisp-part-1-recompilation/ http://malisper.me/2015/07/07/debugging-lisp-part-1-recompil...
- Royalaid 10y agoAHHH, not quite the same, nor as good but sayid(https://github.com/bpiel/sayid https://github.com/bpiel/sayid) is a step in the right direction
- ane 10y agoCIDER has had debugging abilities like this for a year, there's a sexp based interactive debugger that allows injection, evaluation, stepping etc. Here's a 39 second video about it https://www.youtube.com/watch?v=A3JAlWM8qRM https://www.youtube.com/watch?v=A3JAlWM8qRM
- lispm 10y agoThe debugger needs to 'instrument' the code with breakpoints...? That's something different. In a Lisp system I would have an arbitrary amount of code and can halt and inspect/debug any code without any prior need to 'instrument' code.
- ane 10y agoTo debug a function, yes, you need to eval the form using instrumentation. Then the debugger starts when this form is evaluated. This is the the only major difference to what SLIME provides. Adding breakpoints is somewhat easier with cider, you don't need to call break but you can just add a breakpoint to any sexp by pressing b.
- lispm 10y ago> Then the debugger starts when this form is evaluated. You mean the stepper using break-instrumented code? That's just a part of what one would call 'debugger' in Lisp. What CIDER calls 'debugger' would be mostly called 'stepper' in Lisp. http://franz.com/products/allegro-common-lisp/stepper_dialog.lhtml http://franz.com/products/allegro-common-lisp/stepper_dialog... http://www.lispworks.com/documentation/lw70/IDE-M/html/ide-m-186.htm#pgfId-853131 http://www.lispworks.com/documentation/lw70/IDE-M/html/ide-m... > Adding breakpoints is somewhat easier with cider, you don't need to call break but you can just add a breakpoint to any sexp by pressing b. LispWorks does that, too. Usually via a break icon in the window toolbar or the context menu.
- zehemer 10y agoToggling pretty printing via `cider-repl-toggle-pretty-printing` may provide a workaround there. Courtesy of: https://github.com/clojure-emacs/cider/issues/1115 https://github.com/clojure-emacs/cider/issues/1115
- boogiewoogie 10y agoFor debugging try https://cursive-ide.com https://cursive-ide.com it uses intellij and has improved nicely in the past year.
- cdegroot 10y agoThe JVM indeed quickly got me disinterested in Clojure. However, I have similar issues with other (free) Lisps, with probably only Emacs Lisp being the exception. As a Smalltalker ("the other heroin of the programming world") I'm used to a highly integrated and responsive development environment; from what I heard from other Lispers, the quick feedback and gradual building up of your program is a shared aspect, but the thing that Smalltalkers always bring up and Lispers less so is also that your program and your IDE are basically indistinguishable, which is quite powerful because it makes it trivial to adapt your IDE to your project as you go. In the Lisp environments I've tried - latest being Emacs+SBLC - the split between editor and REPL seems unnatural to me, more so because in the standard case you work with two different dialects of the language. It seems that only ACL and LW have more unification. Am I wrong and are the $$$$ versions not better in that respect and should I just drop my Smalltalk habits/arguments when learning CL?
- lispm 10y ago> also that your program and your IDE are basically indistinguishable Lisp provides that,too. But you can also deliver programs with the IDE and much of the development tools removed. Examples for integrated IDEs: Allegro CL on Windows/Unix+Gtk, Clozure CL (free) on Macs, LispWorks on Windows/Macs/Unix+GTK/Unix+Motif. There the IDE and the user code runs in one Lisp. Other examples: Lisp Machines, CMUCL on X11, ... there is also the McCLIM project where some ideas from the Symbolics GUI are used. There are also countless other implementations from the past, which are now mostly forgotten, which had an integrated IDE (Golden Common Lisp for Windows, Corman Lisp for Windows, Macintosh Common Lisp, Medley, Open Genera for X11...),
- iheartmemcache 10y agoYou should really write an analysis contrasting the functionality of these IDEs, especially those 'mostly forgotten' ones so they aren't lost into the abyss. I've used Squeak Smalltalk and DrRacket in the past. As someone who finds slime/swank/sbcl in Emacs a pleasure, I can only imagine how great some of those other environments can be.
- vram22 10y ago