Live data from Hacker News

Bringing Clojure programming to Enterprise (2021)

blogit.michelin.io

41–50 of 135 posts

Re: Bringing Clojure programming to Enterprise (2021)

#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.

Re: Bringing Clojure programming to Enterprise (2021)

#42
post #30

Earlier quoted context omitted.

i don't think you're wrong necessarily...but rust, golang, zig, mojo, etc are gaining popularity and imo they wouldn't be if they were JVM languages.

It's almost as if different tools exist for solving different problems. Clojure is "Lisp on the JVM". That's the core premise behind the language. Rust is a "systems programming language with a focus on type and memory safety". This is an apples-to-oranges comparison. They offer different benefits while providing different drawbacks in return. Their ecosystems are likewise very different, in each case more closely ta…

understood, i'm just pointing out that people seem to prefer the apple over the orange.

Re: Bringing Clojure programming to Enterprise (2021)

#43
post #14
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…

> no type safety

That's fair if you're looking at it from a performance perspective.

Not entirely fair if you look at it from a perspective of wanting fast feedback loops and correctness. In Clojure you get the former via the REPL workflow and the latter through various other means that in many cases go beyond what a typical type system provides.

> the opposite of boring

It's perhaps one of the most "boring in a good way" languages I ever used.

Re: Bringing Clojure programming to Enterprise (2021)

#44
post #28

Earlier quoted context omitted.

yes it's just my opinion. but Clojure's market share is tiny so there must be something to that. it's not even in the top 50 here: https://www.tiobe.com/tiobe-index/ . Lisp is 26.

"The TIOBE index measures how many Internet pages exist for a particular programming language." For some reason I doubt this is in any way representative of the real world. Scratch, which is a teaching language for children, bigger than PHP? Which is smaller than Rust? Yeah, these are results you get when you look at the Internet, alright.

Sure that index isn't great (I think it's basically a regurgitation of Google Trends), but I don't think you're suggesting Clojure is actually a popular language are you? Which is the only point I'm trying to make (that it isn't popular).

Re: Bringing Clojure programming to Enterprise (2021)

#45
post #28

Earlier quoted context omitted.

yes it's just my opinion. but Clojure's market share is tiny so there must be something to that. it's not even in the top 50 here: https://www.tiobe.com/tiobe-index/ . Lisp is 26.

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…

I'm glad it works for you and many others and gives you a good living. Nothing wrong with that. I wasn't trying to attack it or anyone that uses it, just stating why I never warmed up to it and projecting why I think it hasn't become popular.

Re: Bringing Clojure programming to Enterprise (2021)

#46
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, go check stuff in a browser (even jack into a live webpage with ClojureScript), all in one long running instance. I have struggled to recreate this kind of setup as smoothly in Python with any editor (pytest doesn't want to run this way, and IPython's autoreload doesn't feel as reliable), but I do probably write more REPLy code in Python than most, so all my model training and optimisation runs during development happen in pausable background threads in IPython etc.

All that said, 90% of the time you still just eval a bit of a code to see what happens and that's the same between the two languages.

Re: Bringing Clojure programming to Enterprise (2021)

#47
post #33
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…

> 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".

Re: Bringing Clojure programming to Enterprise (2021)

#48
post #43
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…

> no type safety That's fair if you're looking at it from a performance perspective. Not entirely fair if you look at it from a perspective of wanting fast feedback loops and correctness. In Clojure you get the former via the REPL workflow and the latter through various other means that in many cases go beyond what a typical type system provides. > the opposite of boring It's perhaps one of the most "boring in a good…

> It's perhaps one of the most "boring in a good way" languages I ever used.

this is what i meant by that: https://news.ycombinator.com/item?id=47614353

Re: Bringing Clojure programming to Enterprise (2021)

#49

Earlier quoted context omitted.

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…

Indeed. For people used to the "typical REPL" from Ruby, Python and alike, the best comparison I've found is this: "Typical REPL" workflow: Have one editor open, have one REPL open, have one terminal open that runs the application. One change is typically: Experiment in the REPL window, copy-paste into your editor, write tests, restart application (lose all state), setup reproduction state, test change. Or something…

Being someone who’s used to the “typical REPL” flow, I’m not sure I grasp what’s going on with the no-restarts. The implications I think I see are:

* Clojure is built different in terms of hot code reloading

* the REPL is its own application process in languages Ruby or Python, but in Clojure it’s sortof a client for the system

Is that right? Is there more to it?

Re: Bringing Clojure programming to Enterprise (2021)

#50
post #47
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".

In practice, though, most developers don’t do that.

There’s a rule of thumb: write a macro as a last resort.

It’s not hard to stick to it. In general, you can go a long, long way with HOFs, transducers, and standard macros before a hand-rolled macro would serve you better.

Post reply on HN