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

Bringing Clojure programming to Enterprise (2021)

blogit.michelin.io

Post reply on HN
Print view View original

61–70 of 135 posts

Re: Bringing Clojure programming to Enterprise (2021)

#61

Post by nmil »

IBCNU wrote: post #59

AI augmented Repl driven dev has got me back into Clojure and it's been changing my life (full on JVM nerd: Kotlin mostly on the backend). The syntax is the best in the world (how computer's really operate?) but it's always been a pain to setup the tooling for me. I'm dumb like that. Now with AI it's become super easy to get back into the REPL and I'm in heaven. Totally moving it back into workflow and proposing to b…

May I ask what your workflow actually looks like? There's been a fair bit of clojureposting over the last few days, and I've decided to jump in and learn.

I love the idea of an AI integrated repl (like what Jeremy Howard and team have done with solveit), it's far more in line with my preferred vision of the AI augmented future of coding. Less "swarm of agent" more, "learn with the agent".

Re: Bringing Clojure programming to Enterprise (2021)

#62

Post by [deleted] »

honkcity wrote: post #41

I'd love to work with Clojure. I have the misfortune of working on something that is stuck on java1.8 and Groovy, part of the issue is the code quality is a disaster (json and xml parsed with regex...). At least with Clojure I'd get to enjoy the repl workflow and usable text editor (emacs). I also just enjoy working with sexps.

[deleted]

Re: Bringing Clojure programming to Enterprise (2021)

#64

Post by gorjusborg »

virgil_disgr4ce wrote: post #56
thunky wrote: post #14

Earlier quoted context omitted.

Clojure has some pretty big downsides last i looked: - syntax is hard to read unless you spend a lot time getting used to it - convention for short var names makes it even harder - function definition order makes it even harder - too dynamic for most people's taste - no type safety - the opposite of boring - no clear use case to show it clearly beating other languages - niche with small community and job market - JVM…

> - syntax is hard to read unless you spend a lot time getting used to it This is only true if you assume C-like syntax is the "default." But regardless of that, I'd argue that there's much less syntax to learn in LISPy languages. The core of it is really just one single syntactic concept.

This guy gets it.

The syntax argument is such a tired argument. With LISPy language there is almost zero syntax, it's pretty much executable AST.

Because of this, formatting matters a lot, but I don't think that's too different than other languages.

If you think LISP is hard to read, you are someone who could most benefit from branching out to a non-Algol lineage language.

Also, the little syntax present is pretty much timeless. Learn once and its yours for the next 50 years.

Re: Bringing Clojure programming to Enterprise (2021)

#65

Post by thunky »

gorjusborg wrote: post #64
virgil_disgr4ce wrote: post #56

Earlier quoted context omitted.

> - syntax is hard to read unless you spend a lot time getting used to it This is only true if you assume C-like syntax is the "default." But regardless of that, I'd argue that there's much less syntax to learn in LISPy languages. The core of it is really just one single syntactic concept.

This guy gets it. The syntax argument is such a tired argument. With LISPy language there is almost zero syntax, it's pretty much executable AST. Because of this, formatting matters a lot, but I don't think that's too different than other languages. If you think LISP is hard to read, you are someone who could most benefit from branching out to a non-Algol lineage language. Also, the little syntax present is pretty mu…

> The syntax argument is such a tired argument.

It's repeated a lot because it's true. The collective developer world has decided that LISP syntax is not the preference. Good if you prefer it, but you're the in the overwhelming minority.

Random example i just found via github explore: https://github.com/replikativ/datahike/blob/main/src/datahik...

You probably love it but to me it looks like a wall of text. Sure I can figure out what it does, but it gives me a headache.

Re: Bringing Clojure programming to Enterprise (2021)

#66

Post by dkarl »

honkcity wrote: post #41

I'd love to work with Clojure. I have the misfortune of working on something that is stuck on java1.8 and Groovy, part of the issue is the code quality is a disaster (json and xml parsed with regex...). At least with Clojure I'd get to enjoy the repl workflow and usable text editor (emacs). I also just enjoy working with sexps.

Honestly, if I could quit my job for six months and work in a codebase like yours, I'm extremely curious what I could accomplish with AI.

We have a codebase at work that was "stuck." We've consistently done minor library upgrades, but no major upgrades in several years, and was recognized as a major piece of technical debt / minor disaster for almost two years, in that we urgently needed to dedicate an engineer to it for a month or more to bring it up to date. We also suspected that framework upgrades would improve performance enough to save us a little bit in operating costs. I got curious, created a branch, and threw Claude at it. Claude knocked it out in a couple of days while I mostly worked on other things. Then we dedicated several engineer days to doing extra manual testing. Done and deployed. Now we're ready to experiment with giving it less resources to see if the performance improvement holds up in practice.

