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

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 😉

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

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?

lol

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

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

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

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.

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!

Hi

<- new

Hi Phil

hi hi

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.

hows that?

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

that's exactly what we are going away from

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.

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.

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.

Lisps require more serious approach to them.

Yup

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.

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.

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

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.

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.

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

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!

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: https://developer.chrome.com/extensions/nativeMessaging Then you could drive clj repl from a browser IDE

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.

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

We need something that excels at both

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

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

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.

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

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

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

Why?

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.

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.

right....

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

Yes

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>

And I should be able to goto +

so it must be somewhat "virtually balanced" perens

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

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

the worst

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.

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.

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.

Earth Day! https://youtu.be/tOUbZJbkHNw

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.

Which is a lot to ask at first.

Cursive is imo worth every penny

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

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.

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

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.

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

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

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?

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

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

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

New fun stuff in rebl coming soon!

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

https://dev.clojure.org/jira/browse/CLJ-2365

Sweet! Hope it makes it in 1.11

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 https://cljdoc.org/d/seancorfield/next.jdbc/1.0.0-alpha8/api/next.jdbc#get-datasource 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).

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 https://cljdoc.org/d/seancorfield/next.jdbc/1.0.0-alpha8/api/next.jdbc 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)