return to table of content

Try Clojure

jakebasile
54 replies
22h54m

I'm glad this is back. A version of this existed in the ancient past and helped encourage me to try Clojure which ended up being by far the most impactful decision in my professional life. It went away for a while for reasons I'm unclear on.

I use Clojure nearly daily at my job and at home. Sometimes it's standard Clojure, sometimes it's the excellent Babashka flavor which I use as a make-like task runner and Zsh-like script replacement. It's not the only language I use of course, and Go is a strong second place most of the time especially if I need something compiled to a single binary. But Clojure is where I generally feel most at home thanks to the irreplaceable REPL based development flow which is more like a dialogue with my program than your typical write compile run loop.

Combine that with it running on the JVM and you have a wonderful set of tools to get things done in a pleasant way.

I strongly encourage anyone with even a passing interest in Lisp and functional programming to give it a try. If you're using VSCode there is the excellent Calva plugin to help you out.

nine_k
47 replies
22h39m

As a side note, I'm always amazed by people who can use a highly expressive language (Clojure, Rust, even TS) but switch to Go when they feel like it (especially pre-1.18).

To me, switching to a less expressive language is painful and infuriating. I remember having to switch from Python to Java 5, and how everything started to take 3 to 5 times longer code to express.

Maybe the key thing is to only write small things in less expressive languages, like shell scripts, or small C functions to help performance or FFI, or, well, tiny Go utilities.

kubb
19 replies
22h23m

Development in Go will always be more painful for some people than in Clojure or TS, because the language is intentionally hostile to abstraction, so you're thinking in higher level concepts, but you implement them in more steps than necessary. The program can never reflect the shape of the problem, because it will be riddled with "glue code" that implements the obvious dull steps that you abstract away when reasoning.

There's a population of people that don't like this kind of abstraction, because to understand the code you first need to understand the problem, the data flow and how it's expressed. They prefer to look at the issue "bottom up" than "top down", and for them Go is perfect, because instead of reasoning about what the module does, how the data flows, what the algorithm does, they can focus on the small: this is a loop that iterates through a slice, this is an if condition that depends on this variable.

There's no better or worse here, just two types of people. Some like to look at the whole bridge, some like to examine the individual nuts and bolts and joints.

ReleaseCandidat
6 replies
22h18m

There's no better or worse here, just two types of people.

No, two types of solving a problem. I like writing both (Haskell and Go) - for _myself_ - but the tooling and standard library and ... of Go is orders of magnitudes better.

kubb
3 replies
22h9m

I would refrain from comparing Haskell - a research language intended for academia and created in universities, to Go - a pragmatic industry language intended for production and created in a megacorp. Why would Haskell's tooling be better? It's not reasonable to expect that.

ReleaseCandidat
2 replies
21h55m

I'm actually surprised Go's tooling as as good as it is _although_ it is made by Google. But to be fair, GoogleTest is OK too.

nine_k
1 replies
21h44m

Google has produced a number of quite good tools. See also Bazel, for instance.

During my time there, I was genuinely impressed by the quality of many of the internal tools. E.g. it took GitHub code review tools a long time to get on par with Google's internal code review tools from 2015.

ReleaseCandidat
0 replies
10h17m

Google has produced a number of quite good tools.

"Quite good" is exactly the wording that I would have used too. But Go's tooling is _really_ good; the language itself is, well, "quite good". And is still supported and actively developed!

kaba0
1 replies
8h20m

Well, you are comparing the tooling of haskell and go. Of course in this comparison the difference will be stark, but there are plenty of languages that are sanely expressive, unlike go, and has decent tooling around it, like java, c#, perhaps scala if you want even more expressivity.

ReleaseCandidat
0 replies
7h52m

and has decent tooling around it, like java, c#, perhaps scala

All of these are perfectly mediocre and usable languages (in which I would write in if somebody pays me), but surprisingly even for myself I ended up really liking Go.

vaylian
5 replies
12h54m

The program can never reflect the shape of the problem, because it will be riddled with "glue code" that implements the obvious dull steps that you abstract away when reasoning.

How does this affect readability when one tries to dive into an existing Go project? Is Go code harder to navigate than code in more expressive languages?

nXqd
2 replies
9h52m

We shouldn't overestimtae the complexity of expressive language like Clojrue vs Go. Go is perfectly simple and easy to follow, even compared with Clojure. If you come from background of Computer Science or programming first, Go is easier to follow.

kaba0
1 replies
8h16m

I always feel this comparison is a fallacy. Assembly is also perfectly simple and easy to follow, like each instruction is trivial. Yet you will fail to grasp the whole, as “you are zoomed in too close”. I feel go has a good scale for many kind of tasks, but at the same time, it lacks the expressivity to change the zoom level, which I feel is needlessly limiting and makes the language a bad language for problems that require a slightly higher level of abstraction.

alabhyajindal
0 replies
3h18m

I tried Go for a while after coming from JavaScript and didn't feel productive enough. I think this explains why exactly.

kubb
0 replies
7h37m

This would depend on the size of the project, and the difficulty of the solved problem.

With a simple problem, and a small codebase, Go is easier, because you need to know less language constructs.

With a complex problem, and a large codebase, a more expressive language is easier if used properly, because it can highlight what's important in the solution. The ratio of signal to noise when reading code is higher.

ReleaseCandidat
0 replies
9h35m

Go really is the most "readable" code for anybody who has ever read something C (or Algol ;) like - so just about anybody. The only "strange" stuff is its `iota`, the method syntax and of course channels and goroutines. But that's nowhere comparable to some C++ or Haskell, "type heavy" Typescript or some Lisp macro DSL.

chuckadams
3 replies
22h8m

While I share your perspective on go, I do prefer developing in a bottom-up way myself: I just do so with the intent of iterating my way to a higher level abstraction. Sometimes I see the abstraction right away and start with it, but I don’t want a language that gets in my way in either direction.

nine_k
1 replies
20h49m

A Lisp (like Clojure), or Haskell are great for playing around with things and developing bottom-up. I did just that for a day job sometimes. Of course, I then had to translate that to Python or TS, but once an idea is understood and tried, it's not such a big deal.

ReleaseCandidat
0 replies
9h48m

That's interesting, for me Lisps, Python or TS (or Go) are great for playing around with things and developing bottom-up. And then I translate that to Haskell (or Rust or C++ or Go).

kubb
0 replies
22h4m

The thing is, in Go you can develop bottom-up, but you can't always end up with a an appropriate abstraction, because of the lack of tools to achieve that.

nXqd
0 replies
11h41m

I do switch between Clojure and Rust depends on the problems I solve at hands ( prototypes vs building production ). And yes I need go through my checklist of each to switch from connecting data flows at high level to examine nuts and bolts at low level.

kazinator
0 replies
19h49m

they can focus on the small: this is a loop that iterates through a slice, this is an if condition that depends on this variable.

Then a week later, the squinty mole discovers the code is dead; not called at all. There is no slice and no variable.

cess11
11 replies
22h13m

Java has had lambdas, map/filter/reduce and other stuff for like ten years or so I think. It's a bit chatty for sure, but that's what you want sometimes, the verbosity can make it easier for newcomers to make changes and additions.

To me it isn't more infuriating than learning a new language or practicing one I'm not very good at. There's a bit of friction, but that's common when I'm developing in the languages I'm most fluent in too. Either that or the problem is trivial and likely to be in most common programming languages.

ErikCorry
7 replies
10h16m

These Java features are ruined by not allowing mutable variables to be captured. Having to do the 1-element array trick when the compiler could just do it for me is insane.

If you are making JavaScript look good you are failing as a language.

kaba0
4 replies
8h12m

You mean not having the error that go just fixed by changing the language is a problem?

ErikCorry
3 replies
7h25m

JS has this error too, but nothing forces Java to have this issue if they fix the no-mutable-captures problem. Dart got this right from the start.

Here's JS showing the same issue.

  for (var i = 0; i < 10; i++) {
    array.push(() => i)
  }
  array.forEach((fn) => console.log(fn()))  // Prints 10 every time.
The correct fix is that each loop iteration gets a fresh i instead of i just being mutated. Currently you can't see the difference in Java between there-is-only-one-i and there-is-a-fresh-i-every-time, so Java is free to do this right.

cess11
2 replies
6h14m

Here's what I'd do:

   array = [];

   function clos(val) { return () => val; }

   for (var i = 0; i < 10; i++) { array.push(clos(i)); }

   array.forEach(fn => console.log(fn()));
This outputs 0-9 instead of 10, though I'm just a silly self-taught person that never got schooled at these things, maybe there is some reason not to use closures that I don't know about.

ifwinterco
1 replies
4h58m

These days in JS you can just use let instead of var and it will work, but in itself that inconsistency is a bit weird

cess11
0 replies
3h13m

Yeah, let/const is what I tend to use. Here I wanted to change someone else's code as little as possible.

Edit: Oh, right, it also solves the 10-issue. Thanks, didn't realise at first.

cess11
1 replies
8h50m

Typically I can use a forEach in such cases, and when I can't it's probably an incrementer and the IDE just switches out my int as an automatic solution to its complaint.

I think its OK to be reminded that the context is mainly immutable when chaining on a stream.

Method polymorphism to achieve default parameter values is a much worse nuisance, but not particularly hard to get used to when one decides to focus on the problem rather than the inevitable warts of a broadly useful programming language.

Edit: Also a pretty weird complaint in a thread about a programming language where pretty much all the basic data structures are immutable. Maybe take it to the top and make the quip about worse than JavaScript with regards to Clojure?

ErikCorry
0 replies
2h50m

Doesn't the forEach method on arrayList have the exact same issue?

nine_k
0 replies
21h36m

Java 7 is already pretty pleasant, and it has been improving ever since then.

(Say what you want about Oracle Corporation, but as the wardens of Java they're doing a pretty good job.)

kaba0
0 replies
8h13m

The funny thing is, go is significantly more verbose than even decade-old java.

fiddlerwoaroof
0 replies
13h49m

I’ve been writing a lot of Java 11 recently, and I find it to just be a very pleasant environment to work in: the IDEs still are best in class, afaict; the newer APIs avoid a lot of the boilerplate I used to have to write out and there are generally mature libraries to interact with just about any system you might need. Where Clojure really shines is that it’s a really well thought-out layer that can leverage this ecosystem and adds its own well-designed tools on top for my preferred more-interactive development style.

a_wild_dandan
2 replies
22h21m

I must use PyTorch for ML, but badly wish I could use TypeScript instead. Its type system demolishes anything else I've used. Writing anything from SPI communications, to server logic, to rich GUIs is a breeze. Then I work in Python and have to fight `Any`s, ambiguous arguments, more verbose code, and bizarrely slow run times. It makes me sad.

nine_k
1 replies
21h38m

While I agree with you, Python is getting better in this regard, as is mypy.

Making historical interfaces well-typed is another kettle of fish. For instance, Python's range() is actually two overrides with incompatible signatures. I bet PyTorch has more of such examples.

pjmlp
0 replies
11h48m

If it only had a V8 class JIT in the package as well.

ReleaseCandidat
2 replies
22h25m

I write less boilerplate in Go than in Rust, about as much in Go (but of course different ;) as in Haskell).

nine_k
1 replies
20h46m

That's cool! How do you manage? E.g. the `if err != nil { return err; }` stuff?

ReleaseCandidat
0 replies
9h52m

Well, in the context of Lisp, `err != nil` is equivalent to Lisp's parens: if somebody complains about that, chances are their critique is superficial (and there are enough "real" problems when using Go, especially when using goroutines and channels). The amount of low abstraction Go code I write is compensated by the amount of "abstraction boilerplate" like implementing type classes by myself or letting the compiler derive, implementing newtypes, adding GADTs, adding Pattern Synonyms and Type Families to be able to comfortably use the GADTs without much boilerplate and so on. Rust adds for example the need for associated types and is generally more verbose than Haskell.

I do not see a significant difference in the amount of boilerplate needed for catching exceptions, pattern matching or branching on the existence of an error value. Nobody can stop you from implementing `bind` in Go for your error (which I did in some places), but of course Rust "wins" with its `?`.

harrison_clarke
1 replies
20h39m

i find i flip between different languages when i'm thinking about the problem in a different way

