Fork me on GitHub

People of Clojure, I have a question. I read somewhere that it's possible to connect Clojure REPL to java app in debug mode. Did Anybody try that? Could you please share your experience/links here ? I saw one repo in GitHub, but it's more than 5 years old. It would be nice to have a modern way of doing that.




last year i tried clojurescript but i am kinda failed to get it then gave up. then i started to use elixir on server side. after having experience of a functional language now clojurescript looks amazing and very fun. it's interesting such a beautiful language is not popular

👌 16

Yeah, interesting how you didn't like it and then you did, right? If only we could capture that transition in a bottle... We could sell it and make millions 😉

Daniel Hines16:04:12

No joke, some of that transition is called shadow-cljs. It’s not exactly in a bottle, more like a JAR.

Lennart Buit17:04:00

Bottle or jar, one is for fluids the other for cookies… I don’t see much difference ;)


but where do I store my liquified cookies?

Lennart Buit17:04:23

Oh no, the feared diamond ♦️


I actually still believe tooling could make a big difference


If I give some Clojure app over to a team. There's a good chance they'd try to maintain it without ever bothering getting learning and using Cider.


Eventually, they'd think the language is crap, and decide to rewrite it.


handing anything based on cider off to someone is bound to be the most frustrating experience ever


In my shop, we each use different IDEs


when I started writing clojure I would run java -jar clojure.jar in a terminal and copy and paste code form my editor in to the repl, then I started using swank-clojure and emacs, and then nrepl and the elisp code that eventually became cider. using cider is such a pain that I have gone back to just running a bare clojure repl and copy and pasting forms in to it

😮 4

running the clojure repl and copy and pasting code in to it never breaks, and works anywhere, it is a wonderful experience


aye, me too


I forked swank-clojure for a bit, participated in discussions about the nrepl protocol on the mailing list before it was released, fiddled with writing my own repl client for emacs, etc


Just running a standalone repl is very productive and you can manage an app cradle to grave just fine that way.


And it's solid and simple


i can't imagine working without an editor that's wired up


I hate cider so much, and it is so finicky I would be way to embarrassed to suggest anyone use it


I think the editor integration can be pretty awesome, as long as it never breaks


and I exclusively use emacs for writing clojure (although I have been fiddling with ed a little recently)


Also, I dislike when a pile of code is structured such that it works better in one IDE and not another


my point is just the experience with cider is varied to say the least, so the suggesting that cider is going to be the missing bit that causes some team to throw up their hands and rewrite clojure code in another language is silly.


> If I give some Clojure app over to a team. There's a good chance they'd try to maintain it without ever bothering getting learning and using Cider. True. But normally the typical experience of learning Cider (or swank if you're old enough), done at home as your personal project can hardly be extrapolated to the workplace. People have deadlines and generally lack a silent environment where they can learn things properly. IMO there's still place for a nicer Emacs distribution, with intuitive keyboard shortcuts, conventions etc. Releasing such a project is a huge responsibility though, with many prior failed attempts.


Another reason why Clojure doesn't take off for some folks on first try: Clojure is a hosted language that requires some amount of knowledge about the host. So there's a double wammy there, regarding the learning curve.


It's hard to offer it as a beginners language or learning tool, when it doesn't come with a standard lib of it's own

eccentric J18:04:00

How do you and @U8QTB156K feel about recommending a language like Racket as a first language for beginners? In my opinion it has a lot in common with Clojure. It is a full, self-hosted language you can do console prompts -> interactive games with graphics, and even comes with a robust editor\IDE\repl you can further customize with Racket. A lot of learning material is also designed for people learning Racket as their first language too.

Daniel Hines18:04:46

I have no experience with Racket. I did find that has an online Scheme editor that makes it a cake-walk to start going through SICP. But if Racket comes with a nice IDE, that sounds awesome.

eccentric J18:04:21

For a book like SICP I can imagine working well, but in the case of something like Clojure I feel hesitant to guide someone towards a resource like that because only a certain number of learning resources will work\apply in a tool like For instance, I don’t think you are able to follow Clojure for the Brave and True in to completion and it may not be clear whether it’s an error on your part or due to a lack of support for a feature.

Daniel Hines18:04:30

Oh, for sure. But one thing I enjoy about SICP is it starts with nearly nothing, and builds everything up with just the bare LISP primitives.


For someone on my team, I feel confident in our ability to train anyone up on Clojure in just Clojure. But left to their own devices, I think what works may vary too much from person to person - I don't have a confident answer for beginners without java/js experience. I def' think CISP is one route to success, in which case starting with Racket may make sense.


In the interest of time, though, for my own team, we hit the ground running with Clojure ASAP and don't look back.

eccentric J18:04:16

But they’re typically experienced in other languages?


At a college level

eccentric J19:04:44

In that case hitting the ground running with Clojure makes a lot of sense to me. Especially when you’re hiring people. I’m specifically interested in Racket as a solution for people who have not had prior programming education but have expressed interest in learning on their own time.

eccentric J19:04:16

In that scenario, I’m curious if learning the differences between Java versions, Clojure as a hosted language, the difference between Clojure and ClojureScript, an editor, and a REPL integration may be a bit to take on?


Yeah, I'm so far removed from that place that I assume my Clojure bias is blinding me to the difficulty of it, from a beginners perspective. Clojure just seems like the simplest language to me, at this point. So I moreorless take it on faith that something like Racket/CISP is better for a beginner.

eccentric J19:04:26

Fair point. Every time this subject comes up I’ve been asking about Racket. I want to know if A.) It’s a better option for beginners than say a or OR B.) It’s a worse option than Clojure starting out. OR C.) It’s a different-but-equal option to Clojure learning solutions.


