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

31–40 of 135 posts

Re: Bringing Clojure programming to Enterprise (2021)

#31

Post by fredrikholm »

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 relaxing compared to the alternatives (rerunning tests, launching the program with flags, what have you).

Re: Bringing Clojure programming to Enterprise (2021)

#32

Post by Antibabelic »

thunky wrote: post #30
Antibabelic wrote: post #27

Earlier quoted context omitted.

The JVM is one of the major selling points of Clojure. You can "write once, run anywhere" and benefit from Java's massive ecosystem, all without having to use a Blub language. Modern JVM implementations are also incredibly fast, often comparable in performance to C++ and Go.

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 tailored to their particular niche.

Re: Bringing Clojure programming to Enterprise (2021)

#33

Post by asa400 »

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…

> 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 regardless of language version.

Also, you have access to tons of battle tested Java libraries, and the JVM itself is super stable now.

I won’t comment on or argue with your other points, but Clojure has been stable and boring for more than a decade now, in my experience.

Re: Bringing Clojure programming to Enterprise (2021)

#34

Post by embedding-shape »

thunky wrote: post #28
jimbokun wrote: post #16

Earlier quoted context omitted.

Most of those seem very subjective with many people having the exact opposite opinion.

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 + freelancing) Clojure/Script developer for close to 7 years now, never had any issues finding new gigs or positions, also never had issues hiring for Clojure projects either.

Sometimes "big enough" is just that, big enough :)

Re: Bringing Clojure programming to Enterprise (2021)

#35

Post by Antibabelic »

thunky wrote: post #28
jimbokun wrote: post #16

Earlier quoted context omitted.

Most of those seem very subjective with many people having the exact opposite opinion.

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.

Re: Bringing Clojure programming to Enterprise (2021)

#36

Post by Oreb »

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…

> syntax is hard to read unless you spend a lot time getting used to it

That’s pretty much exactly the opposite of how I always felt. Perhaps because I’m not a programmer by education, I always struggle to remember the syntax of programming languages, unless I’m working in them all the time. After I return to a language after working in other languages for a while, I always have difficulties remembering the syntax, and I spend some time feeling very frustrated.

Clojure and Lisps more generally are the exception. There is very little syntax, and therefore nothing to remember. I can pick it up and feel at home immediately, no matter how long I’ve been away from the language.

Re: Bringing Clojure programming to Enterprise (2021)

#37

Post by embedding-shape »

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…

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 like this.

In a Clojure REPL workflow, you'd do something like: Have one editor open, this starts the REPL and often the application in the background too. One change is typically: Edit code, evaluate that snippet of code (which sends it to the REPL and the running application), write tests, evaluate them too in the editor, if you're happy, hit CTRL+S and you're done. Application still has the existing state, no restarts needed and you essentially never have to leave the editor window/pane.

Of course, others might have slightly different workflows, but for myself and many (most?) other Clojure developers I've observed in the wild, this is pretty much the standard.

Re: Bringing Clojure programming to Enterprise (2021)

#38

Post by rienbdj »

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…

Is this similar to Unison scratch file driven development?

Re: Bringing Clojure programming to Enterprise (2021)

#39

Post by [deleted] »

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…

[deleted]
Post reply on HN