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

81–90 of 135 posts

Re: Bringing Clojure programming to Enterprise (2021)

#81

Post by midnight_eclair »

dgb23 wrote: post #69
thunky wrote: post #47

Earlier quoted context omitted.

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 la…

so many similar conversations happening, it's refreshing xD

https://news.ycombinator.com/item?id=47587386

Re: Bringing Clojure programming to Enterprise (2021)

#82

Post by hombre_fatal »

thunky wrote: post #14
LouDNL wrote: post #4

It's good to read that Clojure is getting more and more exposure. I write Clojure fpr my day job and wouldn't want to swap it for anything. The community is small but very helpfull and easy reachable. The learning curve is steap indeed, but very much worth it!

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…

You also need to learn a new tool to write lisp, like paredit.

While it's amazing once you've learned it, and you're slurp/barfing while making huge structural edits to your code, it's a tall order.

I used Clojure for a long time, but I can't go back to dynamic typing. I cringe at the amount of time I spent walking through code with paper and pencil to track things like what are the exact keyvals in the maps that can reach this function that are solved with, say, `User = Guest | LoggedIn` + `LogIn(Guest, Password) -> LoggedIn | LogInError`.

Though I'm glad it exists for the people who prefer it.

Re: Bringing Clojure programming to Enterprise (2021)

#83

Post by embedding-shape »

zingar wrote: post #76
IBCNU wrote: post #67

Earlier quoted context omitted.

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 r…

Hmmmm… seeing this workflow makes me wonder if I can do this with Ruby (the integration between agent and repl)

Absolutely, spin up a TCP server in Ruby, make it run `eval` on what it receives and tell the agent how to call it with netcat or whatever, works like a charm :)

Re: Bringing Clojure programming to Enterprise (2021)

#84

Post by stephbook »

joshlemer wrote: post #78
stephbook wrote: post #71

Earlier quoted context omitted.

Doesn't sound too different from Typescript breakpoints attached to a running website with "Hot Module Replacement."

Yeah to be honest after trying for many years to understand what is so special about this famous Clojure REPL I struggled to see how it was that different in practice from Python or other languages. In Python you can also highlight a section code and send it to the console to be evaluated. I think debuggers are just better anyways. When I got into the weeds trying to do this interactive REPL workflow on an actually r…

To be fair to Clojure, I think it's perfect for rule-engines, where the users supply "business logic" at runtime.

That's where "code is data" shines and you can manipulate it at will. For the rest, I'm glad I have "code as text" in my editor, where I can see and inspect it far more easily than one line at a time.

Re: Bringing Clojure programming to Enterprise (2021)

#85

Post by midnight_eclair »

thunky wrote: post #65
gorjusborg wrote: post #64

Earlier quoted context omitted.

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 ca…

i can link you similarly undecipherable walls of text in rust and zig and c

but i bet if you sat down a junior developer not yet entrenched in any style yet, they'd be able to grok lisp code MUCH faster than the intricacies of syntax of the other alternatives ¯\_(ツ)_/¯

Re: Bringing Clojure programming to Enterprise (2021)

#86

Post by embedding-shape »

joshlemer wrote: post #80
embedding-shape wrote: post #34

Earlier quoted context omitted.

If anything, I think that makes Clojure better. Almost no one in the community is doing stuff to serve "lowest common denominator", compared to how most of JS/TS development is being done, which is a breeze of fresh air for more senior programmers. Besides, the community and ecosystem is large enough that there are multiple online spaces for you to get help, and personally I've been a "professional" (employed + freel…

Spinning dwindling adoption as a good thing because it "unburdens community from serving lowest common denominator use-cases" is exactly the kind of of downplaying/deflection of every issue that I'm talking about, which constantly happens in the Clojure community. It's such an unhealthy attitude to have as a community and it holds it back from actually clearly seeing what the issues are and coming up with solutions t…

> It's such an unhealthy attitude to have as a community

How about just "different"? Turtle want to teach everyone to program, that's fine, just another way of building and maintaining a language. Clojure is clearly not trying to cater to the "beginner programmer" crowd, and while you might see it as "unhealthy attitude", I'd personally much prefer to realize having many different languages for different people is way better than every language trying to do the same thing for the same people. Diversity in languages is a benefit in my eyes, rather than a bad thing.

