Live data from Hacker News

Bringing Clojure programming to Enterprise (2021)

blogit.michelin.io

111–120 of 135 posts

Re: Bringing Clojure programming to Enterprise (2021)

#111

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…

[deleted]

Re: Bringing Clojure programming to Enterprise (2021)

#112
post #97
post #65

Earlier quoted context omitted.

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

The key issue is that Lisp's minimal uniform syntax has less variation to help with visual pattern matching, which we humans are good at (compared to richer syntax).

The meta-programming power of Lisp may be largely due to being homoiconic, although Dylan/Julia etc achieve similar without it. However Lisp's minimal syntax is not a prerequisite for homoiconicity: S-Plus/R has a more conventional syntax while retaining "code is a list" representation.

Re: Bringing Clojure programming to Enterprise (2021)

#113
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…

To me and many other people the syntax looks like Lego but that's a taste thing and arguing about taste isn't very productive. What is more objective is that there are less syntactic patterns to care about to do at least 90% of pretty complex systems including concurrency. The rest can usually be limited to a few namespaces that are rarely touched later because they just work. Compare that with Python...

If you want to calcify something and add robustness, use clojure.spec or Malli. Clojure encourages writing testable code and also in general, there is less code to test. Smaller problem, easier to tackle well.

The JVM is a beast for serious things because of its performance and tooling. If you need something small/ with a quick start, you can use GraalVM or some of the dialects like ClojureScript or Babashka to do what needs to be done. There is ongoing work on ClojureCLR, Jank, Janet, Basilisp, Hy and other dialects or inspired languages. Usually, these are pretty close to Clojure or try to follow the behavior of Clojure so that stuff written using Clojure.core just works the same. Clojure is turning out to be the actual lingua franca.

For me, programming in Clojure is the nearest thing to fun that I ever had doing programming. To me there seems to be less ceremony about things especially on bigger projects. For the little things Babashka tends to be even more straight forward.

And yes, there are things about Clojure that can make the life harder. Usually it has to do with laziness e.g. when you just try to get a data structure written to a file. When you want to have restartable, stateful components such as database connections, web servers, etc. and want to start them in a certain order. There are some functions that are unexpectedly slow and stuff like this that could be somewhat more predictable. All this would be more approachable if there were real documents for beginners with a little more explanations than the terse descriptions that senior developers with 20+ years of experience find sufficient.

Re: Bringing Clojure programming to Enterprise (2021)

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

It also allows you to write stuff like Rama, Specter (@nathanmarz) and to wrap stuff that you do often to avoid boilerplate.

Re: Bringing Clojure programming to Enterprise (2021)

#115
post #55

Earlier quoted context omitted.

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?

what a low trust attitude

wouldn't want to work at a place with those kind of values

Re: Bringing Clojure programming to Enterprise (2021)

#116
post #97
post #65

Earlier quoted context omitted.

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

