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

51–60 of 135 posts

Re: Bringing Clojure programming to Enterprise (2021)

#51

Post by Antibabelic »

thunky wrote: post #44
Antibabelic wrote: post #35

Earlier quoted context omitted.

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

Clojure is reasonably popular as far as programming languages go. It's not difficult to get a job as a Clojure developer, particularly in certain sectors (fintech and healthcare are the heaviest Clojure users). Of course C++, Java, C# and PHP dwarf both Clojure and Rust by several orders of magnitude.

Re: Bringing Clojure programming to Enterprise (2021)

#52

Post by hatefulheart »

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

I read comments like these in bewilderment.

Have you worked for a company that hasn’t created its own, as you put it “mini language”?

Have you worked for a company that doesn’t indulge in over engineering, over abstraction and hidden cost?

Do you actually do programming for a job at all?

Re: Bringing Clojure programming to Enterprise (2021)

#53

Post by greekrich92 »

Cthulhu_ wrote: post #22
greekrich92 wrote: post #20

Earlier quoted context omitted.

Moby Dick is too hard to read. They should make it shorter with a limited vocabulary.

I kinda get where you're trying to go, but is Moby Dick style writing the best way to convey information? That is, prose is good for entertainment, but less so for conveying information, even less so for exactness.

Point being that things of high quality that are enriching sometimes require an investment

Re: Bringing Clojure programming to Enterprise (2021)

#54

Post by LandR »

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?

https://www.youtube.com/watch?v=5HHLT2_a1tI

An example of me solving an Advent of Code with clojure and repl. You can see i never interact with the repl directly, I just send code to it via my editor and get results inline.

Re: Bringing Clojure programming to Enterprise (2021)

#55

Post by thunky »

hatefulheart wrote: post #52
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".

I read comments like these in bewilderment. Have you worked for a company that hasn’t created its own, as you put it “mini language”? Have you worked for a company that doesn’t indulge in over engineering, over abstraction and hidden cost? Do you actually do programming for a job at all?

speaking of bewilderment, i'm not sure at all what you're getting at here.

because programmers suck we should make tools that make it easier for them to suck?

Re: Bringing Clojure programming to Enterprise (2021)

#56

Post by virgil_disgr4ce »

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

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.

Re: Bringing Clojure programming to Enterprise (2021)

#57

Post by tvink »

wwweston wrote: post #49
embedding-shape wrote: post #37

Earlier quoted context omitted.

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?

You're on to something. It's the lisp machine of it all. Hot reloading is nothing that requires anything special, so you can redefine a callback or dependency with ease in the repl and the system chugs along. You can theoretically do something similar in ruby, but it's the opposite of elegant, you'd be forced to re implement methods with different dependencies etc. It's also a function of being "functional" in the lisp sense, that things are lists, and lists can be replaced, functions or otherwise.

The fun way to get a feel for lisp machines is emacs, it's so easy to fall of a language and especially hand-coding in a language if you don't have to.

Re: Bringing Clojure programming to Enterprise (2021)

#58

Post by neutronicus »

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 two big things are:

1. REPL is automatically compiled into running systems 2. Great hot-reloading support

So it's generally very easy to "poke" at a running system, and the whole dev process assumes you will do this.

TBH, these days it is largely possible in a C++ debugger. Less so 10 years ago, though.

Re: Bringing Clojure programming to Enterprise (2021)

#59

Post by IBCNU »

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 bring it back into the dayjob.

Re: Bringing Clojure programming to Enterprise (2021)

#60

Post by IBCNU »

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…

JVM + Syntax is upside for me.

Type's are for compilers ;) jk. I'm fully lover or type's but removing the constraint is easy in clojure. teams resist.

<3 the opposite of boring.

Post reply on HN