Re: Bringing Clojure programming to Enterprise (2021)

#87

Post by tombert »

killme2008 wrote: post #9

I wrote Clojure for about five years. Left when I changed jobs, not because I wanted to. It's genuinely one of the most productive languages I've used, and I still miss the REPL-driven workflow. One thing I built: defun https://github.com/killme2008/defun -- a macro for defining Clojure functions with pattern matching, Elixir-style. Still probably my favorite thing I've open sourced.

Clojure is such a fun language to write; it has great concurrency tools from the get go, and since it has access to the entire Java ecosystem you're never hurting for libraries.

I find myself missing Clojure-style multimethods in most languages that aren't Clojure (or Erlang); once multimethods clicked for me, it seemed so blatantly obvious to me that it's the "correct" way to do modular programming that I get a little annoyed at languages that don't support it. And core.async is simply wonderful. There are lots of great concurrency libraries in lots of languages that give you CSP-style semantics (e.g. Tokio in Rust) but none of them have felt quite as natural to me as core.async.

I haven't had a chance to touch Clojure in serious capacity in awhile, though I have been tempted to see if I can get Claude to generate decent bindings for Vert.x to port over a personal project I've been doing in Java.

Re: Bringing Clojure programming to Enterprise (2021)

#88

Post by midnight_eclair »

hombre_fatal wrote: post #82
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…

You also need to learn a new tool to write lisp, like paredit. While it's amazing once you've learned it, and you're slurp/barfing while making huge structural edits to your code, it's a tall order. I used Clojure for a long time, but I can't go back to dynamic typing. I cringe at the amount of time I spent walking through code with paper and pencil to track things like what are the exact keyvals in the maps that can…

i'm surprised anybody coming from clojure would say this.

you absolutely do NOT need to learn paredit to write lisp, any modern vim/emacs/vscode plugin will just handle parentheses for you automatically.

that said, if you do learn paredit style workflow - nobody in any language in any ide will come even close to how quickly you can manipulate the codebase.

Re: Bringing Clojure programming to Enterprise (2021)

#89

Post by hombre_fatal »

midnight_eclair wrote: post #88
hombre_fatal wrote: post #82

Earlier quoted context omitted.

You also need to learn a new tool to write lisp, like paredit. While it's amazing once you've learned it, and you're slurp/barfing while making huge structural edits to your code, it's a tall order. I used Clojure for a long time, but I can't go back to dynamic typing. I cringe at the amount of time I spent walking through code with paper and pencil to track things like what are the exact keyvals in the maps that can…

i'm surprised anybody coming from clojure would say this. you absolutely do NOT need to learn paredit to write lisp, any modern vim/emacs/vscode plugin will just handle parentheses for you automatically. that said, if you do learn paredit style workflow - nobody in any language in any ide will come even close to how quickly you can manipulate the codebase.

I realize how lame it is to relitigate Clojure's downsides every time it comes up. I fell into the same trap that annoys me about Elm threads: people who haven't used it in a decade chiming in to remind everyone they didn't like some aspect of it. Wow, such contribution.

It's like seeing that a movie is playing at the theater so you show up only to sit down next to people to explain your qualms with it, lolz. Sometimes you need to let others enjoy the show.

The OP of this thread even said all that needed to be said "The learning curve is steep but very much worth it" yet we're trapped in this cycle because someone had to embellish it with a listicle.

I take my post back.

Re: Bringing Clojure programming to Enterprise (2021)

#90

Post by [deleted] »

thom wrote: post #46
erfgh wrote: post #23

Can someone enlighten me about the REPL that lispers keep raving about? Isn't it more-or-less the same as the Python REPL?

Almost exactly, it's mostly how you use the REPL that differs, and then only because of what different editors prioritise. When I'm in Emacs, all my work happens against a running REPL - when I open or save a file, it's reloaded. Any tests loaded in the REPL rerun on every save, within that live instance. If I drop into the debugger, it's against that live instance. I can swap in mock components to a running system,…

[deleted]
Post reply on HN