It might be interesting to see a kind of standard lib implemented over the jvm, clr and js implementations

👍 4
Daniel Hines18:04:28

Yeah, I try to introduce friends who have no programming experience to Clojure, and I quickly have to do a lot of hand-waving around the host language. But I think the classic argument is “Clojure lets you use all the power intrinsic to the host”. I don’t think it’s meant to be a from-scratch-beginner language, and as a result, it isn’t.

Daniel Hines18:04:37

I’ve switched to introducing people to Scheme instead.


I used Elixir as a stepping stone to learn functional/immutable, then Clojure just added the Lisp element. Doing it as a single step would have been too much!

Ivan Koz18:04:52

John i totally agree, can't imagine how it would be for me if i didn't knew Java. But after 2 years of java and 6 months of common lisp, Clojure was a joy to learn


I'm not pointing to Cider as the epitome of tooling. But the interactive REPL driven workflow, in Clojure, is not a good to have.


The REPL workflow is what makes up for the lack of static types and compiler checks.

Ivan Koz18:04:11

that's exactly what we are going away from

Ivan Koz18:04:41

there is ML family and if you want static types


As well as the idiosyncratic syntax. Without proper indenting and coloring and manipulation of s-expr, the syntax is definitly harder for your eyes to follow and easier for typos to be introduced as well. Compared to say Pythons syntax.

Ivan Koz18:04:09

about typos i would agree, but there is structural editing have you tried parinfer + paredit combo?


Ya, sorry, let me clarify.


I'm saying more that, to Clojure, good tooling is even more important to the experience and integral to understanding what's so great about it. As opposed to some other languages.

Ivan Koz18:04:41

yeah true, for any lisp


I speak from experience. I've seen many devs try Clojure and then disregard it in favor of something else. Generally, the devs that did that are those who never went beyond basic tooling. They'd use a command line repl, with no support for multi-line, and a simple editor with maybe only syntax highlighting, nothing more.

Ivan Koz18:04:37

Lisps require more serious approach to them.

Ivan Koz18:04:22

First thing when i discovered common lisp i dived into hyperspec for weeks


That's why I think there's ton of opportunity in improving tooling in Clojure.


Like, Simple made easy. Sure, Clojure is simple, not necessarily easy. But for tooling, you definitly want it to be easy. And I don't think Clojure tooling is easy right now. And that hurts a lot with getting more people to try and like Clojure.

Phil Hunt18:04:18

What's the situation with CI pipeline tooling, containerisation etc and Clojure? I'm still learning the basics, but I imagine support for that kind of stuff is going to be just as important when you're trying to do real stuff with it.

Phil Hunt18:04:37

.. as it would be in a Java or Nodejs shop

Ivan Koz18:04:33