an expressive language (clojure, python, C#, etc.) is good when you're iterating "what problem am i even trying to solve?"

a less expressive language is typically better when you more or less know a high level solution to your business problem, and you're iterating on "how do i make the machine actually do it". like "how do i reduce my AWS bill" or "how do i render it in 16ms?"

for something like gamedev, enough of the problem is in the second category that you might not even reach for the expressive language. (many do, though. with lua, or artisanal lisp dialects)

voidUpdate
0 replies
8h59m

If you're counting C# as an expressive language then a lot of gamedevs will reach for one, judging by the market share of unity, me included :P

fire_lake
1 replies
12h7m

Python is the new Java 5 here. The lack of multiline lambdas is incredibly awkward, leading to code that bounces you around the file.

gpderetta
0 replies
8h50m

Lack of multiline lambdas is infuriating, but nested named functions partially make up for it.

pjmlp
0 replies
21h40m

We get used to being yet another work related chore.

jakebasile
0 replies
22h11m

I won't tell you there aren't stumbling blocks and impedence mismatches but most of them are relatively minor syntactical things. The faux-AST in my head gets typed out in the wrong format and I have to backspace and correct it (think function declaration differences). The biggest workflow difference is undoubtedly the lack of a REPL in Go, but that is somewhat made up for by Go's lightning fast compilation and testing tooling (probably its second strongest attribute after the excellent standard library). After a day or two of writing in one or the other my neurons seem to get used to it only to cause the same problem in reverse when I switch back. Overall, it's not too bad and a case of just accepting the tools available for what they are. I don't try to force Go to be Clojure or Clojure to be Go.

gpderetta
0 replies
8h51m

As a C++ programmer, I definitely like my languages with extra legs nailed on.

But sometimes limitations can spur creativity.

dgb23
0 replies
7h20m

Expressiveness has many dimensions. It depends on what you are trying to express in the first place.

C++ or Rust are expressive in both directions, towards the metal and upwards in terms of abstractions. But those languages are not easy to reason about. They come with lots of stuff, hard to grok abstractions, ceremony and so on.

Small languages like Scheme or Lua are expressive in that they don't force you to write a lot of stuff to get the job done. But those languages don't typically let you express what the computer should actually do at a lower level.

C or Zigs let you do those things and are also relatively small languages. But their facilities for abstraction are limited and they force you to express more computational details.

Go frees memory and schedules goroutines for you, but lets you express a lot more about how you lay out memory than other managed languages, so you can actually think in terms of bits and bytes. It has a great std lib so you can get stuff going quickly and reliably.

BaculumMeumEst
0 replies
10h26m

Writing Go is less fun but the language has far better tooling, dead simple deployment, lower memory usage, generally higher performance, and is easier to onboard new developers. Also I find it way easier to read old projects after time away.

You can get incredible mileage out of Go using just the stdlib, built in tools, and the pure go port of SQLite. With Clojure it feels like I have to stitch a million random libraries together to get anywhere. Writing Clojure is delightful but the ecosystem and tooling pale in comparison, and at the end of the day I think that’s what matters.

If Clojure had great built-in tooling, better error messages (and maybe some SBCL-esque type checking features), and if Datomic was open source and less rough around the edges, I think the language would have been far more successful.

dheera
4 replies
12h36m

The "j" is always what put me off from learning Clojure. I've had too many bad experiences with JDKs and JVMs that I stay a thousand kilometers away from any thing that has "J" in it unless it's referring to JavaScript.

rads
0 replies
12h17m

Check out Babashka. It's a single binary that runs Clojure without a JVM. It also starts up really fast and has a much lower base memory requirement: https://github.com/babashka/babashka

It's pretty easy to switch to writing JVM Clojure if you're familiar with Babashka. Most of the libraries written for Babashka are designed to work in either environment.

That said, there are reasons you may want to use the Clojure on the JVM later on. It might be interesting to read the replies to another poster with similar concerns about the JVM: https://news.ycombinator.com/item?id=40445415

kaba0
0 replies
8h10m

Well, there aren’t too many more stable platforms out there, so your experience elsewhere couldn’t be all that cloudless either.

ertucetin
0 replies
8h24m

You can also try ClojureScript, which runs on JavaScript. If you're developing frontends.

KingMob
0 replies
9h18m

Interesting. Usually the reluctance comes from people confusing Java the language with JVM the platform.

drpossum
38 replies
23h55m

I love clojure, but it's really lost a lot of the momentum it had as many imperative languages have adopted parts of functional programming (and much for the better) over the last many years.

On the other side I've felt a lot of the ecosystem work that was done has a more "timeless" quality. Coupled with java interop I haven't ever felt wanting when I do reach for it for some hobby projects I keep up with.

One thing I will say, since it takes a different tack and philosophy, I think any programmer learning some of it benefits from the different perspective.

d4mi3n
17 replies
23h33m

In my experience, the subsets of the community around clojure were one of the biggest problem with it. It's gotten better over the years, but circa 2016 - 2018 it had a spike in popularity despite being very hostile to newcomers.

There was an almost apologist attitude towards rough edges or failure modes folks new to the community would fall into. I managed to work with it for a time despite that, but it left me with a bad taste in my mouth. It's really important to make your ecosystem and communities welcome to new users or they're destined to fade.

crispyambulance
9 replies
23h17m

  > ...had a spike in popularity despite being very hostile to newcomers.
To be fair the community itself, as humans, was very welcoming to newcomers. Really super nice and helpful folks.

If anything was "hostile" it was the dominance of emacs and very limited options for other tooling. That, and the horrifically unhelpful leaky abstractions in the stack trace when something went wrong. It's a big step, if you don't already know emacs to learn emacs (at a fairly advanced level) AND a new very different programming language.

I see now there's a vscode option with Calva. I haven't tried it. Might do that someday. Really wanted to like this language!

gleenn
2 replies
23h2m

Cursive plugin for IntelliJ is a fantastic option, it's not free but it is excellent.

aeonik
1 replies
21h41m

it's nice, but I used to write Java, and even getting IntelliJ setup on my laptop took a lot of fiddling with JVM versions and getting it to recognize my Clojure install.

To this day, I will still have weird issues where Cursive won't run a project, and Emacs will.

All that being said, I do really like Cursive.

cess11
0 replies
13h1m

I use https://sdkman.io/ to manage JVM versions, have you tried that? I haven't used Cursive, maybe it does something weird, but in general IntelliJ seems to accept it just fine in my everyday work.

neilyio
1 replies
21h27m

I'll second that the popular tooling, while powerful and reliable, its just not user friendly.

The official Clojure CLI, for example, is just plain confusing, and that's most people's first impression to the entire ecosystem. The config files, while they use the wonderful `.edn` format, are also not intuitive. Newcomers are the most likely people to encounter the most amount of error messages... which are famously difficult to read.

And that's before you even get into REPL configuration, which involves coordination with your editor process, a client process, and a server process. Even if you have a tool like Calva or CIDER managing it for you, you'll still get confused when something goes wrong unless you grok all the moving parts.

Even if you figure that all out, you still don't have Parinfer or equivalents setup yet in your editor. Also, clojure-lsp tends to require some configuration to get working the way you want. And that's before you get started with ClojureScript, which brings the complexity to another level entirely.

Despite all this, I love Clojure. It's an expert's language, even though it shouldn't have to be. Once you learn this stuff, you respect why much of this complexity exists. It's inherent to the amount of power the language gives you.

But doesn't mean we can't make it easier to use and get started with.

roenxi
0 replies
18h12m

The official Clojure CLI, for example, is just plain confusing, and that's most people's first impression to the entire ecosystem. The config files, while they use the wonderful `.edn` format, are also not intuitive.

I completely agree; it is unfortunate they don't spend more time officially recommending leiningen.org. A beginner attempting to use the built-in CLI is going to lead to a poor first 3 months.

astrashe2
1 replies
21h23m

This matches my experience as an amateur programmer. The initial hill was steep, but I don't think it was because people weren't friendly.

There is one cultural thing that might be confused with unfriendliness. Sometimes people react badly if someone posts incorrect information. But I think that's good. When you search for information about Python or PHP you have to wade through quite a bit of junk. Ironically, it's sometimes easier to find correct answers for Clojure.

Clojure itself is very clean and consistent, it's got a lot of polish to it, which makes it comparatively easy to learn. And there isn't that much of it. But for a long time the tooling was hard.

That's far less of a problem than it used to be. deps.edn and shadow-cljs both made things easier, as has Cursive. People say nice things about Calva, but I don't know it.

I'm a big fan. Babashka alone is enough to make learning Clojure worthwhile. Also, for someone like me, it's kind of nice that it feels almost finished. Once you learn it, you know it, and now that the tooling has settled down a bit you don't have to keep running to keep up.

hluska
0 replies
16h1m

People posting the wrong information is a great opportunity for a community to explain why it’s wrong. We lost that take on community and it’s a major loss for our entire industry. It’s remarkably hard for people to figure out why they’re wrong when they’re wrong.

I don’t think the solution is the Usenet-esque “you are wrong and your breeding is suspect” way. But there’s a very good place in the middle and I’d really like to find that place.

Business wise, I think we’re using the wrong paradigm in some major places. Maybe we can beat that while I’m still alive and that would be a net win for our whole craft.

yungporko
0 replies
22h4m

the tooling is the reason i gave up when i was interested in learning clojure. everywhere pretty much said that emacs was the "correct" editor to use for clojure, i tried it out for a bit but ultimately learning a new language and a new editor at the same time was just too big of an ask.

i tried calva with vscode afterwards but it was basically the same thing, calva has paredit which overrides the keyboard navigation and there was no way to disable it. somebody had asked for the option to disable it on the github but the creator said something along the lines of calva without paredit wasn't the way he wanted it to be used, so i just picked another language to learn.

kimi
2 replies
23h22m

YMMV. I always found it very welcoming and full of interesting people.

bunderbunder
1 replies
22h49m

I may be wrong, but I think the parent poster was talking more about the language and ecosystem than the community. I, too, have found the community to be amazing. But the language itself used to be quite frustrating to learn. It's better now, but I think that by the time it got fixed many companies and teams had already been burned.

Clojure is particularly vulnerable to that because it really is an enterprise applications language. That makes it more vulnerable to learning curve problems than a language like Rust whose most direct competitors are other languages with comparably steep learning curves.

kimi
0 replies
12h7m

Yes, I agree with you, learning is complicated, because it's mostly un-learning habits you had for 20+ years. Stack traces suck, but after a while you grok them. The clojure/core is full of niceties, but it's so big you need a map just to know what's in there. And still...

bunderbunder
2 replies
23h22m

A somewhat similar thing I ran into is that existing Clojure code can be incredibly difficult to grok if you don't already know the language very well.

Some of this comes from lisp's minimalist syntax, which makes it hard to even know what kind of thing you're looking at when you're encountering a new thing for the first time. But the problem is also compounded by some of Clojure's more distinctive (and powerful) features such as ad-hoc polymorphism and using maps to pass function arguments.

The closest analogy from imperative languages that I can think of is another language that's famous for being incredibly productive in the hands of a skilled user, but whose code tends to feel kind of write-only: Perl.

slifin
0 replies
20h42m

If I can get clojure storm running in my project then I find a lot of code incredibly straightforward

Because there's a preference for just passing immutable data around the time travel debugger really helps me understand complex interactions

kazinator
0 replies
23h1m

In Perl you have the dynamism, and the syntax.

Evidently, 93% paint splatters, when OCRed, are valid Perl programs:

https://www.mcmillen.dev/sigbovik/2019.pdf

I doubt that a similar thing is true for Clojure.

Here, the only problem is that you don't know what the symbols and some of the notations mean. You can look at the unfamiliar syntax and know what is a child of what. Most operators are words you can search for.

wredue
0 replies
21h14m

That is basically every functional programming language in existence.

calvinmorrison
15 replies
23h0m

many imperative languages have adopted parts of functional programming

nailed it. I don't know much about functional languages other than a haskell course back in the day, but I don't want to do functional all the time. It plays great in some situations and I am happy to use those language subsets in my daily coding, but I don't need my entire application to be written in an esoteric language

grumpyprole
14 replies
22h47m

This is of course a popular opinion and pretty much the C++ philosophy. Unfortunately a lot of the benefits of functional programming cannot be fully realised unless you are "all in". The paper "The Curse of the Excluded Middle" is somewhat blunt but it makes some good points: https://queue.acm.org/detail.cfm?id=2611829

macintux
11 replies
22h14m

Programming without immutability is so painful to me, no matter how many functional features a language adds.

grumpyprole
5 replies
21h49m

It's painful for the compiler too, it has to turn the parents imperative code into SSA (essentially A-normal form) so it can optimise it!

wredue
4 replies
21h8m

You guys can make all the baloney claims about this you want.

The day that Haskell stops being 10x slower than languages providing mutable data is the day we can start to seriously entertain your claims.

grumpyprole
2 replies
21h0m

There's nothing baloney about SSA form. I'm sorry to say it, but C is just not close to the metal any more. Even if you are able to hand optimise something so it works well on one architecture, it likely won't be optimal for another.

As for Haskell, it does pretty well being 100 times faster than Python with 100 times less the number of people working on it.

wredue
1 replies
19h56m

I believe that your interpretation of what’s actually happening is what’s baloney.

The fact is that you Haskell people only talk about the optimizations that can sometimes open on immutable data in specific circumstances. What you generally ignore is the optimizations that immutable data permanently locks you out of with no recourse.

As with most things programming, immutability should be considered a tool, not a rule.

grumpyprole
0 replies
13h3m

I believe that your interpretation of what’s actually happening is what’s baloney.

I'm actually quoting Prof Andrew Appel of Princeton: https://www.cs.princeton.edu/~appel/papers/ssafun.pdf

You seem to think that functional programming and in-place updates are mutually exclusive. This is not the case, e.g. Haskell supports mutation as a tracked and controlled side-effect. It can even give static guarantees that a function is pure even it uses mutation internally. Recent research even suggests that compilers can add the in-place updates for us: https://www.microsoft.com/en-us/research/publication/fp2-ful...

joshlemer
0 replies
16h57m

I think the persistent collections are generally worth the cost. IIRC, for HAMT maps/sets for instance, they're about twice as slow for reads and four times as slow for writes. For bulk updates, you can also slip into using transients, and then when you're done, "freeze" it back into a persistent data structure.

I only wish that the transient collections would support more different kinds of writes, like support all operations on java.util.List/Set/Map kind of thing. Forget which ones aren't present but I remember there being a couple...

throwaway96666
4 replies
21h27m

In my experience jumping from a Clojure shop to a large Java shop a few years ago, the benefits of persistent data structures are overstated. Mutable collections are just as good for 99% of use cases. And they're a lot faster (in single threaded code) and occasionally mutation makes things easier.

The selling point of Clojure is that persistent data structures prevent several classes of bugs (unintended mutation, locking, etc.). But in reality -- as long as your team members are good enough programmers -- I don't see these kind of bugs happen in practice.

That being said I love Clojure and the standard library is the best out of any language. It is a great choice in the small market of "projects that need simple and correct code".

slifin
1 replies
20h38m

Looking at an object in my debugger back in my call stack and assume I'm looking at the value as it was but in reality it was mutated in a subsequent stack gives me trust issues

It's probably fine most of the time it's just when I have to get into the weeds I want to have stability

throwaway96666
0 replies
19h18m

That seems like a debugger problem, can't the debugger clone/maintain history of the object?

iLemming
0 replies
14h28m

the benefits of persistent data structures are overstated.

Well, what else is overstated?

- Structural editing? Fine.

- REPL-driven development? Okay, let's throw that out the window.

- Hosted nature and the interop? Gone.

- Destructuring? Eh, we kinda have it in Javascript, right?

- Concurrency support? Who needs that shit, anyway, right?

- Simplicity and elegance? Arguable. Some like verbose Typescript code more.

- Functional programming? What the heck is it even?

The point I'm trying to make is that you can't just "remove" an essential part of what makes a language. Rich Hickey took a year-long sabbatical (or was it two or even three years? I forgot) and used his savings to get this aspect of the language right. Without the immutable collections, the language would've been an entirely different beast.

grumpyprole
0 replies
21h4m

This is like saying "the benefits of functional programming are overstated". If you are happy with mutable collections, you've happy with mutable variables, pervasive side effects and essentially the status quo. Many of us are not happy with the level of software quality out there and the status quo, Rich Hickey included.

wredue
1 replies
21h11m

a lot of the benefits cannot be fully realized unless you’re all in

That is working under the assumption that “the benefits” are actual benefits.

IMO, “the benefits” are measurably drawbacks, and not a technical debt I am willing to accept for no good reason.

grumpyprole
0 replies
20h42m

Functional programming is basically maths, it solves the problem of how to compose software safely. I struggle to understand why anyone who really cares about their craft would not want this. In fact, many want it so badly they are willing to make sacrifices for it (performance, esoteric languages).

elamje
3 replies
22h1m

Should have maintained a python interoperable runtime. Less and less people use JVM languages for things like web apps, data eng, data science, ML, etc.

jayemar
0 replies
3h56m

Briefly looking through this it reminds me of hy

pants2
33 replies
23h44m

Cool site, I've never tried Clojure before. My first reaction though is that (+ 1 1) is a highly unconventional and possibly confusing way of writing 1+1, and I'm not sure why that design choice came about.

julianeon
10 replies
23h33m

On the contrary - I think it's much easier!

The real advantage of this notation is that it's much, much easier to stack calculations.

Example:

(/ (+ 34 68 12 9 20) 140)

You can imagine how the first part of that could come about:

(+ 34 68 12 9 20)

And then the second part (pseudocode):

(/ sum 140)

In Clojure it's easy to mash them together, or for example to paste the first calculation in the second.

(/ (+ 34 68 12 9 20) 140)

Want to go further? Easy: add another enclosing parens.

(* (/ (+ 34 68 12 9 20) 140) 1.5 2)

Note how we're stacking in a more human-readable order - a new calculation starts on the left hand side, the first thing we see as we read it.

Compare how verbose the alternative is:

((34 + 68 + 12 + 9 + 20) / 140) * 1.5 * 2

floodle
3 replies
23h3m

A programming language should be first and foremost precise and readable, not concise. I can barely understand the clojure version but when I read the "traditional" one I don't even need to think.

If you work with clojure a lot, does it become natural?

julianeon
0 replies
22h55m

I would say yes, as someone who got used to it a few years ago.

barrell
0 replies
21h41m

I've worked with clojure for years, and it becomes pretty normal, but I don't think it inherently get's better than the alternative, just on par... although it's realllly nice not to ever have to think about operator precedence, especially if you have to switch between languages.

Where it really shines though is when you use the threading macro and inline comments to make really complex math a breeze to review:

  (-> (+ 34 68 12 9 20) ;; sum all the numbers
      (/ 140)           ;; divide by a quotient for some reason
      (* 2)             ;; multiply by two for it's own reason

ARandomerDude
0 replies
22h52m

Yes, especially because the language is so consistent.

99% of the syntax is just (foo arg1 arg2).

eviks
3 replies
22h55m

I'd take the verbosity over having to count the operators from the start of the line to figure out which one are used at the end of the line "1.5 2"

skydhash
2 replies
22h33m

The parenthesis highlight in any decent editor. So it always very obvious which operators apply to the operands.

eviks
1 replies
12h31m

This reduces the friction, but doesn't eliminate the needles back and forth. Breaking context locality is just bad

The threads example in another comment is way better

skydhash
0 replies
1h41m

There’s no needle back and forth. Everything in parentheses is a complete expression, like a formula. You have the operator (function) and the operands (args). Think of it as add instead of + and multiply instead of *. You get used to it very quicly and then it does not matter.

ReleaseCandidat
0 replies
23h13m

(* (/ (+ 34 68 12 9 20) 140) 1.5 2)

The problem with that is by the time I reach `20)` I have already forgotten what operation I'm in. I'd write it more like this:

    (* 
      (/ (+ 34 68 12 9 20) 
         140) 
      1.5 2)
actually I'd write this as

    (/ 
       (* 2 (/ 3 2) (+ 34 68 12 9 20))
       140)
> ((34 + 68 + 12 + 9 + 20) / 140) * 1.5 * 2

Why not (34 + 68 + 12 + 9 + 20) * 1.5 * 2 / 140?

ARandomerDude
0 replies
22h55m

Use the thread macro to make this easier to think about:

(-> (+ 34 68 12 9 20) (/ 140))

kolme
5 replies
23h36m

+ is a function, there are no operators in Clojure.

That allows for some nifty tricks like:

(reduce + [1 2 3]) ; returns 6

globular-toast
4 replies
23h21m

Another neat thing is that these functions are n-ary, and that includes 0 args. So (+) => 0 (additive identity) and (*) => 1 (multiplicative identity). Little things like this are missing from languages like Python and make functional programming worse than it should be.

tasuki
3 replies
22h12m

Oh wow, this is truly great! Would you have a link to the code behind `(+)` and `(*)` ?

(In my functional programming languages, `reduce` also requires passing an initial value, like `foldl (+) 0 [1, 2, 3]`. But surely it should get a monoid instead of two separate arguments for the operation and the starting value!)

globular-toast
0 replies
9h5m

Yeah, it always annoys me to have to pass an initial argument. The idea of identities is built into Lisps and seems conspicuously missing from other languages and I don't know why. In Python and JS people have to write stuff like `lambda x: x` over and over again. The identity function is surely special enough to get its own name.

widdershins
1 replies
23h28m

Using the same notation for function calls and math operators has many benefits that may not be immediately obvious, and which may (depending on preference) outweigh the unfamiliarity. For example:

No operator precedence rules to remember.

Use math operators in higher order functions:

    (reduce [1 2 3] +)
    (compose + \*)
Simpler parser in the language.

Use kebab-case variable names.

Use most symbols in variable names.

The last two are because of reduced ambiguity in the language. The benefits for readability can be huge. For example, I love question marks for predicates in Scheme.

    (vector? x)
    (filter [1 2 3 4 5] odd?)
I'm sure there are more benefits that I haven't thought of.

ReleaseCandidat
0 replies
23h5m

Use math operators in higher order functions:

To be fair, there just needs to be syntax for passing infix functions as a "normal" function, like parens in Haskell

  (reduce [1 2 3] +)
  foldl' (+) 0 [1, 2, 3]

And to allow `?` in names, it "just" shall not be used elsewhere.

sek
1 replies
23h41m

Lisp is one of the oldest programming languages developed in the 1960, it came before and is very elegant actually. You can write incredibly powerful things with this pattern and it's also really simple to build an interpreter for it with the stuff they had at their disposal at the time.

weatherlight
0 replies
23h42m

because lisp and consistency

(some-function-name arg1 arg2)

taneem
0 replies
23h35m

The way to think about it is that you're processing a list, where the first argument is an operation, and the subsequent arguments are numbers to add. Clojure, and other Lisp based languages use this structure (a list) for representing everything - both data and functions. It turns out to be a very simple yet endlessly flexible and extensible concept.

phoe-krk
0 replies
23h39m

Try 1 + 2 + 3 + 4 + 5 versus (+ 1 2 3 4 5) for one nice reason.

netbioserror
0 replies
23h37m

In prefix notation (which has been around for a very long time) the operation comes first. Think of it as the "addition" function being applied to the arguments following it. This matches how nearly all programming languages are broken down into their abstract syntax trees while compiling.

As an added bonus, you now know Lisp. This is how all Lisp syntax works: `(function arg1 arg2 ...)`. That's literally it.

kazinator
0 replies
23h3m

It resembles command language: + is the command, and 1 and 1 are arguments.

  mv foo.txt bar.txt  # rename a file in the Unix shell
Except there are parentheses to delimit the command because commands can be nested in each other.

(Some Lisps have interactive modes where you can drop the outermost parentheses, allowing you to type like this:

  prompt> + 1 1
  2
but usually the parentheses are part of the formal syntax; where this is just a hack in the interactive listener.)

The design choice came about because the syntax started as an internal representation for a symbolic processing (formula manipulation) system that was being designed by John MacCarthy. The internal representation where the operator is first followed by its arguments was convenient because you don't have to parse around to identify them. You know immediately that by accessing the first position of the formula, there is going to be a symbol there which identifies its operator.

The internal form, and its written notation came to be used directly, while the symbol manipulation system came to be programmed in itself, so that its own "formulas" (source code) ended up in that form.

kamma4434
0 replies
23h37m

Because (+ 1 2 3) makes 6. This said, doing any kind of maths in clj, especially division and comparisons, is a PITA - I’d go as far as to say that’s the worst part of the language. Otoh, (< 3 x 4 y) is pretty cool.

globular-toast
0 replies
23h19m

Your comment is a highly unconventional and possibly confusing way of writing... to a Chinese person ;)

ertgbnm
0 replies
22h59m

Prefix notation isn't unconventional and it has many benefits.

The main one being if you want to add many many items together it's much easier IE (+ 1 2 3 4 5 6).

Instead of doing an operation between two numbers you are apply a function to a list of inputs. In the "+" function's case you are adding them together. With this in mind, it's no different than most other programming languages. You would never have your function be in the middle of your arguments/inputs.

In python its Foo(bar, bar) and not bar Foo() bar, which obviously doesn't make sense.

bunderbunder
0 replies
23h6m

When McCarthy was first working on Lisp he intended to migrate to an infix syntax (called m-expressions), but abandoned the effort because everyone came to really like the current syntax (s-expressions) after they got used to it.

I know it's really hard to see how. (And honestly it's sometimes a little hard for me to see what the big deal is, but one of my first programming languages was a dialect of lisp so I can barely even remember not being comfortable with them.) But many people find that, once they get used to them, and especially if they learn to use an editor with a paredit mode, they can start to feel even easier to work with than infix syntax.

