This REPL like Nodejs REPL are great efforts, if limited to a teletypewriter emulator.
They're pretty terrible compared to what was available in Lisp machines and Smalltalk (for example) from decades ago and what now live on in McCLIM's Lisp Listener https://common-lisp.net/project/mcclim/excite.html and Pharo Smalltalk Playgrounds.
The main problem is the Print part results in "dead text". For example, you can't re-select it (other than using history shortcuts), you can't interact with it (it's dead, afterall) and there was only one representation of it (some kind of "to-string" for it). You can't even inspect it.
Beyond that, you're stuck with the teletypewriter environment. You can't display an image, or sound wave, statistical model graphically etc, let along interact with them.
That is just a painfully awkward inspector. I don't know why Halloway isn't aware of the prior art. I thought he had some experience with Common Lisp...
This looks great, I'm looking forward to giving it a go! Since I've found myself using VSCode pretty much full time now, my current workflow is to use the Calva plug-in [0] which provides a nice REPL amongst many other awesome features.
TL;DR: absolutely yes it's competitive with CIDER; there may be experiments in the CIDER ecosystem that you won't get with Calva but 99% of the stuff you will actually use works totally fine in Calva and if you like VS Code you should definitely not think twice about it :)
Caveat: I don't use Calva myself, but I'm the president of the Clojurists Together Foundation. We just funded Calva's development and of course did some due diligence in the process. It's definitely got a ton of features, it's stable, but it's maybe slightly less feature-complete than the CIDER ecosystem right now. Hopefully funding helps change that, I'm a happy Emacs + CIDER user but rising tides lift all boats :-) One thing I love about Calva is that there's less fiddling. You just turn it on and you get 99% of the actual functionality of a top-end Emacs setup, except you didn't spend hours getting it to actually work. (Spacemacs makes this a lot better, but not everyone uses Spacemacs.)
While Calva isn't CIDER, it does build on stuff that is either directly from CIDER or de facto from CIDER (e.g. nrepl), so fortunately there's a lot of development effort that directly or indirectly helps both projects.
Finally, the shameless plug: if developing the Clojure ecosystem is important to you you should consider giving us (Clojurists Together Foundation) money -- we've funded critical infrastructure like CIDER, fireplace, Ring, Reagent, shadow-cljs... Oh, and we keep a little thing called Clojars afloat :-)
This seems unfair towards CIDER. Cider has excellent debugging, stacktrace navigation, integration with other tooling and more... that isn't available in Calva.
I would never say that you can't use Calva to get work done, but CIDER has a good deal more than what Calva offers currently.
I could accept that maybe "99% of users don't need what CIDER offers", but saying that Calva is 99% of what CIDER offers is just completely incorrect.
... Good thing that I said "but 99% of the stuff you will actually use works totally fine in Calva" which is a lot closer to your first example than the second? Given that I explicitly acknowledge the feature gap?
> Finally, the shameless plug: if developing the Clojure ecosystem is important to you you should consider giving us (Clojurists Together Foundation) money -- we've funded critical infrastructure like CIDER, fireplace, Ring, Reagent, shadow-cljs... Oh, and we keep a little thing called Clojars afloat :-)
I will definitely give you folks some money for that. Thank you for making it a thing! :- )
It will depend on what features your workflow appreciates. Being the creator of Calva I am biased, of course, but it certainly supports my workflow.
The big culprit right now is that Calva doesn't handle large results well at all. I find strategies around it, but it is a thing that really needs to be fixed and it will be in focus during the Clojurists Together funding.
Another feature lacking, that CIDER has, is a step debugger. Something that doesn't affect my workflow very much, but I know some people will lack it. It is also part of what we will try to fix during the CT funding period.
I'll give this a try. I'm currently using VSCode & Calva. It's been a bless! I create an uberjar with Clojure's nrepl server and start that server with my java project's dependent jars. At the end, I am able to "jack-in" the embedded repl server running with in a production-like environment. Needless to say, when I demoed this stuff, many engineers were excited to learn more about Clojure. They saw I inspected, ran and modified behavior of existing code all in the REPL without even redeploy/restart anything.
I have to say that there are 3 things that I am very grateful for acquiring in 2019: got into Bach's music, learn to play the piano and finally "got" LISP via Clojure.
This looks super cool! I'd love a pitch for when you use a terminal clj repl versus your development environment. For years using Python I was constantly experimenting in a terminal REPL, but now with CIDER (or other IDEs--I just happen to use CIDER) it feels like the integration is so good I just do all my REPL work as a side effect of using an editor.
For a long time I ran venantius/ultra but too many of the dependencies ended up randomly breaking stuff. These deps look a little less likely to do that so I'll give it a shot :)
Not trying to convince anyone, but if someone is already using Clojure with Emacs (which the annual survey seems to suggest is the most common case): those are all features you get with CIDER + clj-refactor as well. If you use spacemacs, I think they mostly just work out of the box if you turn on the Clojure layer (and maybe turn on clj-refactor -- I forget if that's an option or a default now).
That's not one of the features GP enumerated, but, yes, there are lots of flavors of accomplishing that while using CIDER.
The two most common ways I've seen people accomplish something like that is probably Clojure's builtin inspector functionality and CIDER's general ability to display any kind of image (which conveniently lets it do stuff like plotting as well). If your focus is on the permanence and documentation aspect of the notebook experience, you're probably going to be happier with ob-clojure or Gorilla REPL. If your focus is on the exploratory part, you're probably going to be happier with REBL, or if you really want everything inside an emacs buffer you might do that with walmartlabs' datascope. I do everything with cider-inspect because I don't find the graphical visualization that valuable -- most of my data structures are too large so I ~always end up writing a specter query ~immediately.
All of this is for Clojure specifically. If you're writing in-browser apps you'll probably like frisk (through re-frisk or data-frisk), where you can do this stuff right in your browser next to the app:
Slightly tangential: the Rainbow Brackets plugin is awesome and I use it in PyCharm too because it makes nested parens in math formulas a bit easier on the eye.
I use it in every single IntelliJ IDE I use. It is highly underrated in my opinion. When I first saw it suggested I was immediately sure it would be useful. Somebody tried to argue that good spacing is the way to resolve any confusion with multiple parens, but I don't think so, visual colors are way better. Java devs love to put curly braces egyptian style, I prefer the C# approach personally, but with Rainbow braces I don't have to care.
> It will also do some autocomplete, although this seems flakey
Can you explain this point. Is it possible that you might have forgotten to sync the new code with the repl. Editor and repl use different completion backends in cursive.
It looks cool, but I never understand "obsession" with having nice [Lisp] REPL in the terminal. I almost never type directly in the REPL, even when I have it in my IDE. One of the selling points of Lisp that you can eval any expression from your editor, isn't that right?
Based on Eric Normand's REPL Driven Development series, if I'm not mistaken, he considers evaling from the editor part of the REPL driven development flow, so it seems that evaling from the editor could also be considered "using the repl"
edit...
I think I'm seeing that your question is more of a point that you're making. Yes, it's nice to be able eval from the editor, but now being a professional Clojure developer after having been a Python developer for years, I would agree with the arguments that typing lisp (s-expression) code in a repl is much easier than Python, because you don't have to worry about indentation. This probably applies to other languages for different reasons. eg. Java... I can't even imagine what a REPL would be there. My repl usage in python was usually just calling a function I wrote in the editor. Same with my little experience in Ruby.
What languages do you usually use? REPLs for languages like python and nodejs are never as integrated and well working as REPLs for lisp languages like Clojure. Probably the structure of the code that lisp almost forces you to have, makes the REPL experience much easier. Especially in Clojure where most functions are side-effect free which means you can run them out-of-context, as long as you've defined the vars it's using since before.
Because non-homoiconic languages don't have "true" REPLs. At best they have "interactive environments". What's great about Lisp, and the point people complaining about parentheses miss, is that you can eval any [sub]expression without any preceding ceremony. That is not possible in almost any other language (maybe with exception of Smalltalk), simply due to the nature of the language syntax.
In Clojure, if you have something like:
(foo [a b] ((c a) b))
you can evaluate every single part of it, you'd get immediate feedback, what is `a`, what is `b` and `c`, the result of `(c a)`, the result of the entire thing, etc. Similar thing in JS would be something like:
let foo = (a, b) => { return c(a)(b); }
It's already more difficult to edit, there's no "structure", it's not easy to evaluate arbitrary pieces without "dancing around", introducing temp variables. Given Clojure code snippet is also data, it can be send over the wire, send directly to the connected REPL instance, etc.
That's what gives Lisp developers a substantial speed of development. When people talk about "what's good about Clojure", they usually say: immutable data-structures, stability, hosted nature - can target JVM, JS, BEAM and CLR, can even have interop with Python and R. But the coolest thing about Clojure and Lisps in general - they provide "true" REPLs.
No, Smalltalk is not fully homoiconic, it has some nice "reflective" abilities, i.e. it's possible to view "code as data" that allows good REPL experience. But it's not a homoiconic language.
Feels like we're talking past each other at this point. You're preaching to the choir here, and not sure where that came from. Basically the question was "What language do you use?" and now you're trying to tell me why lisps are great. I agree with everything you're saying, I write Clojure code professionally during the day-time, but your comment just came from nowhere.
Edit: or maybe you responded to the wrong comment?
Yes, I'm sorry for the confusion. You use Clojure, I use Clojure, we're both commenting in a Clojure related post. I know that I'm "preaching for the choir", and stating the obvious. But to many other people scrolling through the comments, all that may not be obvious.
Please don't go that route. I've worked with several language ecosystems. Clojure community is one of the most open, acceptive, diverse and friendly communities out there. This thread is simply misunderstanding/misreading the intent of the commenters. It happens, nobody got hurt.
I think what @iLemming meant is that she/he doesn’t understand the appeal of having a fancy REPL _UI_ (mostly virtual terminal emulator-based readline implementations) and working with it _directly_ as opposed to sending forms from your editor of choice to a REPL server.
I kind of hold the same opinion. Being more powerful, feature-rich, flexible than readline implementations, editors are, by design, more suited to editing forms. And, I believe, “sending forms from your editor to the REPL” is what the “REPL-driven development” encourages.
Ilemming doesn't seem to care about the UI to the REPL. They simply don't care about REPLs at all. At least that's what I understand from:
> I almost never type directly in the REPL, even when I have it in my IDE
I agree that it's more comfortable to be able to send forms from your editor to be evaled somewhere else, I myself don't use the CLI REPL very much, but since I use vim-fireplace, I guess my REPL is in the terminal anyways.
When you write Clojurescript, you don't need to use Chrome Dev Tools much. You can eval things in your IDE and the changes will be [almost immediately] reflected in the UI.
Sure, I was mentioning it related to JavaScript REPL experience, and having nice things like immediate visualization of data structures, debugging tooltips and such.
Naturally Clojure based IDEs like Cursive are also quite nice.
I love seeing what people are doing in the space of REPL interactivity. I've been working on a similar project, but for Node.js[1]. One of the things I've found the most helpful so far is color highlighting the input, in addition to the output.
I recommend also having a look at OCaml's utop, it's also a very advanced REPL with at least some similar features, and taking advantage of OCaml's static typing.
Useful for newbies and for small experiments. Once you learn how to evaluate s-expressions directly from an IDE connected to a REPL instance - you probably would never directly type in the REPL again.
Yeah, that's a bit unclear, though I think the intention is to preface the format for those familiar with Asciinema (similar to "Video - " or "Slide Deck - ")
They're pretty terrible compared to what was available in Lisp machines and Smalltalk (for example) from decades ago and what now live on in McCLIM's Lisp Listener https://common-lisp.net/project/mcclim/excite.html and Pharo Smalltalk Playgrounds.
The main problem is the Print part results in "dead text". For example, you can't re-select it (other than using history shortcuts), you can't interact with it (it's dead, afterall) and there was only one representation of it (some kind of "to-string" for it). You can't even inspect it.
Beyond that, you're stuck with the teletypewriter environment. You can't display an image, or sound wave, statistical model graphically etc, let along interact with them.