jvm and javascript as platforms makes it even harder to nail tooling right


Re: tooling, I think it's possible to have a very productive workflow with a REPL with minimal tooling -- but it's important to lead with REPL-Driven Development whenever you introduce new devs to Clojure and, by that, I mean integrated into whatever editor the new dev already uses.


Eric Normand's latest newsletter talks about this today actually... use the simplest tooling that you are productive with.

Ivan Koz18:04:57

half of my workflow is rich comments and send to repl command 😃


For me, that's a Socket REPL (or plain text REPL) and eval forms from the editor directly -- yeah, Rich Comment Forms and never typing into the REPL directly.


Well, what happens is that. Everything you need is there. And anyone experienced enough can figure it out and do it. That's even true of say, getting Cider to work reliably. Or creating custom tasks for everything. I can do that and do it. But it's definitly not beginner friendly.

Ivan Koz18:04:26

i demanding on a good static analysis and symbols highlighting tho, that's why i'm staying away from cider atm, altho evil emacs is my main editor for other stuff except java and clojure cider cant even resolve functions and macros properly, not speaking of project wide refactorings


It's hard, you want to tell someone to get started. Oh, but first, install clj, install lein, install an editor, install the Clojure plugin, learn how to start the repl, connect to it, etc.


I'm with @hiredman on not being a fan of CIDER/nREPL... When I first started down that path, my workflow repeatedly broke whenever there was a version update, and I hated having to have dev-specific dependencies in my app in order to run a REPL server in QA/production that my editor could connect to 😞


Yup. Unrepl is the future for me. Maybe pRepl when it gets out of alpha.


Good news is, they're working on getting unrepl to support nrepl

Lennart Buit18:04:52

I recently started in-ns’ing to do some non structural calling of functions in the ns I am working on. I am not a big fan of littering my code with comment blocks but your opinions may vary!

Lennart Buit18:04:05

opinions of a … starting clojure developer, so to say


So you can have nrepl over a socket repl without needing any hard dependencies.


In 2010, I started learning Clojure with TextMate and a clunky REPL integration. At some point I went back to Emacs (after a 20 year break), but I tried pretty much everything along the way -- Eclipse with CCW, IntelliJ with Cursive, LightTable, Sublime Text, Atom...


I switched from Emacs to Atom/ProtoREPL just after seeing Jason Gilman demo it (at Conj? or West?), then switched to Atom/Chlorine recently and I'm really enjoying that (since it's written in ClojureScript and I can edit the source while I'm working).


Well. Emacs is definitly not for the faint of hearts. But inf-clojure gives a more minimal experience closer to protoRepl. And Spiral, which connects over a socket Repl, gives a very similar experience to Chlorine.


That said, while I like their simplicity and how they work more reliably. I always miss the more advanced features of emacs.


Like being able to goto files that are across projects.


Format using cljfmt.


Run tests with the pretty test output


Refresh whole apps. And run refactors


Or even something as simple as pulling the grimoire docs for a symbol


We could build an IDE in browser and connect to it using a browser extension, with native messaging: Then you could drive clj repl from a browser IDE

Ivan Koz18:04:31

atom is pretty much browser isnt it?


yeah, on electron... I just think a lighter weight thing would be interesting


I also think, we need to improve the static support in editors. A lot of things rely too much on a REPL properly loaded and in a compilable state.


Or the support for uncompilable code.

Ivan Koz18:04:14

exactly, state of the art static analysis engine is absolutely important for clojure ecosystem


Cursive does a good job at it. But then it has terrible support for the repl


I’m curious about this. What about Cursive’s REPL support is terrible?


Not trying to call you out BTW, but when I see comments like this they’re not usually very actionable.


Hum. Ya, I should probably refrain, it was from my experience a while back. I think it's more that intellij has bad support for repl.


The only one I can remember is not being able to change the font size in it


Also terrible was a too strong a word. More like, I remember it not being as good as I had hoped.


You can definitely change the font size in the REPL.


Ya, I feel like I've expressed an unfair opinion to Cursive. Which I actually recommend to everyone who isn't into Emacs, as I believe it's the best Clojure editor outside Emacs. I'd need to give it another attempt myself to be able to have real constructive criticism again. I'll try and be less hyperbolic next time if I'm renting about Clojure tooling. Appreciate your hard work fully, you bring something very valuable to the community.