amelius
29 replies
21h9m

unlike full-JVM Clojure it has a very fast startup time

I can't believe that after all these years Java still didn't fix their startup time.

pron
8 replies
20h23m

The JVM cold-starts, loads a Hello, World program from a compressed JAR, runs it and shuts down in 40ms. But Clojure compiles quite a bit of Clojure code generating hundreds if not thousands of classes and then loads them before starting up the Clojure program. Still, there's ongoing work on the JVM (Project Leyden [1]) to speed up both startup and warmup even of such programs by caching more state.

[1]: E.g. see https://spring.io/blog/2023/10/16/runtime-efficiency-with-sp...

kamaal
2 replies
16h22m

>The JVM cold-starts, loads a Hello, World program from a compressed JAR, runs it and shuts down in 40ms.

Im yet to reach the X-men level super qualities that can detect, and work in 40 ms chunks. Or at least even notice a 40 ms delays.

I envy the humans who can notice such small chunks of time.

pron
0 replies
10h1m

Right, but the problem is that many programs do a lot more work when they start up than Hello, World. The Clojure runtime in particular does quite a lot at startup.

joshlemer
0 replies
2h24m

I don't like how this issue is constantly dismissed out of hand. It very obviously is actually a massive glaring issue which severely limits what clojure can reasonably be used for. Nobody would ever accept a 1 second startup time for CLI applications that we use all the time like git, kubectl, npm, docker, etc.

