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

101–110 of 135 posts

Re: Bringing Clojure programming to Enterprise (2021)

#101

Post by joshlemer »

epgui wrote: post #97
thunky wrote: 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.

I think this is kind of misleading. Yes s-expressions have very simple syntax in and of themselves. But s-expressions are not all that's required to get all the control structures in Clojure. You need to memorize all the special forms and all the standard macros that people use on a day to day basis. And they're just as hard (actually IME harder) to memorize as any other syntax. let, cond, record, if, condp, let-if, fn, def, defn, loop, recur, if-some, when-let, for, ->, ->>, as->>, cond-> ...

To this day I have to look up whenever I get back into clojure what the "syntax" is of ns, require, import, etc.

Re: Bringing Clojure programming to Enterprise (2021)

#102

Post by bitwize »

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!

> It's good to read that Clojure is getting more and more exposure.

I nominate this sentence for "best inadvertent freestyle rap on Hackernews".

Re: Bringing Clojure programming to Enterprise (2021)

#103

Post by epgui »

joshlemer wrote: post #101
epgui wrote: 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.

I think this is kind of misleading. Yes s-expressions have very simple syntax in and of themselves. But s-expressions are not all that's required to get all the control structures in Clojure. You need to memorize all the special forms and all the standard macros that people use on a day to day basis. And they're just as hard (actually IME harder) to memorize as any other syntax. let, cond, record, if, condp, let-if,…

Remembering macros is much more like remembering functions than syntax.

Re: Bringing Clojure programming to Enterprise (2021)

#104

Post by regularfry »

virgil_disgr4ce wrote: post #56
thunky wrote: 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…

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

But that's exactly the root of the complaint. Because there's (for the sake of argument) only one syntactic concept, there's no bandwidth for structural concepts to be visible in the syntax. If you're used to a wide variety of symbols carrying the structural meaning (and we're humans, we can cope with that) then `)))))))` has such low information density as to be a problematic road bump. It's not that the syntax is hard to learn, it's that everything else you need to build a program gets flattened and harder to understand as a result.

Even among lisps this has been problematic, you can look at common lisp's LOOP macro as an attempt to squeeze more structural meaning into a non-S-expression format.

Re: Bringing Clojure programming to Enterprise (2021)

#106

Post by weavejester »

hrmtst93837 wrote: post #95
thunky wrote: 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…

[flagged]

Typically you're either deploying via a container, in which case there's no more overhead than any other container deployment, or you're deploying directly to some Linux machine, in which case all you need is a JVM - hardly an arcane ritual.

Re: Bringing Clojure programming to Enterprise (2021)

#107

Post by fredrikholm »

norir wrote: post #93
fredrikholm wrote: post #31

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…

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.

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

As in restarting the entire program and re-running every subsequent query/state changing mechanism that got you there in the first place, being careful not to accidentally run other parts of the program, setting it up to be just so, having to then rewrite parts if you then want to try something somewhere else?

Perhaps I'm misunderstanding you, because that sounds horrible unless you're scripting something small with one path.

The whole point of the REPL is that you evaluate whatever functions you need to get into your desired state and work from there. The ad hoc nature of it is what makes you able to just dig into a part of the code base and get going, even if that project is massive.

> Personally, I find waiting more than 200ms unacceptable and really Calling a function on a running program takes microseconds; you're not restarting anything.

Re: Bringing Clojure programming to Enterprise (2021)

#108

Post by iLemming »

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…

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.

- Rust: borrow checker learning curve; compile times; half-baked async; too many string types; unreadable macros; constantly changing.

- Go: no generics for a decade, now bolted on awkwardly; noisy error handling; no sum types; no enums; hard to get right concurrency.

- Java: absurdly verbose; NPEs all around; JVM startup; enterprise culture;

- C+: Undefined behavior everywhere; header files; template err messages; huge lang spec;

I can keep yapping about every single programming language like that. You can construct a scary-sounding wall of bullet points for literally anything, without ever capturing the cohesive experience of actually building something in the language. For all these reasons, programming in general could sound like a hard sell.

Stop treating Clojure like a "hypothetical" option. It doesn't need your approval to be successful - it already is. It's not going away whether you like it or not - despite your humble or otherwise IMOs and uneducated opinions. It's endorsed by the largest digital bank in the world, it scales to serious, regulated, high-stakes production systems. Not theoretically, not conceptually, not presumably - it has proven its worth and value over and over, in a diverse set of domains, in all sorts of situations, on different teams, dissimilar platforms. There are emerging use-cases for which there's simply no better alternative. While you've been debating whether to try it or not, people have been building tons of interesting and valuable things in it. Clojure is in no rush to be "sold" to you or anyone else. It's already selling like ice cream in July (on selected markets) and you just don't know it.

Re: Bringing Clojure programming to Enterprise (2021)

#109

Post by [deleted] »

thunky wrote: post #55
hatefulheart wrote: post #52

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?

[deleted]

Re: Bringing Clojure programming to Enterprise (2021)

#110

Post by asa400 »

thunky wrote: post #42
Antibabelic wrote: post #32

Earlier quoted context omitted.

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.

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

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

This is kind of like saying that fewer people are drinking Coke every year and are choosing other beverages. It might be objectively true but it glosses over the fact that literally billions of people drink Coke daily and will continue to do so for decades to come.

The JVM is the same. Some people and organizations might be using zig or mojo (and I have absolutely nothing against zig or mojo, to be clear, I hope they succeed) but many multiple orders of magnitude more individuals and organizations run JVM stuff in a given year and will continue doing so.

At this point, the JVM is a civilizational technology. If it went away tomorrow, multiple banks would fail, entire countries would no longer be able to administer social services, millions of people would die. The JVM is in everything.

Developers on HN using zig, mojo, etc. aren't really a representative sample.

Post reply on HN