Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clojure: A Lisp that wants to spread

simongray.github.io

Post reply on HN
Print view View original

171–180 of 306 posts

Re: Clojure: A Lisp that wants to spread

#171

Post by stingraycharles »

devin wrote: post #168
stingraycharles wrote: post #160

Earlier quoted context omitted.

Most of Cognitect's projects use either Maven or tools.deps, though. I don't think I've see any of them use Leiningen, but perhaps you can show an example? Anyway, I'm mostly concerned by the fragmentation of it all. It doesn't help that there are now three (or four if you include maven) package / build tools for Clojure. The community is barely large enough to support a single one.

For the most part I’m not sure it matters. What specific problems have you had as a result of fragmentation in clojure project build tools? I don’t much care what the name of the command is: if running it produces an artifact I can depend on and use in my app, then it did the job. Different types of build pipelines have different needs.

For me personally it’s not a problem, but build tooling is a frequent obstacle for newcomers to the language. Fragmentation is the opposite of what we want here.

Re: Clojure: A Lisp that wants to spread

#172

Post by Heliosmaster »

crispinb wrote: post #75
inferiorhuman wrote: post #59

Earlier quoted context omitted.

What got me started with Clojure was a coworker at megacorp. He's since moved on to a company that makes widespread use of Clojure in production. Startup time was a huge factor for me because I wanted to write command line tools with it. The leaky abstractions were the other painful part – Clojure itself wasn't so bad, but Clojurescript (which would sidestep the startup issue) always seemed to leave me in callback he…

Clojure seems like an odd choice for command line tools. I can see why a committed Clojure programmer would want to reuse their existing skills for a slightly mismatching domain. But Rust/Go (even C) would seem like a more obvious choice if you weren't setting off from Clojure as a starting point.

You should check Michiel Borkent's work (borkdude):

- Babashka: https://github.com/borkdude/babashka

- Clj-kondo: https://github.com/borkdude/clj-kondo

- Sci: https://github.com/borkdude/sci

- Jet: https://github.com/borkdude/jet

But again, those are tools (especially babashka) from a Clojurist's perspective

Re: Clojure: A Lisp that wants to spread

#173

Post by Heliosmaster »

ooooak wrote: post #164

1. In India, there are only ~100 jobs for a Clojure developer. That includes people just throwing in Clojure just to hire Java/Scala developer. 2. The learning curve for the Clojure. Clojure is simple but it's not easy by any means. 3. JVM interop if you are not a java developer it adds in more learning time. Most of the Clojure libraries use java heavily. It's a good thing but it adds in an extra layer of learning j…

To be honest, I've done Clojure full-time (and exclusively) for 6 years now. I've almost never had to use Java interop. (With CLJS I did a little more JS interop).

There were always wrappers written by somebody else that always did what I was looking for.

Re: Clojure: A Lisp that wants to spread

#174

Post by jmiskovic »

kamaal wrote: post #96
vemv wrote: post #57

My personal perspective (after 8 years clojuring, half of that professionally) is that Clojure keeps progressing, with ever better tools and ideas for getting stuff done, optimally. I remain optimistic. At the same time, it still fails at my "golden test": can I gather 5 random freelance engineers and get them to ship a project within a few months, wasting almost no billable time? I can (and have) with Ruby, Typescri…

I think it's a problem loop. No one wants to use Clojure because it's hard to impossible finding Clojure Devs. Also no one wants to learn it for the same reasons. The demand is less to non-existent to a point any time spent learning Clojure is unlikely to give any substantial returns.

I would say Clojure more than substantial returns of invested time. Not just the language itself, but also the wider approach to software composition, feature accretion vs backward compatibility, schema'd dynamic typing seem benefictial no matter what your development tools you use. Maybe check out the talks below and see if they don't enRich you as software engineer.

https://www.youtube.com/watch?v=ROor6_NGIWU The Language of the System

https://www.youtube.com/watch?v=MCZ3YgeEUPg Design, Composition, and Performance

https://www.youtube.com/watch?v=oyLBGkS5ICk Spec-ulation

