Live data from Hacker News

Why Clojure?

gaiwan.co

21–30 of 302 posts

Re: Why Clojure?

#21

Idk ... it feels Clojure stalled since Nubank bought Hickeys company. Worst thing: spec is still in alpha !! I put so much on this ... but nothing really happened since ... idk 8 years?

Call it “stalled” if you like, it’s stable and it’s pure joy. I can just get stuff done with Clojure. And things that may seem inactive, like that lib that you need that hasn’t had a commit in 8 years, turns out that it just works and doesn’t need to change. This is commonplace in Clojure.

Spec is still alpha and I’m not sure it will evolve more or if it’ll be something completely different. At least they’re not pushing you down the wrong path. Use/look at Malli instead of spec.

Re: Why Clojure?

#22
post #20
post #6

I tried clojure long time ago, honestly what made me give up is when I saw a java stacktrace in place of a proper error message when learning it. Also the repl was slow. The UX sucked, I wonder if they improved that

The repl isn't slow, what are you referring to?

Probably referring to startup time. Larger apps solve this with the “reloaded” type of workflow (https://www.cognitect.com/blog/2013/06/04/clojure-workflow-r...)

Re: Why Clojure?

#23

Idk ... it feels Clojure stalled since Nubank bought Hickeys company. Worst thing: spec is still in alpha !! I put so much on this ... but nothing really happened since ... idk 8 years?

Spec isn't really essential to Clojure, and most people use Malli nowadays which is very actively developed https://github.com/metosin/malli

I see the fact that there isn't much happening with the language as a positive myself. I want the core language to be small and stable. The big difference with Clojure and most languages is that it makes it far easier to implement new semantics in user space. It has a powerful macro system and new ideas can be expressed using libraries instead of having to be baked into the core language itself.

Most language grow through accretion as usage patterns change over time. New end up features end up getting bolted on to facilitate that, and the language keeps growing. The problem here is that the scope of things people have to know keeps growing as a result.

Meanwhile, Clojure managed to stay small and focused, while different kinds of ideas are expressed using libraries. When a new idea comes along people can just use a new library, and they don't have to learn about all the previous libraries that worked differently. I think this is a huge benefit from user perspective.

Re: Why Clojure?

#24
post #3

Because you want the type safety of lisp with the simplicity of the jvm /s

I've used Clojure for over a decade and the JVM has never been an issue. The only people I see complaining about the JVM are people who never actually worked with it. Meanwhile, there's zero evidence for the notion that static typing has any impact on code quality. https://danluu.com/empirical-pl/

Re: Why Clojure?

#25

I run a multi-million dollar business which I started with common lisp. I since moved away to go and then rust but I've been looking at clojure again lately. For a team that needs to get s** done and has more per employee productivity than Faang combined it's hard to beat the speed with which you can build things when you have the repl and interactive programming. The jvm while doesn't have great error messages is a…

You should give Gleam a shot. No REPL, but its simplicity, functional-ity and the BEAM lend themselves to the get-shit-done approach

Re: Why Clojure?

#26
post #5

Earlier quoted context omitted.

You are being snarky but I'll take immutability over types and interoperability and access to a vast and stable ecosystem over the simple and extremely limited and underperforming alternatives. Thanks for the segway. I also cannot understate the reasoning ease that comes with basically everything being a static, top-level function. Testing never requires mocks because you can redef any function anywhere trivially whe…

> I'll take immutability over types and interoperability OK. > Thanks for the segway. A segway is a motorized transport; a segue is a transition to a different topic. So this could be considered a type error, and demonstrates why you need types, not just immutability.

While amusing, I still disagree.

Complex static type syntax ends up infecting your code, because the syntax becomes load-bearing. A change to one type has a tendency to ripple through the entire body of code. This means you have tight coupling as a consequence of the syntax, which is a bad trade-off. Clojure's strong dynamic abstract types allow you to focus on the function of the code instead of its structure. Trying things out in the REPL first helps you find many of the things that you might need to wait for a compiler to find.

There are studies that estimate that the kind of bugs shipped to production that strong static types help prevent account for only 2% of defects. The rest are things like off-by-one errors, design errors, and incorrect logic.

The other thing a static type system can help you with is reading code. But it's primarily an aid to people unfamiliar with the language, or put in more popular parlance a "skills issue." We know tooling can navigate the code, because we have tooling that does so (language servers, CIDER, Calva, Cursive, Conjure...). This means that static typing for the purpose of merely reading the code is a crutch. I'd argue it's also a crutch or training wheels for writing correct code.

You can't run with crutches. You can't corner well with training wheels. Clojure is meant to make the expert nimble and fast. The main thrust of its design is to make experienced devs more productive, like professional tools without novice guide-rails make experienced craftsman more productive.

Rich Hickey gave a talk where he mentioned this idea of guardrails on the highway. He told a story of how we all get in our car, then bump into guardrails all the way to our destination... right? Of course not, we learn to keep the car in our lane of travel, to signal others when we switch, and to blend with other traffic on the way. (Rich was talking about TDD, but it still applies to static type systems, IMHO.) Clojure is that power tool without all the novice presets. It's the automobile we keep away from the rails when we drive it.

Mutable state is arguably responsible for far more defects shipped than type errors. Mutability is only a thing because hardware constraints required reuse of memory locations instead of allowing for persistent data structures. Thankfully, for "situated" applications that start and operate for extended periods, those constraints aren't so tight.

If you have to choose between immutable data and static types choose immutable data. But why not both? We can have all our luxuries, right? Because you have to spend so much more time proving things to the compiler, you have so much more syntax to manage. More code and more syntax for the same problem is almost always worse. I'll take Clojure.

Re: Why Clojure?

#27
post #6

I tried clojure long time ago, honestly what made me give up is when I saw a java stacktrace in place of a proper error message when learning it. Also the repl was slow. The UX sucked, I wonder if they improved that

There are no Clojure stacktraces specifically, only JVM/Java ones. Clojure sits closely beside its host so there is no difference. People do complain about stacktraces and they've made some improvements. But they are long because the abstractions run deep and the function you passed in might be on the stack at the very bottom with the actual origination of the cause.

Re: Why Clojure?

#28
post #13

I run a multi-million dollar business which I started with common lisp. I since moved away to go and then rust but I've been looking at clojure again lately. For a team that needs to get s** done and has more per employee productivity than Faang combined it's hard to beat the speed with which you can build things when you have the repl and interactive programming. The jvm while doesn't have great error messages is a…

I feel like there’s a minimum developer quality that’s needed when using a language like Clojure, without static typing, and with a wealth of idioms and best practices that need to be followed and libraries that need to be known. Without it it’s a matter of time before the codebase can’t be developed anymore and the software doesn’t work as intended.

I would love to see how Clojure's "wealth of idioms and best practices that need to be followed and libraries that need to be known" compare to almost any other popular language. Clojure is by far the simplest most straightforward language I've ever used with very few details and gotcha's that need to be memorized.

Re: Why Clojure?

#29
post #17

Tried to love Clojure, but found it to opinionated as a daily driver for me. Sometimes I just need to get some code running to see a result, which is my main use case for Lisp. I used to default to Common Lisp, but it needs a lot of scaffolding to become ergonomic, and even then it has too many quirks to be really enjoyable for me. So I started designing my own: https://github.com/codr7/eli

What wall did you hit? I can jump into a Clojure REPL without needing a project or even any files.

Re: Why Clojure?

#30
post #6

I tried clojure long time ago, honestly what made me give up is when I saw a java stacktrace in place of a proper error message when learning it. Also the repl was slow. The UX sucked, I wonder if they improved that

I used to hate JVM stacktraces but they’re incredibly useful and I miss them when I’m using other ecosystems these days. The way JVM exceptions do “caused by” when an exception is thrown while handling another exception gives so much more information than other languages. It’s also relatively simple to filter out the noise when you want a concise error message: just remove lines that start with a tab.

CIDER (the emacs IDE for Clojure) does a really good job of filtering the stack trace and presenting several views depending on what you care about. L

Post reply on HN