No problem, and thanks - I appreciate it.


We need something that excels at both

Ivan Koz18:04:48

yeah its pretty much the only thing that holds me on cursive atm

Ivan Koz18:04:21

i like to jump to java\clojure source files, look for keyword usage across project and dependencies

Ivan Koz18:04:15

but it looks like such big ide is too much for one person, a lot of imperfections and lack of functionality


Ya, all goto like features should work without a repl. And even when the code is unparsable


Same for getting the doc, looking up the source


Auto-complete should as well, to some extent


My repl should be for eval.

Ivan Koz18:04:47

what kind of lisp ide it is if it cant resolve symbol to highlight it properly

Ivan Koz18:04:03

like in case of function calls


I think implementing a LSP backend for Clojure could be good.


That would give static support to a lot of existing IDEs


But because the REPL can so easily be used for reflective analysis, I think most Clojure effort went with that. And so, we got very little in terms of static editor based parsing and ast management.


Which works great once you know what you're doing. But poorly for beginners

Ivan Koz18:04:03

yeah static stuff, linting, highlighting, formatting and refactorings should be totally independent from repl, just source files


I'd say ease of use.


Doesn't nrepl/unrepl allow us to abstract some of those analysis bits into middleware that can potentially be IDE agnostic? And doesn't that require a repl connection?


Unrepl isn't doing static analysis.

Ivan Koz18:04:43

i dont think thats should be complected with the repl functionlity


Granted, sometimes you want a fast linter that runs from the CLI


You could maybe manage a nRepl as a backend for static analysis. Using it to keep track of the file ast, and constantly reloading as you type. Which would be a different repl from the one you use for evaluating things in your live app


But I've not seen any editor do this


yeah, prepl may make that easier in the future, for structured messages going back and forth


The issue is, Repls don't tolerate unparsable code fragments. Because they rely on the compiler to parse.



Ivan Koz18:04:50

isnt it will be better to have separate client - server engine where repls and editors are clients


You want feedback on forms that aren't necessarily complete


Or at least, it should degrade gracefully


Like ignore that particular form


Not prevent the parsing of everything else to succeed


hmm. That could probably be implemented repl side... But yeah, would require a lot more thought.


I dunno that I have ever wanted to load invalid code


A small example is:

(defn add [num-one num-two]
  (+ num-<this should auto complete>
Even though the form is incomplete


And I should be able to goto +

Ivan Koz18:04:38

so it must be somewhat "virtually balanced" perens


well, paredit doesn't even let me enter that form

Ivan Koz18:04:05

that true, but why dont we autocomplete symbols and parentheses together in one go


Yes, when all the stars are aligned. And you know the right combination of tooling and how their quirks work, it's no longer an issue.


But it's not easy or friendly to beginner


How many people asked, why it doesn't autocomplete and the answer is. Learn and install even more things


I dunno, I don't think it is a high bar to say clojure is a regularly structured language and should be editing structurally and not as free text


Ok and how many editor support it well?


paredit is also a million times more reliable then cider, it just works, I have no problems with it


I dunno, I mean, you were the guy suggesting people would abandon a clojure project if they didn't use cider (the emacs nrepl client)


maybe you meant nrepl and not cider?


But paredit also requires to spend a minimum of one full day learning. And you haven't even started learning Clojure yet


all true, and I barely know paredit


Well, I used Cider as an example REPL based editor


I think I only slurp and barf and maybe raise


When you use paredit, you always use it in strict mode?


I don't even know that there are modes


You've never ever ended needing to paste something and rebalance it, or delete something without using the structural edits?


I just say "emacs turn on paredit" and haven been saying that the same way for years and it continues to work


I know how to turn paredit off


which I do sometimes to manually fix things


I can't remember if default paredit is strict. Does backspace skip over parens?


it stops at the paren (at least for whatever version of paredit I have)


well, it depends, it stops at the paren if the list isn't empty, but if the list is empty it deletes the list


Anyways, I'm not saying that there is missing tooling. Like everything you want can be done or solved. Just that it's not very friendly, has a steep learning curve and isn't super reliable. And sometimes the UX isn't great


Ya, that's strict mode then


like, is it better to have deeper tool support with more static analysis, or is it better for the structural editing support that already exists to become more widespread?


We should have a code-off where a series of videos show the same editing sequence, but implemented in various IDE workflows, to see which is fastest / most efficient.


Its strict in that, it rebinds the bindings that could cause unbalanced parens. Like backspace.


there was a time when I edited clojure code in notepad++ and vim and manually balanced parenthesis, and it hurts now when ever I have to do that in an irregular language


"irregular languages" shudder


Ya. And I agree as well. I'm more productive with the Clojure toolings then any other language. But that took effort, dedication, fiddling, practice. Etc.


I just think we could really improve that ramp up time.


It would help a lot with first impressions, and beginners trying to learn.


I've gotten pretty quick with atom/parinfer. I'm pretty sure I'm just about as fast as a cider/paredit setup, but with out any of the slurp/barf/etc commands. It's pretty efficient with minimal learning curve IMO


I use parinfer primarily (in Atom). I also have paredit installed so I can slurp/barf/raise/expand selection. And then I have just a handful of REPL-related commands (load file, eval top-level form, eval current form). I do have run-test-at-cursor and run-all-tests-in-namespace bound to hot keys too. But very little else.


I went from CounterClockWise eclipse to atom/pareinfer/proto to cursive to emacs


And I run REBL, all-day, every day (so my "eval" is really "eval-into-REBL").


I'm most productive in emacs now. Though it took some learning


I have a lot of my own custom modifications to emacs


I even do java in Emacs now


Ya, i wish I could try rebel


Yeah, I've gone down the emacs road a few times and stuck with it for a while a few times... You know, we complain about how IDEs are hard for newbies, but most "seasoned Clojure devs" have taken the time to learn a half dozen of them. Maybe a corollary piece of advice might be to "just go learn them all"


Anyways, I haven't found something that really works for beginners to get started quickly. I'm wanting to setup a beginner series at my work. And can't decide what tooling to show


I'm considering Emacs with a custom init that makes it beginner friendly and puts all the notepad bindings back in


And inf-clojure or spiral


Again, my recommendation is: use whatever editor/IDE they already use -- if possible.


Learning a language and learning a new editor/IDE at the same time is usually not a good idea.

💯 4

It's one of the things I don't like about Brave & True -- it introduces Emacs up front. If you're not an Emacs user -- and you're just getting started out as a programmer -- learning Emacs is a huge barrier to entry.

Lennart Buit19:04:17

I must admit, I skipped that chapter & I recommend everyone who is reading it to do the same


I didn't and tried to get it working.. then I found out about Cursive luckely.


Hum. I guess. But at my work, it will be Eclipse. And CCW no longer works.


And I'm not a fan of introducing a paid plugin if I go Cursive + IntelliJ. Since this is a work series, I'm assuming paid licenses are in order.


Will people actually be working with Cursive, or just studying Clojure? If they’re not using it for actual work, a non-commercial (free) licence is fine for that.


There is a potential they transfer to work. In which case I'd let them know a license is in order. Otherwise it's more of a "learn clojure" for other teams at my comp if anyone is interested. But I would be showing work related examples. But nothing that would actually make it to production.


That’s fine with me. They’d need commercial licences once they transition to actual work, but for any learning a non-commercial one is ok.


Good to know. So I might offer that as an option when I give the series. I know some people already use IntelliJ. And on my own team, we have a few licenses already for Cursive which some people use.


Which is a lot to ask at first.

Lennart Buit21:04:29

Cursive is imo worth every penny

Alex Miller (Clojure team)21:04:56

seems like a pittance for a tool you use 40 hrs a week


And then Electron doesn't run on the old version of Linux we develop on :man-gesturing-ok:


Well, they get it expensed. But people have to be sold on it first. Like managers don't totally understand why they have too.


So it's a chicken and egg.


First the team needs to build something in Clojure that goes to prod. Then they can say, we need the license to help us with this production product

Lennart Buit21:04:44

Good tooling makes for productive engineers ^^!


In a Java shop, otherwise, you just get asked why you're not using Java or Kotlin or Scala which all have great free tooling.


I can't even say this is true of all managers. But I know the devs feel bad even asking. And I feel bad showing them Clojure in a way that would force them to ask about it very early on.

Alex Miller (Clojure team)21:04:14

given how much we pay programmers, the idea that there should be more than 5 seconds of thought to allow them to buy a tool that is like on the order of magnitude of an hour of work, to let them do their job, even if they only use it for a day, is completely bananas

🎯 12
❤️ 4
Alex Miller (Clojure team)21:04:10

software is made by people. as programmers, we should probably know this. I believe in paying programmers to buy software, especially if it allows me to do my own job.


Yup, I think so too 😋 but I don't make the rules. Also, I've found the bigger the company, the less willing to accommodate things like that they are.

Alex Miller (Clojure team)21:04:52

instead we want everyone to work on open source for free and avoid paying anyone anything for quality work

Alex Miller (Clojure team)21:04:32

sorry, my own hobby horse :)


I think I'm paying for a cursive license personally, and one through work, and I don't even use it ATM. I just like to support the work. But there's free IDEs that are very sufficient to get work done in imo


Thanks! I appreciate it 🙂


I personally support a few open source projects financially. Things that make my life easier and my job more pleasant, I'm willing to pay for. I actually love Cursives personal license model for that.


Y'all noticed the slack Android client missing messages?


But then. How do you know?


I can see the difference from the desktop


Then I guess. I wouldn't know


Since you can get it yourself even if your employers doesn't want to pay. And then just take it with you

Lennart Buit21:04:36

There is no such thing as free software, someone is paying the price

Lennart Buit21:04:25

And I am glad that people do find ways to monetize FOSS

Lennart Buit21:04:54

Because we all depend on it’s existence


I use REBL day-in, day-out and it's worth every penny of the per-month Patreon fee I pay Cognitect! 🙂

Alex Miller (Clojure team)21:04:52

New fun stuff in rebl coming soon!

sheepy 4

Not soon enough 🙂


Don't tell me... Quantum entangled atoms, so we can share objects over the prepl like they're local?!!


Hey, I can dream!


Btw, now that Clojure went Java 8 minimum, any plan to support Stream interop? Like have Clojure Fns implement java.util.Function ?


Hum, and I guess it's a bit trickier, since there's BiFunction and the like as well


Sweet! Hope it makes it in 1.11

eccentric J23:04:18

Have you found yourselves writing more docs than code in your Clojure code regularly?


I find docstrings quite essential but if they're bigger than the impl, maybe some specing/testing/refactoring ought to be done


I think that depends on the code. For example has a very long, detailed docstring so that folks don't need to leave the REPL or their editor in order to look up documentation about how to call that function (i.e., the various database types).


I took a look at the get-datasource doc. Under my current patterns most of that docstring wouldn't exist, as the options, their types and meanings would be defined as individual specs. Sadly one cannot attach docstrings to specs today. I do get around it though in a custom manner


A spec wouldn't really help here since the docstring just lists the databases that next.jdbc knows about out of the box -- but you can pass any string as :dbtype and pass :classname as the hint for which driver to use.


But I probably could move some of that information to to make the docstring shorter...


(but then you can't get to that information easily from your REPL so...)


I guess a spec would partially help: (spec/or :known #{"derby" "h2"} :custom string?) maybe it doesn't enforce much, but serves as doc. > (but then you can't get to that information easily from your REPL so...) I'd expect library consumers to use "jump to definition" so they can read both the docstrings and the specs. Might be overly assuming but... 🙂


There are several places in next.jdbc where the docstring is longer than the implementation. And it also has some very long ns docstrings too, such as which gives an overview of the main API.


(but then I spent nearly all weekend writing documentation so maybe I'm biased? 🙂 )


Respected! One practical issue though is that long var (or ns) docstrings tend to 'break' the editor's UI or at least produce a humongous tooltip (in Emacs I use either tooltips or the echo area). Past ~5 lines it can be hard to comprehend those tooltips at all. I know one can just (doc x) in the repl which will be more readable than in a tooltip, but that's pretty manual. If there's something really that long to explain I'd consider linking to it from the docstring (quite a subjective matter of course)


(I have it planned to make my Emacs auto-detect long docstrings and present them in a dedicated fullscreen frame... one day ^^)