Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Clojure?

gaiwan.co

Post reply on HN
Print view View original

291–300 of 302 posts

Re: Why Clojure?

#291

Post by chamomeal »

xigoi wrote: post #200
hlship wrote: post #93

I've been working in Clojure now for about 12 years. Maybe 12+ years of Java prior to that. I've created some great apps, and great libraries (in both Clojure and Java). I often describe Clojure as "the least worst programming language", which is an off-handed complement, but I think accurate. Things you don't like can generally be fixed (at least locally) using macros and libraries. The core is strong, a good basis…

> Things you don't like can generally be fixed (at least locally) using macros and libraries. What macro do I use to make it not run on the JVM? :)

Babashka!

Re: Why Clojure?

#292

Post by chamomeal »

huahaiy wrote: post #111
eddd-ddde wrote: post #107

Earlier quoted context omitted.

How does the REPL approach scale in very large codebases? I.e. code that talks to multiple services, complex configurations, etc..

Scales very well. Immutable data pairs great with REPL. Because data are immutable, you don't need to care about where that data come from and where it will go. Just focus on what you need to do with that data at the point you work. Everything is localized due to immutability.

I’ve started learning clojure recently and I haven’t quite grasped the REPL yet. I really like it, but so far the type of feedback it provides feels similar (and sometimes inferior to) a static type system. I mostly use it as a tool for answering “wait what data does this return?” And of course trying functions as I’m building them.

Are there any tricks or habits you learn with the REPL that go beyond what a static type system gives you?

Re: Why Clojure?

#293

Post by perrygeo »

hlship wrote: post #93

I've been working in Clojure now for about 12 years. Maybe 12+ years of Java prior to that. I've created some great apps, and great libraries (in both Clojure and Java). I often describe Clojure as "the least worst programming language", which is an off-handed complement, but I think accurate. Things you don't like can generally be fixed (at least locally) using macros and libraries. The core is strong, a good basis…

I picked up Clojure recently after a 10 year hiatus. My early complaints were around tooling - a Lisp-specific IDE felt all but required to get the benefits of the REPL and structural editing. And leiningen, god how I despise that tool.

With clojure-lsp, deps.edn, and more REPL tooling (conjure in neovim in my case), the situation is better now. I find myself reaching for Clojure for almost everything these days - from scripting to data crunching to quick web apps to database work. Clojure is an amazing tool once you grok it - closest thing to a super-power we can get.

> working "with" my code, molding it like clay

This the best description. Clojure feels very fun/interactive but simultaneously feels rock solid for production work. There is no gap between "notebook" and "prod". Zero compromises. Most other languages pick one or the other (Python - interactive but plagued by runtime errors, Rust - rock solid but clunky to iterate and experiment)

Re: Why Clojure?

#294

Post by panick21_ »

huahaiy wrote: post #109
newlisp wrote: post #81

Earlier quoted context omitted.

Datomic feels like a natural extension of Clojure for storing data—you get no impedance mismatch, you continue working with Clojure's data structures for storing, querying, and writing data instead of dealing with clunky query builders(or SQL strings), and you gain immutability. Sure, you can use any database you like, but then you're playing the same game as every other programming language, ultimately getting less…

Not really. Database is where immutability may not be a good fit, at least not all the time. In many use cases, database is where application state resides, hence a mutable database is a better fit. There are Datomic flavored database in the Clojure ecosystem that is specifically design to address this point, e.g. Datalevin.

Wow I didn't know about datalevin. There are a few Datomic like databases around by now, this one looks interesting. I have been following Datahike and XTDB.

Re: Why Clojure?

#295

Post by 392 »

masijo wrote: post #184
slowmovintarget wrote: post #31

Earlier quoted context omitted.

But have you seen flow ? I don't think it's stalled at all, and Nubank seems to have become an enabler to the ecosystem. I mean, Datomic is free to use! [core.async.flow]: https://github.com/clojure/core.async/commit/03b97e0b3e0ec32...

I really don't understand what flow is and what problem it solves. I've read the commit comments and some posts but I still don't get it.

I've poked around three of those links and still not found an accessible good reason. But I am excited to try this, having never used this language before. It rolls into the language a perfect abstraction for deterministically simulating software. See Antithesis's big promises for more. I'm curious to see if this model of flows can be ported to other languages.

Re: Why Clojure?

#296

Post by KingMob »

lukev wrote: post #290
KingMob wrote: post #136

Earlier quoted context omitted.

As someone who was equally deep (I worked with you and the Danes), I think a lot of that elitism isn't just about building software. It's a large part of why I've stepped back from clj these days.

love this... would love to discuss more (but not quite sure who you are)... hit me up via other channels?

Sent a DM on clojurians

Re: Why Clojure?

#297

Post by MarkMarine »

DeathArrow wrote: post #145
MarkMarine wrote: post #14

Learning clojure has improved all of my programming in every language. I’m in love with the simplicity and smallness of it. Rich said one of the reasons he built it was he was programming like this already (pure functions acting on data) but the languages he was using didn’t support it well. There is a lot to be learned and applied even if you can’t use clojure at work every day.

>Rich said one of the reasons he built it was he was programming like this already (pure functions acting on data) but the languages he was using didn’t support it well. But he could have been using F#, OCaml, Haskell. So it might not be just about pure functions and immutable data.

Rich has talked about all of this, it’s all on YouTube if you’re curious.

https://youtu.be/nD-QHbRWcoM?si=yneAgMhk6NjTf9ZU

The video I remember when he was describing the origin was on 480i, I’ll try to find it

Re: Why Clojure?

#298

Post by KingMob »

erichocean wrote: post #208
synthc wrote: post #204

Earlier quoted context omitted.

you get runtime errors with a long JVM stacktrace

If you paste into Claude, it will instantly tell you what's going on.

If the core team had ever addressed the decade of surveys showing that error messages/stacktraces were people's top complaints, you wouldn't need Claude.

Re: Why Clojure?

#299

Post by KingMob »

cutler wrote: post #286
cogman10 wrote: post #257

Earlier quoted context omitted.

> learning a Lisp also makes you a better coder It can do, but it also can make you a worse coder. Specifically in typed languages. One of the issues I've ran into with Clojure devs doing Java is that instead of relying on a type, they tend to want to write stuff like `Map >`. Even when the key sets in both maps are well known. This becomes worse when you mix that with Immutability. Immutability can be fine except wh…

Clojure data structures implement structural sharing which minimises copying overhead.

True, but persistent data structures are still 2x-4x slower than mutable structures on average.

Re: Why Clojure?

#300

Post by lucyjojo »

nogridbag wrote: post #237
hlship wrote: post #93

I've been working in Clojure now for about 12 years. Maybe 12+ years of Java prior to that. I've created some great apps, and great libraries (in both Clojure and Java). I often describe Clojure as "the least worst programming language", which is an off-handed complement, but I think accurate. Things you don't like can generally be fixed (at least locally) using macros and libraries. The core is strong, a good basis…

I gave Clojure a shot some years ago and even wrote an important tool used daily by all employees at our company in Clojure. The problem for me was maintenance. If I had to make any change to that code, I had to dive into the REPL just to understand it. Whereas with something like Java, even if something is poorly written and not documented, I can get at least a minimum understanding of the code just looking at the t…

maintained a few clojure code bases at my old company for 10+ years

i find core.spec did wonders for that problem.

also, i have a tendency to write a lot of in-code documentation, whichever language i use. so it probably helps too.

Post reply on HN