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

91–100 of 135 posts

Re: Bringing Clojure programming to Enterprise (2021)

#91

Post by midnight_eclair »

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?

the benefit of lisp in an editor with integrated repl environment is that you get to see immediate feedback by easily evaluating chunks of your code as you navigate it, without copying stuff back and forth between the editor and the repl

and the benefit of lisp comes from the fact that every expression is fully delineated by parentheses, so you don't need to select any text, find the start or the end of any syntactic construction, you just eval the form you're standing at and see the result

or just as easily you can wrap that form, bind the locals to test values and eval that to see what changes

Re: Bringing Clojure programming to Enterprise (2021)

#92

Post by tombert »

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…

I don't think the syntax is hard to read in any kind of objective sense, it's just different than most mainstream languages. Greek would be hard for me to read too, but that's not because it's necessarily harder to read than English, just that I don't really know Greek.

I agree with the short variable name convention, that's annoying and I wish people would stop that.

Everyone complains about a lack of type safety, but honestly I really just don't find that that is as much of an issue as people say it is. I dunno, I guess I feel like for the things I write in Clojure, type issues manifest pretty early and don't really affect production systems.

The clearest use-case I have for Clojure is how much easier it is to get correct concurrent software while still being able to use your Java libraries. The data structures being persistent gives you a lot of thread safety for free, but core.async can be a really nice way to wrangle together tasks, atoms are great for simple shared memory, and for complicated shared memory you have Haskell-style STM available. I don't remember the last time I had to reach for a raw mutex in Clojure.

Good concurrency constructs is actually how I found Clojure; I was looking for a competent port of Go-style concurrency on the JVM and I saw people raving about core.async, in addition to the lovely persistent maps, and immediately fell in love with the language.

Also, I really don't think the JVM is a downside; everyone hates on Java but the fact that you can still import any Java library means you're never blocked on language support. Additionally, if you're willing to use GraalVM, you can get native AOT executables that launch quickly (though you admittedly might need to do a bit of forward-declaration of reflection to get it working).

Re: Bringing Clojure programming to Enterprise (2021)

#93

Post by norir »

fredrikholm wrote: post #31
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?

You evaulate code within your editor against the REPL, seeing the output in the same window you're writing in (perhaps in a different buffer). The cycle is: 1. Write production code. 2. Write some dummy code in the same file (fake data, setup). 3. Evaluate that dummy code. See what happens. 4. Modify code until satisfied. Your feedback loop is now single digit seconds, without context switching. It's extremely relaxi…

You don't need a repl for this workflow and it can be easily implemented in any language. `ls *.MY_LANG | entr -c run.sh` You get feedback whenever you save the file.

Personally, I find waiting more than 200ms unacceptable and really < 50ms is ideal. When the feedback is very small, it becomes practical to save the file on every keystroke and get nearly instantaneous results with every input char.

Re: Bringing Clojure programming to Enterprise (2021)

#94

Post by ux266478 »

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…

> With LISPy language there is almost zero syntax

To be pedantic, this isn't quite correct. Syntax isn't countable like that. What S-expressions are light on is production rules. At their most basic they have IIRC 7 production rules but there are absolutely 0 languages based on s-expressions which are that simple, since it doesn't give you anything like quasiquotes, vectors, Lisp 2 function resolution, etc. Reader macros make matters much worse.

What we can say is that they are constructively simple, but not particularly unique in that. Once you get into real sexpr languages they aren't simpler than horn clauses, and are constructively more complex than languages like Brainfuck and Forth.

Re: Bringing Clojure programming to Enterprise (2021)

#95

Post by hrmtst93837 »

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…

[flagged]

Re: Bringing Clojure programming to Enterprise (2021)

#96

Post by slifin »

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…

As someone who loves the clojure repl I do somewhat agree with debuggers are better

If it was like a choice, Clojure has my favourite reverse debugger flowstorm which also exposes the runtime information of your program programmatically

So you can code cool visual programs against the runtime values of your first program

Like I built an emulator at work that simulates our program in production as a flowstorm plugin then you can step through the program frame by frame

I love taking the guess work out of production issues, just get the computer to show you exactly how everything went down

It's like a rewindable movie made up of thousands or millions of frames of the execution of your program

Re: Bringing Clojure programming to Enterprise (2021)

#97

Post by epgui »

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…

It’s not true, unless you have an unusual definition of “syntax”. Lisp basically has the most minimal syntax possible, by design.

To use the right words: it’s not a syntax issue, it just looks unfamiliar to you.

Re: Bringing Clojure programming to Enterprise (2021)

#98

Post by thunky »

hombre_fatal wrote: post #89
midnight_eclair wrote: post #88

Earlier quoted context omitted.

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. Sometim…

I didn't realize it was a no-no to share opinions here.

Plus to be fair we're having this discussion in the context of an article from 2021 that just rose to front page of HN, only to repeat the same set of pros we've been hearing about Clojure for ages (code as data, repl, etc).

Probably should expect some dissenting opinions.

Re: Bringing Clojure programming to Enterprise (2021)

#99

Post by InvOfSmallC »

My pain point (which I admit didn't recheck if someone did something about it), is an interoperable example of how to use Spring (n.1 framework for many enterprises) with Clojure.

Something where I feel Kotlin did better.

For me the best way to introduce something like this is that I can actually start with small software increments on a Spring Java project.

Re: Bringing Clojure programming to Enterprise (2021)

#100

Post by SatvikBeri »

jimbokun wrote: post #17
midnight_eclair wrote: post #11

every time i go back to writing non-clojure code outside of repl-driven environment i feel like a cave man banging rocks against each other no amount of ide smartness or agentic shenanigans is going to replace the feeling of having development process in sync with your thought process

You just made me wonder if REPL driven development and LLMs can be better combined somehow.

I use a REPL in tmux. That lets Claude code read/write to it easily, as well as letting me take manual control to investigate.
Post reply on HN