Clojurians Log v2

@bozhidar: it seems ten thousand messages are exchanged fast. I was going back here to see if I could check up that new tooling thing you posted about the other day, but now it is gone. Can you remind me what it was?

Sorry for being so unspecific, my memory is vague here and there is also the possibility that I misunderstood the whole thing.

@pez https://github.com/clojure-emacs/orchard

Common functionality for Clojure editors.

It’s work in progress, but that’s basically the heart of CIDER nREPL middleware. (and, of course, the middlewares are also editor agnostic)

The idea behind orchard was to share the functionality with non-nREPL clients.

@pez your work is based on cider nrepl isn't it? 🙂

@bozhidar Thanks! Appreciated. I'll probably come back with questions. 😃

@dominicm yes

Well, then you’re using orchard already. 😉

Haha, you live and learn. I really need to check it out then.

Btw, @bozhidar, saw your talk from Bulgaria (I think it was) about the bad parts. Awesome stuff. Started watching the Stewardship talk you recommended. Can't wait for a time slot to finish it.

Happy to hear this! Wasn’t my finest talk (was pretty sick at the time of that conference), but I’m glad people find it useful. I should revisit it down the road. I’ve got many ideas on the subject.

I am in my first learning phase of Clojure things, I found it very useful!

So, a noobish question then: we are thinking about ways to support Lumo. Not all that seriously thinking, since it seems a lot of work, but anyway, orchard could maybe help with such an undertaking?

Or, no, maybe it is tied to the JVM and not suitable for selfhosted Javascript stuff?

Orchard does aim to smooth over jvm/cljs differences to the degree it makes sense.

The support isn't there yet, but I think it's intended that it will integrate the cljs-tooling library.

Sounds great. We have tons of work to do without bringing Lumo into the mix, but I will keep an eye on this development, then.

While at this, have you guys seen any initiatives towards writing a language server (Microsoft style) for Clojure?

Yeah, I’ve seen a couple of projects on GitHub, but I don’t think there’s anything that mature yet.

I guess that lsp for Clojure would mostly be a wrapper around something like nREPL or a socket server and would just reuse existing functionality to provide a new interface.

Makes total sense.

An alternative approach would be to try to do mostly static analysis in a lsp implementation (I think I saw one of those), but I don’t think that’s the way to go given all the work that has gone into building REPL-powered tooling.

https://github.com/snoe/clojure-lsp

That’s the one I saw doing static analysis instead.

We have talked a bit about static analysing. But I think much of the power comes from having that REPL at your fingertips, so anything REPL-powered makes most sense for us.

You also get more accurate results by inspecting the actual state, rather than statically "guessing"

macros throw a spanner into static analysis methods.

The two approaches are not exclusive of each other, but there’s one fundamental issue with static analysis in Clojure - it’s not that static.

You have to eval the code to know what you’re analyzing, and that’s rarely what the users want.

That one you posted has a POC vscode client, very interesting.

@pez it's also coupled to lein, just as an fyi

We do some static analysis with refactor-nrepl and people are often surprised when their namespaces get evaluated “by themselves”.

Very good FYI, @dominicm, thanks!

@bozhidar true. I also have had some reports of certain records just not working for unknown reasons.

As for the LSP in general - knowing how wider the protocols for Lisp dev environments are, I wonder if they’ll ever gain a footing in the lisp world. Sure, the basic ops are the most important, but I can imagine that many people would benefit immensely from extra functionality outside the LSP standard.

You can extend LSP with additional functionality.

What are some examples on what lispers might miss?

eval

Haha, wow.

LSP has been designed in the context of rust/c++/etc. which don't really have a repl at all

RPL is not that fun.

I might be making that up, but I'm pretty sure it's true

I haven't looked into it for a while

> You can extend LSP with additional functionality.

Ah, didn’t know this.

But overall I think you’re right - all of this was created with different languages in mind. In a way for while our “LSP” was been nREPL extended with some extra middleware.

@pez about lumo support at the moment there is only a socket REPL. Inf-clojure just sends the form and shows the response..very basic. I have been thinking and @futuro really had this idea, of adding a bencode layer + sessions and support nRepl but it is a daunting task

@richiardiandrea I hope someone undertakes it. :face_with_cowboy_hat:

We can solve the self-hosted IO problem, and potentially get a single library that nREPL code can use for file system and networking.

The major hurdle I see still is that the async methodologies are so fundamentally different.

In the JVM, call future and you’re off to the races. On Node, all of the async involves passing callbacks

And in JS in general, that’s sort of a hard limit imposed by the JavaScript spec.

@futuro does the nrepl code base run a lot of futures?

haven't even looked at it

I really want a self-hosted nREPL server (I really want Cider, tbh) but I won’t have good answers to that question until I face it.

I want the same...

😄

The nREPL uses some, but cider uses a lot.

So a base nREPL server isn’t too hard (the original implementation is very small), but getting cider support will be more work.

It’s the dream 😁

when you say cider I guess you mean cider-nrepl?

That being said, it probably makes the most sense to look at what operations the cider code supports and remake that from a self-hosted perspective.

because cider can work with no middleware as well

Yeah, I think so.

Really?

yeah, if I understood @bozhidar correctly

so the first thing would be to get the protocol + sessions going

protocol meaning - bencode - https://github.com/themasch/node-bencode