This is the most Java-y Clojure I’ve probably ever read. Just use Java? It’s so verbose and complex for what it is doing. Breaking this down into smaller functions and using core.async would make it even more succinct.
Just want to emphasize this because clojure is indeed a small, lesser known language that has a hard enough time attracting users. This is not what anyone would consider an idiomatic example of using clojure.
dig1 · 3h ago
I don't see why this wouldn't be considered idiomatic clojure code; it makes proper use of all the facilities provided by the language and the main intention of this code is to follow the article. Additionally, the clojure core team often encourages not to shy away from using java code directly, as this approach strikes a good balance between performance and language expressivity.
> It’s so verbose and complex for what it is doing. ... and using core.async
I think this code is actually quite straightforward and easy for a clojure developer to understand. In fact, using core.async in this case would be overkill and could complicate things further.
roenxi · 9h ago
Would it be 200 lines of Java? It'd be 200 lines of just for the boilerplate. It isn't really a selling point of Clojure because it is subjective, but low-syntax high-terseness look of the code is in itself a reward for using the language.
And there isn't anything especially wrong with sticking to Java primitives if someone is comfortable with them. They work fine for Java programmers. The dude doesn't need to learn a new async library to write an LSP client if he doesn't feel like it. Code works, its easy to read, easy to understand and modify.
koito17 · 9h ago
Line count is not very useful to compare without the context of standard library size, third-party dependencies, etc. The code in TFA depends[1] on a JSON library[2] that is about a thousand lines of code (excluding tests) wrapping a Java library for JSON decoding.
Then there's other things to consider, like the fact that this LSP client, while succinct, pays not only the cost of loading Jackson, but also the cost of loading clojure.core, which is quite non-trivial[3]. Startup time for LSP servers and clients definitely matters to some, considering that e.g. even clojure-lsp recommends running native executables over JAR files[4]. Can't find documentation proving it's for quick startup, but it's a plausible rationale for their recommendation of a binary over a JAR.
Note: I have used Clojure professionally and in hobby projects. I think it's nice that one can interactively develop a minimal LSP client and the resulting amount of work is roughly 200 lines of code. I say "minimal" because it's unclear how this client deals with offsets reported by LSP servers, which are all given as offsets in a UTF-16 encoded string. In any case, I still think advertising "LSP client in 200 lines of code" hides valuable information regarding functionality, implementation, "actual" code size, and trade-offs made in the choice of technology stack.
This looks like the other completely normal, idiomatic Clojure programs I've seen which manipulate a StringBuilder. And as Clojurians go I'm far to the succinctness/concision-preferring end of the spectrum.
I'm curious to see your core.async-based version :)
newlisp · 7h ago
It's idiomatic "low-level" Clojure, though. Not everything is a happy place where you're just manipulating maps and vectors like in most examples.
0x1ceb00da · 4h ago
> lesser known language that has a hard enough time attracting users
For very good reasons.
90s_dev · 10h ago
5 hours, 66 points, and still no comments. So we're all thinking the same thing?
0_gravitas · 10h ago
My thoughts are "cool!, neat!"
But I don't feel like the world particularly needs to hear my singleton exclamations, no reason to add unnecessary noise, this isn't reddit.
bjconlan · 9h ago
Yeah I feel yah; But to bolster the post:
I now want to hear more as to why Defold now has a clojure repl! I noticed some musings around some native bindings in gh issues which is "interesting" but I'm not quite getting it. I guess off to the forums I go!
lenkite · 6h ago
Clojure is dying. But its heir - Jank might take the crown.
uludag · 3h ago
> Clojure is dying
is it really though? While I feel the hype is definitely not what it used to be, after getting back into Clojure after a few year hiatus I'm not noticing anything that would suggest it's dying. For example, there's still active Clojure podcasts still in production. Jank may very start exceeding Clojure in terms of hype though.
shivekkhurana · 2h ago
Jank is Clojure.
Languages are often thought of in-coupling with the runtime.
But Clojure is a way of writing code. The official implementation runs on JVM. There are community ports for Node, C#, Go. Jank is the port on CPP.
Jank winning is Clojure winning.
pseudony · 5h ago
The thing about not having loads of syntax is that at some point, there is not much to do aside from polishing.
I don't know why it would feel comforting to people that languages like python/c++/rust keep piling on syntax and features like the people in Rammstein's keine lust, who keep stuffing themselves in spite of their grotesque size.
Haven't looked at jank, but given it looks like lisp, it would be the same thing. No news is actually good news in some cases
lyu07282 · 1h ago
> there is not much to do aside from polishing
If only other languages could just have been designed perfectly first try like <insert your favourite irrelevant lisp dialect>...
pseudony · 1h ago
Right, and popularity is the ultimate determinant of value.
Maybe you are simply ignorant of how many systems might actually run a lisp or similar "irrelevant" programming language in the systems you interact with. From airline reservation systems to banking and high-frequency trading.
JavaScript is not, in fact, eating the world, and nor will Python, Rust or whatever else.
Just want to emphasize this because clojure is indeed a small, lesser known language that has a hard enough time attracting users. This is not what anyone would consider an idiomatic example of using clojure.
> It’s so verbose and complex for what it is doing. ... and using core.async
I think this code is actually quite straightforward and easy for a clojure developer to understand. In fact, using core.async in this case would be overkill and could complicate things further.
And there isn't anything especially wrong with sticking to Java primitives if someone is comfortable with them. They work fine for Java programmers. The dude doesn't need to learn a new async library to write an LSP client if he doesn't feel like it. Code works, its easy to read, easy to understand and modify.
Then there's other things to consider, like the fact that this LSP client, while succinct, pays not only the cost of loading Jackson, but also the cost of loading clojure.core, which is quite non-trivial[3]. Startup time for LSP servers and clients definitely matters to some, considering that e.g. even clojure-lsp recommends running native executables over JAR files[4]. Can't find documentation proving it's for quick startup, but it's a plausible rationale for their recommendation of a binary over a JAR.
Note: I have used Clojure professionally and in hobby projects. I think it's nice that one can interactively develop a minimal LSP client and the resulting amount of work is roughly 200 lines of code. I say "minimal" because it's unclear how this client deals with offsets reported by LSP servers, which are all given as offsets in a UTF-16 encoded string. In any case, I still think advertising "LSP client in 200 lines of code" hides valuable information regarding functionality, implementation, "actual" code size, and trade-offs made in the choice of technology stack.
[1] https://github.com/vlaaad/lsp-clj-client/blob/a567e66/deps.e...
[2] https://github.com/metosin/jsonista/blob/c8f2b62/project.clj...
[3] https://clojure-goes-fast.com/blog/clojures-slow-start/#cloj...
[4] https://clojure-lsp.io/installation/#embedded-jar-legacy-exe...
I'm curious to see your core.async-based version :)
For very good reasons.
But I don't feel like the world particularly needs to hear my singleton exclamations, no reason to add unnecessary noise, this isn't reddit.
I now want to hear more as to why Defold now has a clojure repl! I noticed some musings around some native bindings in gh issues which is "interesting" but I'm not quite getting it. I guess off to the forums I go!
is it really though? While I feel the hype is definitely not what it used to be, after getting back into Clojure after a few year hiatus I'm not noticing anything that would suggest it's dying. For example, there's still active Clojure podcasts still in production. Jank may very start exceeding Clojure in terms of hype though.
Languages are often thought of in-coupling with the runtime.
But Clojure is a way of writing code. The official implementation runs on JVM. There are community ports for Node, C#, Go. Jank is the port on CPP.
Jank winning is Clojure winning.
I don't know why it would feel comforting to people that languages like python/c++/rust keep piling on syntax and features like the people in Rammstein's keine lust, who keep stuffing themselves in spite of their grotesque size.
Haven't looked at jank, but given it looks like lisp, it would be the same thing. No news is actually good news in some cases
If only other languages could just have been designed perfectly first try like <insert your favourite irrelevant lisp dialect>...
Maybe you are simply ignorant of how many systems might actually run a lisp or similar "irrelevant" programming language in the systems you interact with. From airline reservation systems to banking and high-frequency trading.
JavaScript is not, in fact, eating the world, and nor will Python, Rust or whatever else.