geokon
1 replies
14h14m

Why can't you do some JVM equivalent of memcopy/execve the starting state of the program?

Isn't the initialization procedure (or at least the vast majority of it) exactly the same at each run ?

pron
0 replies
10h3m

That's pretty much the idea behind Project Leyden's "premain" work. The tricky bit is that the program startup being almost exactly the same each time isn't quite the same as being exactly the same. The JVM already caches some things and the capabilities of that mechanism are being expanded to cover more, including JITted code as well as some program computations done at initialisation.

fiddlerwoaroof
1 replies
14h1m

Back when I wrote Clojure professionally, using GraalVM to generate a native executable of things like clj-kondo basically eliminated the startup latency.

pron
0 replies
9h2m

Right, but Native Image comes with its own tradeoffs. Lyeden's "premain" work aims to be somewhere between the situation today and Native Image.

didibus
0 replies
14h19m

You still don't see many scripts or CLI apps in Java though. I was wondering if that would change now that you can run a source file directly, but then wouldn't the startup be slower, because now it's also having to compile.

rtpg
5 replies
21h4m

My understanding is that this isn’t really a JVM thing, but I might be wrong.

koito17
4 replies
20h47m

Your understanding is correct. JVM startup accounts for a small portion of Clojure's startup time.[1] Most of the overhead is in compiling and loading clojure.core. Efforts have been made to remedy this issue[2] (e.g. direct linking, ahead-of-time compilation, ...), but this doesn't remove the fact that clojure.core is huge and virtually any Clojure program will be importing more than just clojure.core, so there is still a lot of var derefs to deal with, then code to compile, then classes to load, etc.

[1] https://clojure-goes-fast.com/blog/clojures-slow-start/

[2] https://clojure.org/reference/compilation

didibus
3 replies
14h14m

Well, it's still partially the JVM at play. For example, if your application has big classes, and many classes, the JVM will be slow to start. This is what is happening here. Clojure is like a large-ish Java project, it has big classes, and many of them, with static initializers, that need loading at the start, and the JVM does all that slowly.

In some sense it's Clojure's fault for having an implementation that causes slow JVM startup, but it's also the JVM's fault that the way Clojure uses it causes it to take a long time to start.

pjmlp
2 replies
11h40m

The various JVM implementations have mechanisms to fix that, like JIT caches and AOT compilation, which Clojure doesn't take advantage of.

So it is indeeed a Clojure issue, not a JVM one.

didibus
1 replies
10h6m

Can you talk more about these?

pjmlp
0 replies
8h36m

AOT compilation with PGO, available for free on GraalVM and OpenJ9.

Also available since around 2000 from comercial vendors, of which, Aicas and PTC are the main survivors.

https://www.aicas.com/wp/products-services/jamaicavm/

https://www.ptc.com/en/products/developer-tools/perc

OpenJ9 also does JIT caching across executions, https://eclipse.dev/openj9/docs/aot/

OpenJDK also does caching but at higher level,

https://docs.oracle.com/en/java/javase/22/vm/class-data-shar...

https://wiki.openjdk.org/display/HotSpot/Application+Class+D...

Project Leyden plans to add a similar JIT cache like on OpenJ9, https://openjdk.org/projects/leyden/notes/02-shift-and-const...

Azul and OpenJ9 have cloud JIT servers, that share execution heuristics and dedicate servers for highly optimizing compilers,

https://www.azul.com/products/prime/cloud-native-compiler-fa...

https://eclipse.dev/openj9/docs/jitserver/

Finally, although technically not really Java nor JVM, the Android Runtime (ART), does a mix of high performance interpreter written in Assembly, JIT, AOT compilation, and PGO sharing across devices via Play Store (cloud profiles).

https://source.android.com/docs/core/runtime/configure

neilyio
4 replies
21h3m

When you get into REPL-driven development, the JVM startup time (which is often under a second for me anyways) is a total non-issue. You don't continuously restart your program to see changes or run tests. You can refresh all your state instantly without exiting.

But before Babashka, that was indeed a barrier to using Clojure in shell scripts. Now we have it all!

amelius
2 replies
20h50m

In Unix it is customary to invoke tools from the Bash shell or Bash scripts. That doesn't mix well with a separate REPL.

neilyio
0 replies
20h41m

I see your point here... I was addressing to the feedback loop during development time. Babashka works well for Clojure in a Unix tool pipeline.

It's also possible to compile your JVM Clojure program yourself to a binary with GraalVM for even better performance than Babashka and even faster startup.

fiddlerwoaroof
0 replies
13h56m

Clojure and Common Lisp are the two cases where I’ve never felt the need to work in bash: most projects grow a library of utilities for development that aren’t limited by the stringly-typed nature of bash or zsh

geokon
0 replies
14h10m

Except in Babashka you can't use Java libraries.. Right?

I feel a good fraction of code will dip into Java libs at least a bit - so you're limited in what libraries you can use

I think the real solution is probably Graal native - though it's not part of the official toolbox/deps.edn

paulddraper
3 replies
18h56m

It's not the JVM.

It's how much code you load.

didibus
2 replies
14h9m

I mean... That's not an issue in other runtimes, so it's kind of a JVM quirk no?

pjmlp
0 replies
11h30m

Those other runtimes also don't do half of the features a JVM usually has to offer, and most people complaining also don't bother to actually learn the Java ecosystem, the existing set of JVM implementations, and the optimizations features made available to them.

paulddraper
0 replies
2h5m

No, that's defiantly true in other non-native runtimes.

E.g. any Python project has to deal with this, like Mercurial.

Java projects tend to (insert stereotype) have a lot of code.

derefr
1 replies
20h45m

I think, in a lot of cases when people still complain about "the slow startup time of the JVM", they're really just talking about how the big JVM GUI apps (like IDEs) struggle to get started on heavily-loaded systems. And this, I think, is mostly just due to these apps eagerly reloading the most recent workspace on startup, and so pre-allocating big chunks of memory on startup to be ready for that — which can ripple out, on systems with low free memory, as other, colder processes all bottlenecking together on the IO of having their own memory written out to swap; and/or to having dirty mmaped pages forcibly-flushed to disk en masse so that the page-cache entries they live in can be purged.

Much more rarely — mostly when talking about writing CLI tools in a JVM language — people actually are complaining about the single second-or-so it takes the JVM to start up. (Usually because they want to run this tool in a loop under xargs(1) or find(1) or something.)

This last second of startup lag is (AFAIK) quite hard to improve, as it's mostly not the JVM itself starting up, but the static methods of JVM classes being called as those classes are loaded — which can do arbitrarily much stuff before any of your own code gets control. (Due to legacy code expecting to read certain per-boot-dynamic info as static fields rather than as the results of static method calls, I believe the JRE runtime is actually required to do quite a lot of that kind of static initialization, to pre-populate all those static fields, just in case something wants to read them.)

---

You'd think that GraalVM could inherently skip most of this, because the Graal compiler does dead-code analysis. "If nothing in your code reads one of those static fields, then nothing needs to write that field, so let's not invoke the static initializer for that field." But that's not true: static initializers are exported and called by the runtime — so they're always "alive" from the compiler's perspective. The Graal compiler isn't doing full-bore data-flow analysis to determine which static members of which classes are ever read from.

I believe GraalVM does try to work around static initializers as much as it can, by pre-evaluating and snapshotting as much of JVM runtime's static initializer code as possible by default, converting it all into const data structures embedded in the class files before the native codegen step gets run on it (see: https://www.graalvm.org/latest/reference-manual/native-image...).

It's not possible to apply this pre-baking to 100% of classes, sadly — some of these data structures need environment data like env-vars or system network config threaded into them on boot.

(I wonder anyone on the Graal project is working on a fully-general static-initializer optimization pass, that does something like concolic execution to bake these initializers out into either fullly-constant data if possible, or if not, then constant "data templates" plus trivial initializer functions that just gather up the few at-boot context fragments, shove them into the "data template" using a low-level hook, and then memcpy the result out onto the heap and call it an object.)

pjmlp
0 replies
11h32m

They are working with PGO, and adding also AI based optimization algorithms, both can help.

rads
0 replies
19h49m

It's a tradeoff. The startup time of Clojure on the JVM is slower than most, but the runtime is faster than most. It also needs a lot of memory to get going. This means it's optimized toward long-running programs like web servers. During development, you use the REPL interactively which makes this a non-issue, but it does take some getting used to at first.

That said, there are alternative runtimes that have different tradeoffs. For example, Babashka is a runtime for Clojure that uses GraalVM instead of the JVM as the foundation. Babashka scripts have about a 10ms startup time on my M1 MacBook Air.

pjmlp
0 replies
11h42m

The problem lies with Clojure implementation, not Java or the JVM.

winrid
17 replies
21h52m

Clojure looks productive. What frameworks libraries do people use to build web apps? Like, replacement for Django view layer and ORM (not looking to debate orms thanks)?

rads
11 replies
21h17m

This is a good starting point if you want to get a web app going quickly: https://biffweb.com

It uses XTDB by default but you can switch to Postgres: https://biffweb.com/p/how-to-use-postgres-with-biff/

People don't really use ORMs in Clojure, they just write SQL directly and abstract the details from consumers using functions. That said, HoneySQL is a common alternative to writing SQL that makes it a lot less painful (and composable!): https://github.com/seancorfield/honeysql

winrid
9 replies
20h51m

Biff looks neat, thanks! I mainly just don't want to write raw sql/mappers to structures for simple queries. Looks like most sql libraries with clojure can just return maps so that's neat.

rads
6 replies
20h18m

Here's a quick example of how DB access generally looks in production:

    (ns rads.sql-example
      (:require [next.jdbc :as jdbc]
                [honey.sql :as sql]
                [clojure.string :as str]))

    ;; DB Table: posts
    ;; +----+-------+
    ;; | id | title |
    ;; +----+-------+
    ;; |  1 | hello |
    ;; +----+-------+

    (def ds (jdbc/get-datasource (System/getenv "DATABASE_URL")))

    (defn row->post [row]
      ;; This is your optional mapping layer (a plain function that takes a map).
      ;; You can hide DB details here.
      (update row :title str/capitalize))

    (defn get-posts [ds]
      ;; Write a SQL query using Clojure data structures.
      (let [query {:select [:*] :from [:posts]}]
        ;; Run the query.
        (->> (jdbc/execute! ds (sql/format query))
             ;; Convert each raw DB map to a "post" map
             (map row->post))))

    (println (get-posts ds))
    ;; => [{:id 1, :title "Hello"}]

winrid
5 replies
20h16m

You would abstract away the jdbc/execute part though, right? otherwise that's terribly unproductive compared to django etc.

rads
4 replies
20h15m

In practice I do wrap `jdbc/execute!` with my own `execute!` function to set some default options. However, there is no ORM layer. What makes you think the code above is terribly unproductive?

Edit: Not trying to dismiss your concerns, by the way. In Clojure you can often get away with doing less than you might think so I'm genuinely curious about the critique.

winrid
3 replies
19h9m

In Django I would just do Posts.objects.filter(title=x)

I don't need to define driver boilerplate for every query (or ever have to write it... at all).

didibus
1 replies
10h32m

In Clojure you'll have to write the queries yourself unfortunately. People always ask, where is the fully fledged web framework in Clojure? There isn't one. Why there isn't one is hard to answer, but it's partially because the people who could write one, don't find they need one themselves.

There's definitely a preference in Clojure for not relying on frameworks, because the current people in the community like to be in control, know what's going on, or do it their own way.

That said, the whole code still ends up being relatively small. So, you kind of end up with a similar amount of total code, but you're much more in control. And if certain things you find too repetitive, you can remove the repetition yourself through many of Clojure's facilities, specifically where they annoyed you.

See: https://github.com/didibus/simple-website-with-posts where I implemented the small website you were talking about, creating posts and seeing them. The whole code is here (minus the CSS): https://github.com/didibus/simple-website-with-posts/blob/ma...

It's 95 loc and that includes the templates. There's no framework.

winrid
0 replies
1h19m

I implemented the small website you were talking about

Thanks, that's neat.

I'm not even talking about the framework part. Just db access. Let's say I have a Posts with a managed_by property that points to a list of User which have a ManagedProfile. In Django's ORM (or any good ORM), I could do:

if post.managed_by.contains(user.managedProfile)...

or I could do:

post.managed_by.add(user.managedProfile)

also all these tables and join tables are generated by just a few lines of model definitions.

I'm still in control. I am writing the code. I get to choose when I do slow and fast stuff. Not having these features isn't "more control" it's less features. :P

I still see the benefits of Clojure, though!

rads
0 replies
13h3m

The key thing is experienced Clojure programmers often see a lack of ORM as a feature rather than an oversight. There were some more ORM-like libraries years ago (see Korma) but my impression is that people ultimately didn't want this and moved on to lower-level JDBC wrappers combined with HoneySQL. I found a more detailed discussion on Reddit about Clojure and ORMs back in 2020 if you want to get more info: https://reddit.com/r/Clojure/comments/g7qyoy/why_does_orm_ha...