minimal and simple is not the same thing as easy to use and natural/obvious. what looks easier to read:

  (if (
or

  if a 
to me the first one is way more noisy and confusing. and you really need a text editor with auto close and rainbow brackets to be productive, of course thats a non issue today with vscode and zed/neovim/helix but still something to think about. now rust might not be the best example for "easy to read syntax" but theres also python, lua, kotlin, even js if you ignore strict/loose equals and weird casts. all of them use more procedural/c like syntax because its the natural way humans think about running an algorithm. theres a reason why pseudocode in every textbook looks like that.

Re: Bringing Clojure programming to Enterprise (2021)

#117
post #116
post #97

Earlier quoted context omitted.

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.

minimal and simple is not the same thing as easy to use and natural/obvious. what looks easier to read: (if ( or if a to me the first one is way more noisy and confusing. and you really need a text editor with auto close and rainbow brackets to be productive, of course thats a non issue today with vscode and zed/neovim/helix but still something to think about. now rust might not be the best example for "easy to read…

> what looks easier to read

> to me

> theres a reason why pseudocode in every textbook looks like that

The reason is history, inertia, and limited exposure. Preference is self-reinforcing for those reasons. That doesn't make it better, or irreversible.

Re: Bringing Clojure programming to Enterprise (2021)

#118
post #65

Earlier quoted context omitted.

> 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 ¯\_(ツ)_/¯

To me, it's the uniformity and limited rules that make lispy languages attractive.

Javascript's destructuring syntax can look almost indecipherable, and it is mostly because the language syntax is not uniform in its meaning.

  const f = ({a: {b: [x, , z] = [], c: {d: w} = {}} = {}, e: [, y] = []} = {}) => ({x, y, z, w});
This is a function written in one of the most popularly used programming languages in the world.

Re: Bringing Clojure programming to Enterprise (2021)

#119
post #116
post #97

Earlier quoted context omitted.

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.

minimal and simple is not the same thing as easy to use and natural/obvious. what looks easier to read: (if ( or if a to me the first one is way more noisy and confusing. and you really need a text editor with auto close and rainbow brackets to be productive, of course thats a non issue today with vscode and zed/neovim/helix but still something to think about. now rust might not be the best example for "easy to read…

Honestly it's so exhausting. Every time Clojure gets mentioned on a broader forum, there's always some ridiculous claim that the Lispy syntax is "un-natural". Other Lisp dialects mostly pass unnoticed, but Clojure being more popular always causes some ruckus and I never get it - do people think that Clojurists stumble on it and be like: "holy mother of Alan Turing, this is so much more 'natural' to me than everything else..." Both choices are in the same sense "natural" as skiing and sledding. None of it is "natural" - reading prose in English, Thai or Katakana - all that is "unnatural". Nobody stumbles on the language and immediately thinks the syntax is just better - the majority of Clojurists come to it after years, often decades of using other PLs and they have to struggle at first.

Comparison with sledding is apt here, because both methods let you achieve the same goal - going down to the base of the mountain. Of course, skiing is more difficult to start with, it's more expensive, it requires deliberate effort and dedication. But the practical, learned experience far exceeds initial expectations. Do you realize how ridiculous it looks when inexperienced people try to convince them it's not worth it? Well, you may say, "the point is not to convince 'them', but to show the wider public..." And that's even more imbecilic. Imagine trying to point at people zigzagging 70 miles down from the peak, having enormous fun and telling the observers not to even try that? I'd dare anyone to argue with an experienced skier that sledding is more fun.

> theres a reason why pseudocode in every textbook looks like that.

Like I said, most - the absolute majority of Clojure programmers come to it after many years of programming in other languages (see the surveys). They are using it as a real instrument to achieve real goals, to solve practical problems. It's not an educational tool, not a "hello world app" incubator, not a "good for the resume" kind of a thing for them. If you (not you personally, but some proverbial programmer) are arguing just for the sake of it, well, with all respect, then "fuck you" (for wasting people's time). If you're sincerely trying to make a choice - nobody can "make a skier" out of you - that is something you must do on your own. No theory, no books, no videos can ever convey to you the enormous joy you may get out of it later - there's too much nontransferable tacit knowledge there. Just keep in mind, people in this community didn't make the choice because "their brains are wired differently" or something, not because "they are oblivious", no. Unlike you - they have seen, walked and lived through both of these worlds. Most of them have to switch between them, sometimes multiple times a day. And yes, the wider majority can often be wrong. In fact, history shows us that it makes wrong choices all the time. Lispers don't care about popular choices - they prioritize pragmatism above all.

Re: Bringing Clojure programming to Enterprise (2021)

#120
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…

Ah, here we go again. Every single time Clojure gets mentioned on HN, some clueless egghead comes listing various "issues" without considering holistic, overall experience of using the language for real. Because they effing never did. Sure, it's so easy to "hypothesize" about deficiency of any given PL: - Python: slow; GIL; dynamic; package management is shit; fractured ecosystem for a decade due to version split. -…

> Ah, here we go again. Every single time Clojure gets mentioned on HN, some clueless egghead comes listing various "issues" without considering holistic, overall experience of using the language for real. Because they effing never did

Stopped reading here because of your hostility so I'll just say: yes I tried to use it "for real" but I didn't like it.

Post reply on HN