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

91–100 of 306 posts

Re: Clojure: A Lisp that wants to spread

#91

Post by cube2222 »

inferiorhuman wrote: post #59
tensor wrote: post #26

Startup time isn't what is holding the language back. In my opinion it's: 1. Tooling. You end up spending way more time getting your tooling setup than it should be. 2. Difficulty in learning. 3. Clear best practices and frameworks. The philosophy of composing libraries is extremely powerful, but to gain broader adoption you still need straight forward frameworks and opinionated best practices. The last point has man…

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…

Nowadays you can use GraalVM to have quick startup time for commandline tools with Clojure.

Re: Clojure: A Lisp that wants to spread

#92

Post by mikelevins »

simongray wrote: post #58
codr7 wrote: post #55

Earlier quoted context omitted.

I'm curious, what features are missing that stops Clojure from being considered a proper Lisp? From my brief experience it can do most of the same things except reader macros.

The common talking points are * Clojure is based on seqs rather than cons cells. * Clojure renamed certain common functions, like car and cdr, so 30 year old Lisp example code no longer compiles. * Clojure doesn't have implicit tail call optimisation for recursion. * Clojure reveals its host platform when it has runtime errors.

This list doesn't strike me as the important things that Clojure is missing. They're all relatively minor matters. There are several other things that I would consider much more important.

I've gone on at some length about those things before (for example, see my long comment in this thread: https://news.ycombinator.com/item?id=22318748, ), so I won't repeat it here.

I'll just say that Clojure is pretty nice as far as it goes, and I like it when it's the right tool for the job, but I feel like it's only halfway to being a proper Lisp. Whenever I work in it for very long I always miss more complete Lisps, and I daydream about a Clojure with the missing pieces filled in.

Re: Clojure: A Lisp that wants to spread

#93

Post by didibus »

abrax3141 wrote: post #86

I don’t actually get the big deal about enforced immutability. Of course, you need to constrain yourself in certain circumstances to do things immutably, but it seems like something that should be contextual (immutably ...), rather than enforcing it. In fact, sometimes it is necessary in high performance multi—threaded/multi-processor environments to use side effects judiciously. Moreover, most serious lisp programme…

> but it seems like something that should be contextual

That's exactly what Clojure does. It makes immutability the default, but offer tons of mutable options with varying degree of contextual restraints for performance.

For example, by default your data-structures and record types are immutable. Now, say you can tolerate some mutability within a local context, you can make your immutable data-structures temporarily mutable (called transients), apply mutation for performance in the local context, and make it immutable again once done.

Another example is, by default, Global Variables are immutable and can't have their value changed, but, you can have them have per-thread local values, which are then allowed to be modified, since they're concurrently safe.

Another example is local variables are also immutable by default, and so are data-structures, but if you need to mutate the variable, you can make it `atomic` or `volatile` depending on the level of guarantees you need around concurrent access. Now you'll be able to change their values, for the former, using an atomic eventually consistent swap and set algorithm, and for the latter, with CPU cache synchronization.

There's more, but basically, the idea is to start with the safest default, and for every new level of: "I need a bit more performance or flexibility", there is an additional construct that can be used to enable it. All the way down to full blown mutable variables and data-structures when absolute performance is required.

Re: Clojure: A Lisp that wants to spread

#94

Post by didibus »

svnpenn wrote: post #35

The situation with windows is weird. You have to run a powershell script to install. They should just offer a Zip or Exe like every other programming language. https://github.com/clojure/tools.deps.alpha/wiki/clj-on-Wind...

You could try with: https://github.com/borkdude/deps.clj

It replaces the powershell code with a Clojure based executable.

Re: Clojure: A Lisp that wants to spread

#95

Post by [deleted] »

simongray wrote: post #37
anmonteiro90 wrote: post #33

It'd be interesting to back the claim that "Clojure is (slowly) eating the world.". Interestingly, that's absolutely not my perspective and I don't see any sources for that statement in the post.

I was talking about its ever expanding reach. It was more of an intertextual reference to the Andreessen Horowitz classic than an ideological statement about the popularity of Clojure, that is why I also added the (slowly).

[deleted]

Re: Clojure: A Lisp that wants to spread

#96

Post by kamaal »

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.

Re: Clojure: A Lisp that wants to spread

#97

Post by Scarbutt »

simongray wrote: post #40
anmonteiro90 wrote: post #39

Earlier quoted context omitted.

That makes sense but it's not what comes across. The sentence immediately after says that "the language continues to grow". That's what I'm questioning.

That is my impression, especially 2019 seems to have been a turning point after 1-2 years of relative stagnation, but I get that you feel differently. That's why you switched to OCaml ;-)

Looks like its peak was in 2014[0] and since then it has been declining.

https://trends.google.com/trends/explore?date=all&geo=US&q=c...

Re: Clojure: A Lisp that wants to spread

#98

Post by hota_mazi »

tensor wrote: post #26

Startup time isn't what is holding the language back. In my opinion it's: 1. Tooling. You end up spending way more time getting your tooling setup than it should be. 2. Difficulty in learning. 3. Clear best practices and frameworks. The philosophy of composing libraries is extremely powerful, but to gain broader adoption you still need straight forward frameworks and opinionated best practices. The last point has man…

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 catch it now.

Re: Clojure: A Lisp that wants to spread

#99

Post by peferron »

tensor wrote: post #26

Startup time isn't what is holding the language back. In my opinion it's: 1. Tooling. You end up spending way more time getting your tooling setup than it should be. 2. Difficulty in learning. 3. Clear best practices and frameworks. The philosophy of composing libraries is extremely powerful, but to gain broader adoption you still need straight forward frameworks and opinionated best practices. The last point has man…

Clojure would not gain widespread adoption even if all your points were fixed. The sad reality is that 99% of developers out there are instantly turned off by the parens and absence of while loops.

Re: Clojure: A Lisp that wants to spread

#100

Post by peferron »

hota_mazi wrote: post #98
tensor wrote: post #26

Startup time isn't what is holding the language back. In my opinion it's: 1. Tooling. You end up spending way more time getting your tooling setup than it should be. 2. Difficulty in learning. 3. Clear best practices and frameworks. The philosophy of composing libraries is extremely powerful, but to gain broader adoption you still need straight forward frameworks and opinionated best practices. The last point has man…

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…

Python and JS succeeded long before they had a static type system. Many people still use Python and JS today without type annotations. Elixir is not statically typed either and seems to be doing fine.

I like static typing and agree that it will eventually "win", but I really don't see where you're coming from here.

> I know it's trying very hard to catch up to statically typed languages now by retrofitting some type system

What makes you say that?

Post reply on HN