Note that I'm not making a value judgement about Python/Django or any other library/framework combination. It's obviously a valid path, but Clojure is a different path. I can assure you there are straightforward solutions to create readable APIs like the Django example with minimal boilerplate, but the approach is fundamentally different from Python/Django.

If you do decide to build something in Clojure and think, "I already know how to do this in Django, why is it missing?", don't hesitate to join the Clojurians Slack and hop into the #beginners channel. There are plenty of people who can help you there.

didibus
1 replies
13h22m

There's no object in Clojure, so there's no need for an Object Relational Mapper. You just work directly of the query result sets, which the SQL library itself can conveniently turn into rows of maps if you prefer (over rows of lists).

winrid
0 replies
1h17m

No object is kinda mind blowing since it has java interop. I guess everything just becomes maps?

neilyio
0 replies
21h12m

HoneySQL is so, so good. It does for SQL what Hiccup did for HTML. Once you start writing with those, it's hard to remember there's any other way.

winrid
0 replies
19h6m

Those all look great, including HugSQL, thanks!

neilyio
1 replies
21h19m

Check out Biff, it's very thoughtfully made: https://biffweb.com

anentropic
0 replies
6h23m

It's kind of surprising the most popular(?) web framework uses a weird/obscure db

I have no doubt that XTDB is good, it is just surprising as a first choice and is not going to be easy to get up and running compared to the conventional alternatives

(Is there even a hosted offering for XTDB? I like that it's open source but seems that you will have to grapple with all this stuff including a Kafka cluster https://docs.xtdb.com/guides/starting-with-aws.html)

whalesalad
0 replies
21h24m

There is not a batteries included framework a-la Django or Rails for Clojure. I would argue that is one of the biggest pitfalls to the language/ecosystem. If you are building a web application, you will need to invent the entire thing yourself. There are micro frameworks and tools that exist standalone to deal with HTTP, DB ORM, etc... but that will be an exercise left to the reader.

Some will say this is a good thing (and as a very experienced engineer I will agree) but the barrier to entry for a newbie is quite high in this regard. You have all the rope to hang yourself with - and you will. Especially if you are on a team full of lots of interns and junior folks.

xyzzy4747
13 replies
23h3m

I'm happy with TypeScript, Go, and Rust. Don't feel like learning anything else.

zug_zug
7 replies
22h5m

I'm with you. I'll even go a step further, since I haven't heard anybody else say this:

My hot take -- There are already too many programming languages in use and every engineers life would be easier and productivity would be higher if we standardized.

There is almost no situation where making an entirely new language is the optimal solution. And the worst reason of all to make a language is anything aesthetic (e.g. spacing, parentheses, notations) -- all of those cases should be handled via native transpiling in the IDE.

zug_zug
3 replies
14h4m

I'm not sure if you meant this as evidence for or against my point, but this is exactly what I mean.

Every year dozens of people think they're going to make some holy-grail language and it's 1% different from the prior version but now every single library needs to be rewritten, a dozen years of patches/bugs/security-holes must happen, whole resumes get shined up rewriting tech stacks that were perfectly capable, all for it to be thrown for the next shiny toy in less than a decade.

A new language just fractures knowledge.

cess11
2 replies
13h16m

Is that how you see people that know several natural languages? You think they're intellectually fractured?

zug_zug
1 replies
3h9m

I don't really get what you're getting at here.

It sounds like you're trying to draw some equivalence between multiple spoken languages (largely seen as something brag-worthy-ish) and multiple programming languages. Like if culture thinks it's sexy to know french that somehow that means it's sexy to know Cobol [It's not].

The two are wildly different of course, a programming language can be learned in weeks and a spoken language takes years.

But if your question is -- would the world be a better place if we all spoke the same language? Then yes, absolutely.

Fortunately AI will help continue to reduce these artificial barriers between languages.

cess11
0 replies
2h47m

I'd consider a person that has only studied programming for weeks extremely junior.

Edit: And no, "AI" is not going to affect any such barriers. It's already trivial to learn new natural languages, and some people do, some don't. Those who don't, generally don't care about people that speak other languages than the one they learned in childhood.

rads
0 replies
21h44m

Hmm, maybe we could come up with a standard syntax? We could call it “Standard-expressions”, or perhaps “S-expressions”? That way an entire family of languages could use the same syntax. Now how do we get people to follow this standard?

iLemming
0 replies
14h46m

If we were forced to use only selected, most popular languages to communicate and ban all others, everyone would have to speak Mandarin, Spanish, and English. And the world would never know the Quran, the Bible, Arabian Nights, the Epic of Gilgamesh, War and Peace, the Ramayana, or the Divine Comedy.

There are some good examples of applications that are specifically written in Clojure and would be quite difficult to replicate in other PLs - Roam Research and Logseq, XTDB and Datomic, Nextjournal and Precursor.

And the worst reason of all to make a language is anything aesthetic

Interestingly, people avoid learning Lisp, because it doesn't look "sexy enough" the first time they see it.

latexr
0 replies
20h22m

Weirdly appropriate that the first thing on the website is this quote:

If you want everything to be familiar, you'll never learn anything new. - Rich Hickey
jwr
0 replies
21h45m

I'm happy with Clojure, having progressively discovered better and better programming languages over the years, and yet I'm constantly on the lookout for new languages and approaches.

Don't feel like being the Blub programmer and missing out on new good stuff.

iLemming
0 replies
15h4m

Don't feel like learning anything else.

If you need to do graphql in typescript, you still "learning a new language". If you're using Prisma or you doing css-in-js, or rxjs, or tRPC, or Cypress, you're still "learning a new language".

You're basically moving from having to understand one (seemingly arbitrarily composed) syntax to another (seemingly arbitrarily composed) syntax. While I learned Clojure syntax once, and now only have to learn paradigms and techniques - logic, pattern-matching, concurrency, reactive dataflow, polymorphic dispatch, metaprogramming, event-driven programming, state management, etc. etc.

My hope is that I never have to use TypeScript, Go, or Rust daily since Clojure already gives me everything I need to write programs. It simply makes much better sense for the type of programs I'm writing today. Someday that may change, but I doubt that any of those would suddenly start making better sense to use. It probably will be something else, not these.

ekzy
0 replies
22h43m

Then… don’t? No ones is forcing you to try it or even to comment with your close-minded opinion. What does this comment bring to the conversation?

BeetleB
0 replies
21h49m

Do you post this comment on every thread involving a language that isn't once of your Holy Three?

Personally I don't feel this strong urge to tell communities that I'm not interested in them. Waste of my time and theirs.

neilyio
13 replies
23h0m

If you are new to Clojure and would like to experiment with it in a way that is immediately useful, I highly recommend the Babashka runtime for scripting [0]. It's very fun, approachable, and one of the more polished parts of the Clojure ecosystem.

It's a particularly good entry point because unlike full-JVM Clojure it has a very fast startup time. Newcomers can use any file-watching /reloading tools (e.g. nodemon) that they're already familiar with to work with it interactively.

Hopefully, a enthusiastic user will graduate to using a REPL connection in their editor for a fully interactive setup. But newcomers tend not to do this... its an unfamiliar workflow to most, and can be pretty cumbersome to setup.

[0]: https://babashka.org

neilyio
9 replies
22h32m

And when you're ready to take the fun to the web, look no further than Biff: https://biffweb.com

packetlost
3 replies
22h8m

I recently went through most of the Biff tutorial but found it seemed to be missing some parts later on that had me scratching my head. It was otherwise a very enjoyable experience and Biff seems like a great way to get a "batteries included" starting point for web (similar to something like Rails or Django, though maybe not as comprehensive as either of those).

jacobobryant
2 replies
21h2m

Mind sharing the parts of the tutorial you had trouble with, if you remember?

packetlost
1 replies
5h4m

I'll see if I can go back and figure out where I lost track of things. I believe it was right around when making the message entry box functional. I ended up having to dig into the repo to see what I was missing.

jacobobryant
0 replies
30m

Good to know--I'll do another run through the tutorial sometime and see if I notice anything. I know there are a couple things I need to update in the example repo at least.

hi-v-rocknroll
2 replies
20h26m

Ah neat. But darn, I was kinda hoping for supporting tools and packages with names like tannen, delorean, doc, mcfly, and strickland ;)

ungamedplayer
0 replies
10h39m

I don't know if op had chance to evaluate because they were outatime.

zarathustreal
1 replies
21h41m

I love this so much. The power of being able to connect a repl to your production instance and fix bugs instantly is hard to understate. It’s actually kind of hard to explain to devs used to deployment cycles measured in weeks

fire_lake
0 replies
11h11m

How is the fix committed once you are done? Does this run counter to immutable deployments?

yogthos
2 replies
21h30m

The best part about Babashka is that it's really batteries included nowadays. I had to make a little UI to display some stats about an app at work, and decided to try using it with HTMX. Turned out to be a really good experience. Babashka has pretty much everything you need for a basic web app baked in, and HTMX lets you do dynamic loading on the page without having to bother with a Js frontend.