This codebase was only about 200k lines of code, so probably smaller than yours. Really curious how it would go with a larger codebase.

EDIT: Claude may only have taken a couple of days because I was only checking in occasionally to give it further instructions. I don't know how fast it would have been with my complete attention.

Re: Bringing Clojure programming to Enterprise (2021)

#67

Post by IBCNU »

nmil wrote: post #61
IBCNU wrote: post #59

AI augmented Repl driven dev has got me back into Clojure and it's been changing my life (full on JVM nerd: Kotlin mostly on the backend). The syntax is the best in the world (how computer's really operate?) but it's always been a pain to setup the tooling for me. I'm dumb like that. Now with AI it's become super easy to get back into the REPL and I'm in heaven. Totally moving it back into workflow and proposing to b…

May I ask what your workflow actually looks like? There's been a fair bit of clojureposting over the last few days, and I've decided to jump in and learn. I love the idea of an AI integrated repl (like what Jeremy Howard and team have done with solveit), it's far more in line with my preferred vision of the AI augmented future of coding. Less "swarm of agent" more, "learn with the agent".

Sure!

Setup is:

- nvim --listen /tmp/nvim — starts Neovim with a socket Claude can connect to

- /mcp in Claude Code — enables the Neovim MCP server, gives Claude direct control of Neovim

- lein repl in the nvim terminal

- Claude reads .nrepl-port, runs :ConjureConnect — REPL is live!

The loop is so dope:

- Claude writes code directly into my .clj files

- Then evals it into the running process via Conjure

- Sees the result in the REPL, iterates if wrong, all in the same conversation turn

- wrap-reload middleware means the web server hot-reloads changed namespaces on the next request

Re: Bringing Clojure programming to Enterprise (2021)

#68

Post by IBCNU »

nmil wrote: post #61
IBCNU wrote: post #59

AI augmented Repl driven dev has got me back into Clojure and it's been changing my life (full on JVM nerd: Kotlin mostly on the backend). The syntax is the best in the world (how computer's really operate?) but it's always been a pain to setup the tooling for me. I'm dumb like that. Now with AI it's become super easy to get back into the REPL and I'm in heaven. Totally moving it back into workflow and proposing to b…

May I ask what your workflow actually looks like? There's been a fair bit of clojureposting over the last few days, and I've decided to jump in and learn. I love the idea of an AI integrated repl (like what Jeremy Howard and team have done with solveit), it's far more in line with my preferred vision of the AI augmented future of coding. Less "swarm of agent" more, "learn with the agent".

Also I love your take.

Feel like a holy grail to me to back in the hot seat with repl driven but I can drop in and figure things out... all on the JVM. Madness!

Re: Bringing Clojure programming to Enterprise (2021)

#69

Post by dgb23 »

thunky wrote: post #47
asa400 wrote: post #33

Earlier quoted context omitted.

> the opposite of boring I have to push back on this one, respectfully. Clojure is easily the most boring, stable language ecosystem I’ve used. The core team is obsessed with the stability of the language, often to the detriment of other language values. This attitude also exists among library authors to a significant degree. There is a lot of old Clojure code out there that just runs, with no tweaks needed regardles…

What I meant by that is the metaprogramming capabilities that often get cited for allowing devs to create their own domain specific "mini languages". To me that's a "creative" way to write code because the end result could be wildly different depending on who's doing the writing. And creativity invites over-engineering, over-abstraction, and hidden costs. That's what I meant by the "opposite of boring".

You linked me to this comment from another one and I have to agree with this sentiment.

Creating these mini DSLs is something that requires a lot of thought and good design. There is a danger here as you pointed out sharply.

But I have some caveats and counter examples:

I would say the danger is greater when using macros and far less dangerous when using data DSLs. The Clojure community has been moving towards the latter since a while.

There are some _very good_ examples of (data-) DSLs provided by libraries, such as hiccup (and derived libraries), reitit, malli, honeysql, core match, spec and the datalog flavor of Clojure come to mind immediately (there are more that I forget).

In many cases they can even improve performance, because they can optimize what you put into them behind the scenes.

Re: Bringing Clojure programming to Enterprise (2021)

#70

Post by packetlost »

IBCNU wrote: post #59

AI augmented Repl driven dev has got me back into Clojure and it's been changing my life (full on JVM nerd: Kotlin mostly on the backend). The syntax is the best in the world (how computer's really operate?) but it's always been a pain to setup the tooling for me. I'm dumb like that. Now with AI it's become super easy to get back into the REPL and I'm in heaven. Totally moving it back into workflow and proposing to b…

> how computer's really operate?

I don't know exactly what you mean by this, but Clojure syntax is not really anywhere close to how computers actually process instructions.

Clojure is very nice though.

Post reply on HN