https://www.youtube.com/watch?v=YR5WdGrpoug Maybe Not

Re: Clojure: A Lisp that wants to spread

#176

Post by Heliosmaster »

mateuszf wrote: post #144
galaxyLogic wrote: post #113

Earlier quoted context omitted.

Much of the client-side code is about manipulating the DOM. Such code must assume the DOM-API exists. So such code can not run on the server unless there is some kind of ducky DOM environment there as well. And since client-side relies much on destructively manipulating the DOM, how can such code be tested on the immutable clojure server? > sizeable parts of the code are cross-compiled to run both on the browser But…

> Much of the client-side code is about manipulating the DOM. Such code must assume the DOM-API exists. So such code can not run on the server unless there is some kind of ducky DOM environment there as well. And since client-side relies much on destructively manipulating the DOM, how can such code be tested on the immutable clojure server? The same way as it's done in React. Think of a client app as a loop reacting…

Precisely. There's a lot of (domain) data manipulation before it gets to the DOM, and that's where cross-platform clojure (CLJC) excels.

Re: Clojure: A Lisp that wants to spread

#177

Post by m0skit0 »

peferron wrote: post #155
escherize wrote: post #105

Earlier quoted context omitted.

Clojure has while loops, but I think I see where you're coming from: It is a significantly different approach to programming, and if an engineer is not willing to re-jigger their style Clojure is not going to be a good fit for them.

I meant that they won't even try.

Those who won't even try are not worth hiring.

Re: Clojure: A Lisp that wants to spread

#178

Post by smnplk »

vga805 wrote: post #53
slifin wrote: post #48

Earlier quoted context omitted.

The normal one true way for most commercial companies right now is reframe, there's a nice ecosystem there and it's teachable

reframe is just the front end though isnt it? i think this is not the crud/rails alternative the op is talking about

Checkout Fulcro http://book.fulcrologic.com/#_fulcro_from_10000_feet

Re: Clojure: A Lisp that wants to spread

#179

Post by kimi »

crispinb wrote: post #75
inferiorhuman wrote: post #59

Earlier quoted context omitted.

What got me started with Clojure was a coworker at megacorp. He's since moved on to a company that makes widespread use of Clojure in production. Startup time was a huge factor for me because I wanted to write command line tools with it. The leaky abstractions were the other painful part – Clojure itself wasn't so bad, but Clojurescript (which would sidestep the startup issue) always seemed to leave me in callback he…

Clojure seems like an odd choice for command line tools. I can see why a committed Clojure programmer would want to reuse their existing skills for a slightly mismatching domain. But Rust/Go (even C) would seem like a more obvious choice if you weren't setting off from Clojure as a starting point.

I use it extensively for automating tasks, and it's pretty good. Sure, it's not as snappy as a Go executable, but:

1. you get all JVM libraries (eg JDBC) 2. it's very compact to write and maintain 3. you can develop stuff using a REPL, and this is very handy for ill-defined problems. 4. if the result is worth it, I can create a Graal native for it (but I hardly ever use this)

I ended up as an author of a thing to minimize the boilerplate involved: https://github.com/l3nz/cli-matic

Re: Clojure: A Lisp that wants to spread

#180

Post by exdsq »

slowmovintarget wrote: post #109
hota_mazi wrote: post #98

Earlier quoted context omitted.

I think you are omitting the main reason why Clojure never succeeded: it's dynamically typed at the core. It's on the wrong side of history in that respect. I know it's trying very hard to catch up to statically typed languages now by retrofitting some type system, but it's too little, too late. Static types are where the current state of the art is, and we're not going back. Clojure missed that train and will never…

Static types are the new religion, like OOP was in the 90s. Types solve 2% of programming errors. They lead to coupling for the sake of the compiler, and make code harder to change, harder to write, and often needlessly constrain the utility of the code where they're applied. But they do make the IDE code-completion go, so there's that.

Can you reference "Types solve 2% of programming errors"? I've read numerous research papers and blogs on this topic and have never seen anything as low as 2%.

Edit: Googled and nope, can't find anything.

Post reply on HN