Best part is that bb can start nREPL with `bb --nrepl-server` and then you can connect an editor like Calva to it and develop the script interactively. Definitely recommend checking it out if you need to make a simple web UI. Here's an example of a full fledged web app:

    #!/usr/bin/env bb
    (require
     '[clojure.string :as str]
     '[org.httpkit.server :as srv]
     '[hiccup2.core :as hp]
     '[cheshire.core :as json]
     '[babashka.pods :as pods]
     '[clojure.java.io :as io]
     '[clojure.edn :as edn])
    (import '[java.net URLDecoder])

    (pods/load-pod 'org.babashka/postgresql "0.1.0")
    (require '[pod.babashka.postgresql :as pg])

    (defonce server (atom nil))
    (defonce conn (atom nil))

    (def favicon "data:image/x-icon;base64,AAABAAEAEBAAAAAAAABoBQAAFgAAACgAAAAQAAAAIAAAAAEACAAAAAAAAAEAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//AAD8fwAA/H8AAPxjAAD/4wAA/+MAAMY/AADGPwAAxjEAAP/xAAD/8QAA4x8AAOMfAADjHwAA//8AAP//AAA=")

    (defn list-accounts [{:keys [from to]}]
      (pg/execute! @conn
                   ["select account_id, created_at
                     from accounts
                     where created_at between to_date(?, 'yyyy-mm-dd') and to_date(?, 'yyyy-mm-dd')"
                    from to]))

    (defn list-all-accounts [_req]
      (json/encode {:accounts (pg/execute! @conn ["select account_id, created_at from accounts"])}))

    (defn parse-body [{:keys [body]}]
      (reduce
       (fn [params param]
         (let [[k v] (str/split param #"=")]
           (assoc params (keyword k) (URLDecoder/decode v))))
       {}
       (-> body slurp (str/split #"&"))))

    (defn render [html]
      (str (hp/html html)))

    (defn render-accounts [request]
      (let [params (parse-body request)
            accounts (list-accounts params)]
        [:table.table {:id "accounts"}
         [:thead
          [:tr [:th "account id"] [:th "created at"]]]
         [:tbody
          (for [{:accounts/keys [account_id created_at]} accounts]
            [:tr [:td account_id] [:td (str created_at)]])]]))

    (defn date-str [date]
      (let [fmt (java.text.SimpleDateFormat. "yyyy-MM-dd")]
        (.format fmt date)))

    (defn account-stats []
      [:section.hero
       [:div.hero-body
        [:div.container
         [:div.columns
          [:div.column
           [:form.box
            {:hx-post "/accounts-in-range"
             :hx-target "#accounts"
             :hx-swap "outerHTML"}
            [:h1.title "Accounts"]
            [:div.field
             [:label.label {:for "from"} [:b "from "]]
             [:input.control {:type "date" :id "from" :name "from" :value (date-str (java.util.Date.))}]]
    
            [:div.field
             [:label.label {:for "to"} [:b " to "]]
             [:input.control {:type "date" :id "to" :name "to" :value (date-str (java.util.Date.))}]]
    
            [:button.button {:type "submit"} "list accounts"]]
           [:div.box [:table.table {:id "accounts"}]]]]]]])
    
    (defn home-page [_req]
      (render
       [:html
        [:head
         [:link {:href favicon :rel "icon" :type "image/x-icon"}]
         [:meta {:charset "UTF-8"}]
         [:title "Account Stats"]
         [:link {:href "https://cdn.jsdelivr.net/npm/bulma@1.0.0/css/bulma.min.css" :rel "stylesheet"}]
         [:link {:href "https://unpkg.com/todomvc-app-css@2.4.1/index.css" :rel "stylesheet"}]
         [:script {:src "https://unpkg.com/htmx.org@1.5.0/dist/htmx.min.js" :defer true}]
         [:script {:src "https://unpkg.com/hyperscript.org@0.8.1/dist/_hyperscript.min.js" :defer true}]]
        [:body
         (account-stats)]]))

    (defn handler [{:keys [uri request-method] :as req}]
      (condp = [request-method uri]
        [:get "/"]
        {:body (home-page req)
         :headers {"Content-Type" "text/html charset=utf-8"}
         :status 200}

        [:get "/accounts.json"]
        {:body (list-all-accounts req)
         :headers {"Content-Type" "application/json; charset=utf-8"}
         :status 200}

        [:post "/accounts-in-range"]
        {:body (render (render-accounts req))
         :status 200}

        {:body (str "page " uri " not found")
         :status 404}))

    (defn read-config []
      (if (.exists (io/file "config.edn"))
        (edn/read-string (slurp "config.edn"))
        {:port 3001
         :db {:dbtype   "postgresql"
              :host     "localhost"
              :dbname   "postgres"
              :user     "postgres"
              :password "postgres"
              :port     5432}}))
    
    (defn run []
      (let [{:keys [port db]} (read-config)]
        (reset! conn db)
        (when-let [server @server]
          (server))
        (reset! server
                (srv/run-server #(handler %) {:port port}))
        (println "started on port:" port)))

    ;; ensures process doesn't exit when running from command line
    (when (= "start" (first *command-line-args*))
      (run)
      @(promise))

    (comment
      ;; restart server 
      (do
        (when-let [instance @server] (instance))
        (reset! server nil)
        (run)))

neilyio
1 replies
21h23m

I agree. It's a breath of fresh air in the Clojure world. I'm grateful to thoughtful builders like yourself and borkdude for bringing the language to new heights.

yogthos
0 replies
19h43m

Babashka is definitely the most exciting thing currently happening in Clojure world in my opinion. And thanks, always great to hear my stuff ends up being useful. :)

hombre_fatal
12 replies
1d

Maybe online "learn lisp" repls should implement paredit keybindings in their editor and have a short section on how to manipulate s-expressions. Because you're gonna have to learn it to use the language, but it also helps people understand from the start that "oh, so using the language isn't actually complete shit".

Instead, this fact always seems glossed over, and because of it anyone who spends 60 seconds writing lisp by hand into a repl assumes that's the lisp experience and nopes out forever. When in fact paredit makes lisps the easiest-to-edit languages in the world.

askonomm
5 replies
23h55m

Or Parinfer. I personally like Parinfer more than Paredit, mainly because I can't be arsed to learn a gazillion keyboard shortcuts.

hombre_fatal
4 replies
23h53m

Oh, interesting. Yeah, that's even better for an onboarding tutorial. I didn't know it existed (used Clojure for 6 years a long time ago).

Cool: https://shaunlebron.github.io/parinfer/

I always thought that the surrounding tooling (having to learn how to edit parens productively, using nrepl/cider, maybe even emacs... with evil-mode of course) to be both the worst and then eventually the best parts of Clojure.

askonomm
3 replies
23h49m

I'm one of those mainstream devs (who also did Clojure for 6 years, coincidentally) who never got into emacs, and always just used the Cursive IDE plugin for IntelliJ and its Parinfer editing mode. I know I probably didn't unlock true god mode of productivity, but it worked fine for me.

hombre_fatal
1 replies
23h30m

I had already used vim by the time I found clojure during uni (back when I had the energy to learn major new things), but vim support sucked for things like evaluating code blocks in the buffer, so I tried emacs and immediately slapped on evil-mode (vim bindings inside emacs).

For those six years I don't think I used emacs keybindings during that time except to move between files and execute clojure code. I couldn't be arsed to learn it. It was basically a fancier vim, haha.

These days I use VSCode for all software. At some point in my 20s I found out there's life outside of coding so now I use a less esoteric editor. I'm sure its clojure / nrepl / paredit / parinfer support is fine. (Seems to be this: https://calva.io/) Back in 2010 the options weren't as great.

stefcoetzee
0 replies
19h25m

Yup, Calva's pretty great.

simongray
0 replies
11h34m

I'm the same, always just used parinfer with IntelliJ, though I do know a few paredit key combos that I use occasionally (paredit isn't disabled just because parinfer is enabled).

globular-toast
1 replies
23h53m

At the very least they should have auto-closing and matching parens. I dread to think how many people have been put off Lisp because they think we actually type all those parens (in fact Lisp users have enjoyed IDE features many programmers could only dream of for decades).

anentropic
0 replies
6h35m

I remember trying Clojure a few years ago, and Racket, and had similar problem with both... feels like everybody doing LISPs is using Emacs and it was hard to get a decent set up in VS Code configured and working properly

writeslowly
0 replies
23h17m

I spent a few months writing a decent sized Clojure program just using my IDE's matching bracket highlighting and some sort of rainbow parentheses settings, and never found it very annoying. I'm not sure there are that many more parentheses than curly-bracket languages, it's just that all of the closing parentheses are more likely to cluster together at the end.

silcoon
0 replies
20h51m

TryClojure author here. Thanks for the suggestions! I’ll look into adding parinfer soon and maybe add a section on the benefits of integrating Clojure with the editor.

neilyio
0 replies
21h7m

I use Helix [0] myself, which has tree-sitter based commands for moving + selecting up/down/forward/back by expressions. These are built-in and require no configuration.

It's surprisingly excellent! Sure, the "language" of paredit features more powerful text manipulation that just simple movement... but combined with the new "jumping" in the latest Helix release [1], it makes for a very impressive keyboard-based navigation system.

[0]: https://helix-editor.com [1]: https://helix-editor.com/news/release-24-03-highlights/

jwr
0 replies
21h48m

When in fact paredit makes lisps the easiest-to-edit languages in the world

That is true and whenever I switch from Clojure to C, I immediately feel the pain (what do you mean I can't just kill or lift this entire expression?).

But structured editing has a learning curve, so it's a difficult balancing game. Beginners are overwhelmed by all the parentheses, while experienced programmers don't even notice them and love the structured editing approach.

talkingtab
11 replies
22h44m

I know many people will have problems with this post, but I am posting as information for clorjure-ophiles. Not reasons, but personal reasons why I don't do Clojure and will not try it.

1. When I read about Clojure (repeatedly) I like it. I am especially interested in transducers. I even built a half baked transducer engine in JavaScript using generators. There is clearly something here of value here. Any system that can produce transducers is worth learning.

2. I spent too many years of my life on Java. It was okay until someone wrote a thing in php (!!) in a day that would be have taken at least a month in Java. Maybe two. I understand the "good" of Java, but for me personally, the cost of that good is just incredible tedium. This is personal and I understand that.

3. However, as soon as I get to the part of installing Clojure where you install a JVM, I start hearing voices that say "It ain't me babe" and "Just say no to Java". PTSD?

For a while there was Clojure-script and I started working with that, but it seemed to fall off the edge of the world.

I will happily try Clojure again if it will compile itself or if it does not require the installation of a JVM. [ And last but not least of irrational reactions- anything associated with Oracle is to be avoided like the plague. sorry]

[Edit: then I saw the stuff about Babashka so I will give that a try]

jwr
3 replies
21h50m

Running on the JVM is one of the best things about Clojure. The JVM is an impressive piece of engineering where uncounted bajillions of man-hours were invested into making a good and performant VM with modern GC.

I've been using Clojure heavily for the last 9 years or so and I can't see any reasons to dislike the JVM. Also, I barely ever touch any Java. You don't need to.

owenmarshall
1 replies
20h45m

And if you do need to touch Java for reasons Clojure doesn’t impose, the interoperability story is really good.

I’ve done this with internal libraries - it’s easy to get them pulled into a Clojure code base, wrap them in such a way that the ergonomics of the rest of your code aren’t ruined, and still treat them as a first class citizen for stuff like your build system, artifact stores, etc.

puredanger
0 replies
20h37m

Clojure 1.12 (which is nearly done) is going to add a bunch of interop support - method values, array class syntax, Clojure fn -> Java functional interface conversion, stream support, etc.

delegate
0 replies
19h51m

I can hardly write a correct Hello World in Java. I can read it, I can probably write it, but I've never really used it. Yet I've been writing Clojure daily for the last 9 years.

This means that you really don't need Java in order to use Clojure.

Coming from a C++ background, I used to dislike the JVM out of principle just like yourself, especially since it needs to run on my local machine and it uses so much memory and is slow to start up.

However, once your app is started, you're in the REPL and that's the only time you need to start your app.. You can keep developing for days without restarting your app once.

Once I finished developing my app and I deploy it to a server, I'm kind of happy it runs on the JVM - that thing is super tuned, very fast and runs on a myriad of hardware platforms.. I don't have to spend one minute thinking about those details.

So while the JVM is somewhat inconvenient on the dev machine, it helps a lot when you deploy it to production.

Things became a lot simpler when I stopped worrying about it and just used the language for its power and beauty.

default-kramer
2 replies
22h37m

It was okay until someone wrote a thing in php (!!) in a day that would be have taken at least a month in Java. Maybe two. I understand the "good" of Java, but for me personally, the cost of that good is just incredible tedium. This is personal and I understand that.

You understand that this has everything to do with Java and nothing to do with the JVM, right?

vips7L
0 replies
22h11m

It's everything to do with the libraries people pick and not Java the language. Java the language can be extremely concise and expressive. Stop picking Spring and Java becomes fun again.

collyw
0 replies
22h9m

PHP avoids many of the hassles of deployment that pretty much any other language does.

whalesalad
0 replies
21h26m

I also cannot stand Java (not the technology, but everything surrounding it - bean factories, J2EE, Tomcat, war files, maven, insane unhinged class paths etc) but honestly one of the reasons Clojure is amazing is that it allows you to exist inside of the Java ecosystem while also being pretty isolated and walled off from it. It's all the good parts of Java without all the bad annoying parts.

I would urge you to push thru the PTSD and give it another shot.

There is also Clojurescript, which runs on Javascript, and Babashka which is a lighter weight implementation of Clojure for fast startup times that is targeted at things like shell scripts or system programs. https://babashka.org/

petersellers
0 replies
22h11m

I spent too many years of my life on Java. It was okay until someone wrote a thing in php (!!) in a day that would be have taken at least a month in Java. Maybe two.

Really curious to hear what that was, because I'm having a hard time believing that is true.

iLemming
0 replies
15h34m

Slowly repeat after me... "Java and JVM are not the same thing." Do it ten times every morning.. jk. JVM always gets a bad rap because of Java. Matter of fact, JVM is an incredibly good piece of tech.

tastyminerals2
10 replies
21h8m

I have to admit, several years ago, a colleague of mine advised me if not to try Clojure but at least to read the "History of Clojure": https://dl.acm.org/doi/pdf/10.1145/3386321, which I never did. But one day I decided to watch Rich Hickey - Greatest Hits https://changelog.com/posts/rich-hickeys-greatest-hits... I then read the "History of Clojure", and then jumped into learning it. This is probably one of the most fun languages to build with and one of the most beautiful ones. If not syntax-wise, rather in a way it allows you to express your thoughts via good design and composition that so nicely tickles your brain. If you are still searching for that one shiny tool, and none of them clicks, maybe try Clojure. It's one of the most concise and yet powerful languages I've seen.

ryan-duve
9 replies
20h47m

I got what you described by learning Common Lisp just a few months ago. Do you think learning Clojure would get me something in addition to that or is it roughly the same?

didibus
2 replies
13h54m

Clojure also teaches you functional programming, where-as CL only teaches you the LISP beauty. Clojure teaches you both Lisp and Fp. So the FP part should still be worth it even though you got the Lisp part from CL.

mikedelago
1 replies
3h59m

How does fp in clojure differ from fp on common lisp?

Verdex
0 replies
3h26m

Clojure has immutability built into the language and the core data structures are all persistent so that you can get sufficiently efficient partial updates while still preserving a pure FP style.

Furthermore, the data structures in clojure also have interfaces that make it easier to swap out which data structure you're using while still keeping whatever map/filter/reduce algorithm implementation you're sending it through.

Common lisp, on the other hand, has setf. Which more or lets you mutate anything. You certainly can code in an FP style in common lisp, but it doesn't restrict you in any meaningful way. Not a problem if you control the entire codebase, but when gluing components together this can be a source of friction.

tmountain
0 replies
20h40m

Depends on your style of programming CL. Clojure is immutable by default with a heavy emphasis on concurrency and strong ties to the JVM as its host environment. The differences you’ll find mostly lie in those areas.

rtpg
0 replies
17h19m

I think Clojure leans into immutability a lot, and that leads to more interesting APIs and norms that are valuable. CL has always felt a bit more.... "running on a machine" that I feel has less of a place in an era where everyone and their dog has functional programming essentials built in.

Clojure is interesting, but some Clojure APIs (stuff like Spectre) is "I want this everywhere now" stuff.

iLemming
0 replies
15h39m

Do you think learning Clojure would get me something in addition to that

For me, the biggest benefit is that it's hosted. Learning only Clojure, I can easily today write for JVM, .NET, JavaScript, Flutter, or shell scripts. Even when I need to write Lua, I'd usually pick Fennel. It's not Clojure but feels very similar. There are libs that can give you Python or R interop from Clojure. There are projects to target Golang, Rust or Erlang. Jank is a super interesting, experimental implementation of Clojure that runs on LLVM, I'm very excited about it. Do you want to become a true polyglot programmer? You only need to learn Clojure.

epgui
0 replies
19h41m

IMO, Clojure is superficially/syntactically much more elegant and beautiful than Common Lisp or Scheme. I find this really helps you focus on what matters most.

parhamn
10 replies
23h7m

(+ 1 2 '(1 2))

"3(1 2)"

Yup, I'm out.

bunderbunder
2 replies
23h2m

Fair. I don't mind dynamic typing so much, but I agree that getting clever with automatic type conversion is just plain wat.

(reference to: https://www.destroyallsoftware.com/talks/wat)

systems
1 replies
22h57m

I wouldnt call that getting clever, its just a string of what you did

  > (type (+ 1 2 '(1 2)))
    #object[String]

bunderbunder
0 replies
22h45m

The problem is how you get there.

1 and 2 are integers. '(1 2) is a list. None of them are strings, but + helpfully converts them to strings because ClojureScript is leaking some of JavaScript's wat behavior.

ARandomerDude
2 replies
23h1m

That's because this is actually ClojureScript (JS under the hood) running as a browser library.

If you try that in Clojure, you'll get:

ClassCastException class clojure.lang.PersistentList cannot be cast to class java.lang.Number

If you try it in a "proper" ClojureScript dev environment (shadow-cljs), you get nil as a result with this warning:

cljs.core/+, all arguments must be numbers, got [number cljs.core/IList] instead
parhamn
1 replies
22h54m

Thats actually good to know, I thought this was reflective of Clojure itself.

yladiz
0 replies
19h47m

In a way it is, since Clojure typically both compiles but doesn’t really hide its connection to either Java or JS, so you can’t ignore the underlying target language.

TacticalCoder
1 replies
22h44m

That's JavaScript for you. Here's a talk about the (in)sanity of JS:

https://youtu.be/et8xNAc2ic8

The same under Clojure (on top of the JVM) shall throw a class cast exception.

monsieurbanana
0 replies
22h56m

Clojurescript compiles to Javascript and so inherits some of it's idiosyncrasies.

This is one of the real problems of clojure: you need some knowledge of the host language. It's also one of it's major strengths, and the only reason a lisp managed to get so much (relative) commercial traction.

gleenn
0 replies
23h0m

That has more to do with Javascript being weird than Clojurescript. That would almost certainly throw a good exception when using Clojure / Java.

phendrenad2
7 replies
22h40m

Is there a version of Clojure that compiles to LLVM or something? Sort of like what Scala-native was supposed to be (but never materialized). I like functional programming but I can't abide the Java ecosystem in 2024, it's just too archaic for my taste.

lgrapenthin
1 replies
20h47m

Do they have a realistic shot at implementing immutable datastructures?

baq
1 replies
22h23m

the top comment as of writing this reply points to https://babashka.org/, but it's GraalVM instead of LLVM (which shouldn't really bother you)

kolme
0 replies
21h1m

Babashka scripts are interpreted, the babashka binary itself is compiled with GraalVM.

But: you can also build regular Clojure programs using GraalVM and create a fast-starting binary.

jomendoz
0 replies
19h57m

There's an ongoing effort to create a Clang/LLVM implementation of Clojure's runtime with hot reloading and other very interesting features. You can take a look at it at https://jank-lang.org/. It still hasn't reached feature parity with full blown JVM Clojure but we've paying close attention to its development.

createaccount99
7 replies
12h43m

The problem I see with clojure, isn't it missing autocompletes? You work with JVM/typescript libraries, but your editor isn't smart enough to pull types from those into clojure. That slows you down tremendously.

ilikehurdles
2 replies
12h26m

No. When working with JVM/typescript libraries you have their autocomplete information.

If you need method autocomplete scoped to a type you can use the `..` macro for more concise call syntax:

    (ns my-project.core
      (:import (java.util ArrayList Collections)))

    (defn example []
      (let [list (ArrayList.)]    ; ArrayList constructor can be autocompleted
        (.. list
            (add "Hello")         ; The .add method on ArrayLists will be autocompleted
            (add "World")
            (add "Clojure"))
        (Collections/sort list)   ; The Collections.sort method will be autocompleted
        list))

this other form will a also autocomplete everything after the dot (.) to call a method on an object:

    (.toUpperCase some-str)
but the trick with this arrangement is to write that variable some-str first, then if you write . in front of it the autocompletes will be relevant to that object. But I gratuitously used threading macros like .. or -> to make it match java-style code (in other words: (-> some-str (.toUpperCase))).

createaccount99
1 replies
12h5m

That's cool, I had no idea. In clojure itself I suppose you eval code and then get autocompeletes from the repl output? -- I mean for stuff with no types

simongray
0 replies
11h36m

Autocomplete also works for the functions and vars in the namespaces. You don't really use methods in Clojure unless you're doing interop with Java or JS.

cospaia
1 replies
11h30m

As a Clojure editor tool smith it pains me that this is the case. Especially for ClojureScript where I spend most of my time. I really want to fix this.

For JVM interop, I think Cursive (IntelliJ Clojure plugin) is smart enough to help with autocompleting Java libraries.

sswezey
0 replies
6h57m

Yea, Cursive is the best by far for doing Java interop. It is really good.

ziftface
0 replies
11h39m

Autocomplete works for me with jvm imports

FredrikMeyer
0 replies
12h14m

I use Emacs with Cider+clojure-lsp, and the autocomplete/refactoring tools are super good.

DeathArrow
7 replies
10h4m

I wonder why no functional language has the degree of success imperative or OOP languages have.

Is functional programming too weird for majority of computer programmers? Is functional programming not optimal for solving industry problems? Maybe there is no functional programming that that is up to some set of standards? Is functional programming too complicated?

I do enjoy functional programming myself, and while I don't use a functional programming language at work, I try to use functional programming paradigms when I finds it suits the probem.

cageface
5 replies
9h56m

Functional programming languages haven't gone mainstream but functional techniques are very common now.

Higher order functions, immutable data structures, declarative UI frameworks, etc are things you're quite likely to encounter in a contemporary codebase these days.

DeathArrow
4 replies
9h39m

That's what I said. I do use functional programming techniques, I just wonder why functional programming languages don't see a larger following.

cageface
1 replies
7h4m

Good question. I suspect it's because the downsides of losing the larger ecosystem of more mainstream languages outweigh the upsides of a functional language. The libraries, package managers, tooling, runtime, debuggers, documentation, and editors etc just aren't anywhere near as mature for Haskell or Ocaml as they are for Typescript or Python, for example.

nequo
0 replies
2h44m

Debugging is a known sore point with OCaml for example. But what is the problem with the Haskell RTS or the OCaml runtime? Why is it not “anywhere as mature” as Python’s or something like Node for JS?

Python’s had the GIL while Haskell has had a well functioning parallelized runtime for a long time. And both Haskell and OCaml’s runtimes outperform Python’s and are on par with Node.[1]

As for documentation, every time I come back to Hoogle,[2] I remember how I miss it in other languages that just don’t have anything similar going. The lack of types doesn’t help, and reading the documentation of the Python standard library or a popular library like torch is sometimes like solving a puzzle because it’s unclear what a function or a class constructor really does or even what class’ instance it returns.

[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/... for CPU usage but their memory usage is comparable too, and OCaml’s benefits from the language’s eagerness.

[2] https://hoogle.haskell.org/

tankorsmash
0 replies
5h14m

I didn't get anything close to that from your original message. I thought you meant "I write functional JS, but am wondering why a language like clojure or OCaml isn't more popular"

freilanzer
0 replies
6h6m

Inertia of languages like Java, C, C++, C#, etc. due to university and existing projects. Also managers wanting a huge recruiting pool.

dgb23
0 replies
9h31m

There are degrees and different shades of "success" and "functional programming".

Clojure is successful, stable and well maintained. However it is a niche language compared the big mainstream languages. It takes a functional approach by default, but doesn't shy away from other paradigms/patterns/idioms when appropriate.

Functional programming itself has had a huge influence on mainstream languages since about a decade and a half. More and more pragmatic features have been introduced in mainstream languages. Newer languages have adopted functional idioms from the get go. On the macro level as well, ops and architecture have been adopting statelessness, reproducibility and so on.

The consensus has shifted towards containing state. The more moving parts you have, the harder it gets to reason about a whole thing. Treating data as data.

OOP has also changed and got refined over this time. I think people realized that it has good ideas (generic interfaces, polymorphism etc.) and bad ideas (inheritance, local state etc.). Same thing with FP, there's stuff that's esoteric and too far from the reality of actual programming and stuff that is pragmatic and simplifying in there.

tmtvl
6 replies
20h43m

So here's something which I, as a Lisper, don't understand: Clojure has syntax for hash tables (the curly braces), why doesn't it use those for let-bindings, instead choosing to use vector syntax? (Of course I prefer standard Lisp syntax which can easily be extended for multiple-value and destructuring bindings:

  (let ((a 1)
        ((b c) (list 2 3))
        (d e (values 4 5)))
    `#(,a ,b ,c ,d ,e))
  ;; => #(1 2 3 4 5)

puredanger
2 replies
20h39m

Maps are unordered, but let bindings are sequential so order matters.

tmtvl
0 replies
9h5m

I see, so Clojure's let works like Lisp's let*. I didn't know that, thanks for the explanation!

joshlemer
0 replies
19h29m

And also, a variable can be rebound in later bindings!

didibus
1 replies
13h27m

What's so different to Clojure's ?

    (let [a 1
          [b c] (list 2 3)
          [d e] [4 5]]
      `(~a ~b ~c ~d ~e))
    ;; => (1 2 3 4 5)

tmtvl
0 replies
9h6m

But what would be the equivalent of:

  (let ((quotient remainder (floor x y)))
    (+ (* quotient z)
       (* remainder (floor z y))))
Where floor is a function which returns multiple values rather than a list or vector of results?

Also, but this is entirely on me being an absolute dullard, I like having the brackets around each binding as a kind of guardrails for my mind to not lose track of where I am and what belongs where.

phforms
1 replies
8h30m

Reagent is nice and has been around for about a decade now, but I moved away from it towards very thin wrappers around React[1], because I felt like it was adding too much additional complexity on top of React, which is already quite complex on its own. I wanted a clearer view at what is going on and a simpler way to interop with native React components.

Although it seems to catch up with experimental support of React 18 now, Reagent has fallen behind the latest developments in React and may not benefit from all of its performance optimizations. It is still using class components instead of hooks and there have been concerns that the runtime conversion of Hiccup may drag down performance. I guess in most cases it is not really an issue or in any way noticable, so if you’re not doing any fancy stuff it should be fine. I may even come back to Reagent at some point, since I have to admit that I miss the UI-as-data model with Hiccup.

What I highly recommend, however, is using re-frame[2] for state management. It has also been around for a long time (2014, around the same time Reagent came along) and pioneered some popular ideas in that area. It may seem a bit overwhelming at first, but the docs provide a great introduction and I find the model very clear once you wrap your head around it. At the moment it depends on Reagent, but there are ways around that. [3]

[1]: see Helix (https://github.com/lilactown/helix) or UIx (https://github.com/pitch-io/uix)

[2]: https://day8.github.io/re-frame/

[3]: refx (https://github.com/ferdinand-beyer/refx) is an almost drop-in replacement without the Reagent dependency, but hasn’t been updated in a while. Alternatively, re-frame can be integrated with UIx/Helix by adding some interop code https://github.com/pitch-io/uix/blob/master/docs/interop-wit...

nathants
0 replies
8h23m

you think reagent is more complex?

i don’t even know what the difference between hooks and classes are, reagent has never given me a reason to care.

if that’s not simplicity, i don’t know what is.

if i were to build a 3d high performance game in react, maybe i’d experiment with dropping reagent. instead i’d just use cpp.

not sure why people want yelp complexity websites to be 3d games.

i love react! i absolutely do not care about the details. never have…

createaccount99
1 replies
12h8m

Does your setup do code splitting, SSG? I can't really be shipping a blank html file in 2024, destroys SEO. Otherwise am interested in trying.

nathants
0 replies
12h1m

no, i’m not interested in seo.

this setup is a single go binary that serves a single pre-gzipped html file from a lambda.

that html file contains inlined js, that is a reagent app.

there is also a favicon. total of 3 files in the lambda zip.

you desired setup is certainly possible though. you’d probably want clojure on the backend though, so you could more easily do SSG.

jarl-ragnar
0 replies
12h34m

Completely agree. Though I’ve also found an Elixir backend works well because of the power of the Beam VM.

masspro
5 replies
23h13m

<hot-take type="anecdata"> My Clojure experience was that basic dev experience things were shockingly behind where any other moderately popular lang is at. It's been some time though so all I remember clearly is bad error output. Stack traces are hard to read unless you install $random_lib. But worse than stack traces are type errors/"Java errors": if you give the wrong args to a function, the error output is completely inscrutable, generally a very short string like `java.lang.Foo does not implement IBar`, which is only helpful if you kind of know how the Java layer works and all your args are different enough types that you can guess which one it's talking about (bonus: anything function-like is just `IFn` so good luck). Ahhh and that made me remember: the doc situation even for stdlib is bad. Everyone around me used a third-party site clojuredocs.org which has broken-formatted auto-ingested versions of the plaintext official doc strings, because it is still the least bad option. No one has decided on a docstring format. No one has decided on code stylistic things either, which has mostly precluded the existence of auto-formatter tools.

The lang itself is good and I recommend folks use a LISP sometime. I was just genuinely surprised a 17-year-old lang was lacking in these areas, and I'd be pretty careful about setting out on a long-term project with it, unless all of those things have radically improved from 6 months ago.

(And like other folks said, you genuinely need editor integrations to not be wasting all your time on pren balancing. Not clj's fault, just LISPs in general.)

joshlemer
3 replies
19h13m

Along the same lines with the docs, I also find it frustrating that a lot of the very most core basic abstractions and interfaces are left totally undefined in terms of documentation. Take `ISeq`'s definition. Surely, a candidate for the single most core interface.

https://github.com/clojure/clojure/blob/master/src/jvm/cloju...

But like, where is the javadoc? What exactly is supposed to be the contract of these methods `first`, `next`, `more`, `cons`? What's the difference between `next` and `more`?

I really just don't like that. Are we just supposed to pick up the core contracts/abstractions through oral teachings and slack channel messages?

puredanger
2 replies
15h2m

You don’t use the ISeq interface directly, you use them through the clojure.core API. The seq abstraction is documented at https://clojure.org/reference/sequences

joshlemer
1 replies
12h31m

It’s rare for an application developer to need to use ISeq, but library authors do use of when they want to implement custom seq’s right? For them, and also just for those curious to understand how the core interfaces work, it’s still better to be explicit and write what the contract is I reckon.

puredanger
0 replies
5h18m

Generally, custom seqs (rare) are implemented by leveraging something like `lazy-seq`, so library authors are also not using it.

Yes, it would be good if there were javadoc on more of the impl, but this is just not an issue for the vast majority of devs.

neilyio
0 replies
22h39m

I'm an advocate for Clojure, and while I believe that the usability speed bumps are more than made up for, I completely agree with you. The awkwardness of Clojure's errors, REPL experience, and build tooling is a dealbreaker for many.

A couple years with Rust has taught me that intuitive errors and tooling will funnel you far enough into language to get you productive, and then you're much more likely to stay. There's just no way I would have stayed long enough to be a Rust professional if it hadn't been for cargo and rust-analyzer.

These "non-language" components of Clojure are just not easy enough to use, and its inhibited Clojure's growth. If, however, you do put in the time to grok these parts, the joy of using the language itself never fades.

alabhyajindal
4 replies
2h50m

Isn't it tiring to type so many parenthesis all the time? This is probably my first time encountering a Lispy language, other than Logo.

puredanger
1 replies
1h52m

The number of parentheses is the same, they're just in a different place. Isn't it tiring to type so many semi-colons and commas all the time?

alabhyajindal
0 replies
1h45m

I think it's tiring because before every expression I have to type a (. It's not tiring to type semi-colors and commas because they are very well positioned on the keyboard and I don't have to reach out in the same way as I need to for the parenthesis.

Plus, there are not a lot of semi-colons and commas in JS and Python.

phforms
1 replies
1h43m

I know a lot of people think that you write more parentheses in Lispy languages, but actually in most cases you just type them in a different order, e.g. instead of `foo(x, y)` to call a function, you type `(foo x y)` and you even save a comma.

Of course, there are constructs such as `let` and `cond` that are more parenthetically noisy (not so much in Clojure though), but on the flip side you don’t have to remember a lot of special syntax like in non-lisp languages.

Most Lisp-people also use structural editing tools like paredit[1], which make it really easy to write and edit s-expressions. I found that after some time I didn’t really think that much about parentheses anymore.

[1]: https://paredit.org

alabhyajindal
0 replies
1h33m

You're right about the order part and I didn't consider it initially. This is what Fizzbuzz looks like in Clojure:

  (defn fizzbuzz [n]
    (cond
      (zero? (rem n 15)) "FizzBuzz"
      (zero? (rem n 3)) "Fizz"
      (zero? (rem n 5)) "Buzz"
      :else (str n)))

  (defn print-fizzbuzz [n]
    (doseq [i (range 1 (inc n))]
      (println (fizzbuzz i))))
This looks overwhelming for someone who hasn't written any Lisp. My thought looking at this code was that I have to type a parenthesis before formulating any thought. Which is crazy because it's not some huge thing. It's like saying I have to press Enter before writing a line of Python.

qnsoaejacniln
3 replies
22h29m

There is XSS in the (my-name) part :)

(my-name "<img src='#' onerror=alert(1) />")

didibus
1 replies
13h39m

Nice catch. Is it an issue though when the script injection only runs within your own browser session?

Jeaye
0 replies
1h46m

No. That in itself shouldn't be a cause for concern. Local users can do anything to their own machines already. It would be a concern if you persist this to then later be loaded by someono else's machine.

hpeter
0 replies
11h24m

It's not XSS if it's not cross-site.

stefcoetzee
0 replies
19h33m

Agreed. Perhaps using VSCode with the Calva plugin if the reader has no previous experience with Emacs.

rads
0 replies
12h36m

I think the writing style is too fluffy, but I realize some people like that. The true sin of this book is that it actually starts by teaching the reader Emacs, not Clojure. That's a huge distraction for a beginner who is probably coming from VSCode these days.

MetaWhirledPeas
3 replies
23h39m

I love it! But is there a back button or key or command? I'm flaky and I need to re-read things a lot.

disambiguation
1 replies
22h13m

(prev-step) ?

MetaWhirledPeas
0 replies
22h0m

Whoa, hacks! Thank you.

varjag
0 replies
23h15m

It should be trivial to add with all the promise of data immutability :)

mysore
2 replies
20h39m

i wish it was easy to make android apps with clojure. not sure if itd be easier with jetpack compose + clojure or react native + clojurescript.

prabhasp
0 replies
18h8m

There’s also clojuredart to do a dart / flutter app. I’ve been working on one, and it’s been pretty pleasant to work on.

jollyjerry
2 replies
23h3m

I still remember Professor Brian Harvey rolling out his terminal on a cart in Berkeley's CS61A and typing out commands in a scheme repl. Learning what a y-combinator was with Structure and Interpretation of Computer Programs, and building my own scheme compiler with scheme.

bhasi
1 replies
12h10m

Oh wow, I didn't know that "Y-Combinator" was not just a fancy name but was an actual computer science concept. Thanks!

jackbravo
2 replies
20h34m

Clojure is becoming popular in Mexico, and I'm guessing Brazil may see a similar situation, because of nubank. It is a popular destination to go work there for computer scientists, and they seem to work mostly in Clojure. I seem to remember they even employed some of the core members of the language? I think at some point they also bought the company of Jose Valim (Elixir's creator), but I think they are still mostly a Clojure shop.

zachromorp
0 replies
4h34m

I often encounter Clojure Chinese users (at least Chinese sounding names, don't know about their nationality). I wonder if Clojure is a thing in China ?

hlship
0 replies
18h37m

Nubank purchased Cognitect (the consulting company behind Clojure) in 2020, as well as Platformatec (employers of Jose Valim); the latter was for access to Platformatec's project management expertise (see https://building.nubank.com.br/tech-perspectives-behind-nuba... there is no Elixir code running at Nubank AFAIK.

There is Python on the "other side" of the ETL pipeline, but everything user-facing is (again AFAIK) Clojure on the backend and TypeScript in the Android and iOS apps.

camelspotter
2 replies
8h29m

this example shows how "elegant" closure treats syntax errors, almost looks like a bad joke.

=> (+ 2 2 + 3)

"4function Cg(a){switch(arguments.length){case 0:return Cg.s();case 1:return Cg.g(arguments[0]);case 2:return Cg.h(arguments[0],arguments[1]);default:for(var c=[],d=arguments.length,e=0;;)if(e<d)c.push(arguments[e]),e+=1;else break;return Cg.j(arguments[0],arguments[1],new gc(c.slice(2),0,null))}}3"

zakkor1
0 replies
8h20m

That's a bug in the JS interpreter they're running, not anything related to Clojure. Also, that's not a syntax error

silcoon
0 replies
8h14m

Not a syntax error. TryClojure is running on SCI which is a interpreter that uses a Babashka version for Clojurescript compiler, not Clojure JVM.

Babashka cli returns this, telling you clearly what the error is:

   user=> (+ 2 2 + 3)
   java.lang.ClassCastException: clojure.core$_PLUS_ cannot be cast to java.lang.Number [at <repl>:1:1]

BaculumMeumEst
2 replies
16h22m

Clojure is a really interesting and well designed language with bad error messages and bad official tooling. It feels very sloppy.

Compared to Go, it has a weak stdlib, is more memory intensive, and generally slower. You get beautifully concise code but it can be very hard to follow (or return to after time away).

Go can look completely idiotic or unbelievably focused and practical, depending on the light. It is painful to give up Clojure’s very strong selling points but I find alternatives to be more pragmatic.

hpeter
1 replies
10h4m

"weak stdlib": You can use the Java ecosystem, most of the things you need are there

"it can be very hard to follow": I agree, if you are not a lisp developer it's really hard, but if you develop clojure everyday, it's as easy as anything else.

The answer is usually clean code when it comes to clojure. Keep your functions small.

"more memory intensive, and generally slower": yep, the JVM is more memory intensive than Go. No surprise there and Clojure adds up on top of that. Startup times are pretty slow too. But compared to python it's still fast. Apples to oranges.

I would say Clojure and Go are both great languages that tackle different problems so it's not a fair comparison.

BaculumMeumEst
0 replies
8h26m

Having projects that make significant usage of interop feels kind of gross, but I guess that is an option yeah. Pig-latin java is probably less fun to write than Go.

Regarding difficulty reading code, I'm not talking about syntax, I'm talking about the fact that many libraries define their own DSLs and you _cannot understand what they are doing_ by reading the code, you have to dig into the library internals to make sense of how they actually work, particularly when documentation is lacking or outdated.

Many problems can be solved by either language, and I wish it was easier to justify reaching for Clojure.

spronket_news
1 replies
21h44m

this is super neat! how did you set up your fonts folder? what tooling did you use?

memothon
1 replies
19h7m

My favorite part of working in clojure is how easy it is to do common data structure operations.

map, filter and reduce are extraordinarily powerful, especially when combined with the other core library functions.

makach
1 replies
23h15m

That's a great introduction, but... how to do an if statement would've been cool to add in the tutorial.

613style
0 replies
23h2m

What is this "statement" you speak of?

(if (= 2 2) :OK :nope)

cageface
1 replies
18h39m

What's the recommended stack for doing front end development with clojure these days?

rads
0 replies
12h50m

Here is where I'd start for the path of least resistance while still using the most modern libraries:

- Dependency management: https://clojure.org/guides/deps_and_cli

- Clojure->JS compiler: https://github.com/thheller/shadow-cljs

- React integration: https://github.com/reagent-project/reagent

- Global state management (optional): https://github.com/day8/re-frame

You might also want a CSS framework. There are some options to write CSS in ClojureScript, but I prefer TailwindCSS which isn't a Clojure-specific thing and it works fine out-of-the-box with `.cljs` files.

You can swap out Reagent for Helix, which is a lower-level and faster wrapper for React. That said, Reagent does work with React 18 just fine and there's tons of docs for it, so jumping to Helix first is a premature optimization IMO, especially if you're new to Clojure.

android521
1 replies
14h25m

Clojure will get more adoption if they find a way to make it very easy to build cross platform mobile and web apps like React & React native. They need to keep adding libraries to make the eco-system bigger.

socksy
0 replies
21h57m

Another website in this vein is https://www.maria.cloud/ which is more geared up for teaching complete beginners programming, but I think with the basic paredit style controls and the evaluate-each-form-at-a-time style is I think a lot more realistic to the kind of REPL driven development that you actually use — typing directly into the REPL terminal window is very unergonomic imo. You’re much more likely to use something like VSCode’s Calva or emacs’ cider to send the form under the cursor to a REPL process somewhere.

okasaki
0 replies
21h13m

I was hoping it would be longer, like the tour of golang.

As is it basically just shows you how to do arithmetic, which isn't interesting at all.

munirusman
0 replies
23h13m

Shameless plug: If you’re looking for an online compiler specifically designed for conducting interviews in Clojure, you might find [0] very useful. It’s designed to streamline coding interviews with real-time collaboration features.

[0] https://codeinterview.io/languages/clojure

mariogintili
0 replies
13h22m

the Scicloj stack https://scicloj.github.io/

in my opinion competes with python when it comes to DS/ML. I find it a lot more comfortable to use if you use emacs bindings

imzadi
0 replies
2h16m

I love Clojure. My dream is to be a clojure developer, but there aren't a lot of jobs available and everyone wants 87 years experience.

brabel
0 replies
21h52m

Does this end at "Apply functions on lists"?? For some reason I can't get past that!

Anduia
0 replies
23h12m

I found the red over gray combination a bit hard to read, so I checked it with a color contrast calculator:

The contrast ratio here is 3.9:1 (text #DC2626, background #E5E7EB), and the minimum recommended for small text is 4.5:1.

Sorry to be that guy :) I am enjoying the tutorial.