I am not sure I buy into the argument that startup time is the hurdle to Clojure adoption. If that were the case, we would have at least seen more adoption for server use cases. Applying Occam's razor, I think Clojure is not popular for the same reason that common lisp is not popular - it is simply too hard. Functions and immutability are a more difficult abstraction to grasp compared to objects and procedures and mutable state. The overhead of finding quality talent is too high, and likely always will be because of this.
Clojure: A Lisp that wants to spread
111–120 of 306 posts
Re: Clojure: A Lisp that wants to spread
#112Startup 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.
Clojure for a Lisp dialect has already gained quite some adoption. I like Lisp, and of course, I would love to see Lisp being used everywhere and used more. But honestly, if someone asked me ten years ago if Clojure would ever become more popular than languages like OCaml, Haskell or Scala, I would've said: "very few people would probably know that such language has ever existed." I'm not trying to bash on other PLs, the popularity of any language is difficult to measure, and it is a very subjective topic. Still, today Clojure has lots of conferences, and the number is growing every year, several active podcasts, tons of (relevant and up to date) books, jobs (that no matter how many, never will be enough), meetups, etc.
I'm seeing Clojure related posts on top of HN almost every week. And I'm watching people trying Clojure, coming with all sorts of different backgrounds. I have worked with people who came to Clojure from C++, Ruby, Python, C#, Haskell, Go, Scala, OCaml, JavaScript, CL; people with no programming experience at all.
Of course, that all is incomparable with the craze that something like Typescript receives. And I used to feel anxious, worried that this would be the last ever job where I happily used Clojure. But after my third job where Clojure was the primary language, I stopped sweating about that.
I think Clojure, at this point, has stabilized in the industry and slowly and steadily would continue to attract people. The only thing that can genuinely kill Clojure - is a better version of its fork.
Re: Clojure: A Lisp that wants to spread
#113Last week some nice folks assured me tooling was good in Clojure; and not a total time suck, and so I'm getting ready to take the jump I think... but, one thing I'm still really skeptical about... is embodied in this paragraph: > The way the languages are integrated today, Clojure developers doing full-stack development don’t really have to think about data serialisation/deserialisation. Writing code for frontend and…
I can attest that full stack (server-browser) Clojure code sharing works very-very smoothly. I've been developing web applications like that for some time now, and apart from less context swithing (because it's the same language on both sides), sizeable parts of the code are cross-compiled to run both on the browser and the JVM with very little or no extra effort. Example 1: I'm using Clojure's Spec library for valid…
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 not all, right? I think the challenge would be knowing which parts can run on both the client and server, so you can know which parts can be moved between client and server.
But code is typically intended to run on either the server, or the browser. What would be the practical benefit of moving code between those environments?
I have not used Clojure so I'm asking because I have a similar circumstance with Node.js on the server, and DOM-manipulating JavaScript on the browsers, and its not easy to move code between those environments, and secondly, I don't much see the need for doing so. Naturally testing everything on the server would be nice, but I'm not sure how my DOM-manipulating client-code can be tested on the server.
Re: Clojure: A Lisp that wants to spread
#114I 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…
The point is to force you to think whether mutability is necessary or not in every given case - you have to, because you have to consciously pick it.
Re: Clojure: A Lisp that wants to spread
#115My 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 can (and have) with Ruby, Typescript
That's precisely the reason why Clojure attracts seasoned, experienced, grumpy developers.
Over and over again, they have been perfecting the art of "building things fast." The problem [with the most] programming languages today, that although they provide frameworks, command-line tools, code generators, etc. to build things quickly, the codebases very quickly become difficult to maintain and scale.
So many times, I have seen it myself. I quit jobs simply because I exhausted my mental and cognitive capacity to deal with the code that I wrote myself several months ago.
While Clojure codebases, no matter how messy they can get, they feel very much like gardens - you can slowly and organically keep growing them.
Some may say: "You're talking about Haskell, or Scala, (or some other language)" And in my experience, although you can do pretty cool things in those languages, sometimes simple, dumbed-down solutions are better. Some may argue: "Now you're talking about Python, or Go...". I think Clojure has a perfect balance between "sophisticated, ultrasmart" PLs and Pls with the books titled "X for complete idiots."
I think Clojure is an ideal language for writing business apps and more and more companies starting to see that.
Re: Clojure: A Lisp that wants to spread
#116Earlier 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.
Yeah, sometimes I look at some Typescript or Scala code and feel like I don't even understand what the heck they are trying to build anymore.
Very often it feels like they're "elegantly" trying to solve some made-up, bullshit problems for some questionable gain. Feels like bureaucracy for the sake of bureaucracy.
Totally like OOP shit that we're still trying to make sense of, like:
public abstract class Ellipse2D extends RectangularShape
What's the problem? Ellipses are rectangles with some extreme rounded corners. That's exactly how Euclid described them.
Re: Clojure: A Lisp that wants to spread
#117I am not sure I buy into the argument that startup time is the hurdle to Clojure adoption. If that were the case, we would have at least seen more adoption for server use cases. Applying Occam's razor, I think Clojure is not popular for the same reason that common lisp is not popular - it is simply too hard. Functions and immutability are a more difficult abstraction to grasp compared to objects and procedures and mu…
Clojure is not hard. It's just different. People immediately reject anything that's different. Just like when Fibonacci tried to convince people in 13th century to use indo-arabian numerals.
I've seen people with no prior programming experience learning Clojure within a few days. And I've seen senior software developers struggling with it for months.
Re: Clojure: A Lisp that wants to spread
#118Earlier quoted context omitted.
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...
How is it declining? Every single year we're adding 3-5 new conferences, last year alone - Ukraine, Russia, Brazil, India, Canada. New books being published. There are number of active podcasts (more than for any other FP lang). Latest JVM survey shown - Clojure has become more popular than Scala (largely due to Kotlin), but still surprisingly so. There's a Clojure related post on HN top, almost every week, sometimes multiple times a week.
Sure, it ain't Typescript or whatever, but it's definitely not declining.
Re: Clojure: A Lisp that wants to spread
#119Earlier quoted context omitted.
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.
Yeah, sometimes I look at some Typescript or Scala code and feel like I don't even understand what the heck they are trying to build anymore. Very often it feels like they're "elegantly" trying to solve some made-up, bullshit problems for some questionable gain. Feels like bureaucracy for the sake of bureaucracy. Totally like OOP shit that we're still trying to make sense of, like: public abstract class Ellipse2D ext…
You're aware that it's possible to write bad code in any language, even Clojure, right?
Re: Clojure: A Lisp that wants to spread
#120Earlier 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.
A command-line tool is nothing more than a script that maybe parses some input from the program's arguments or from stdin and then does something useful. Naturally you want to have the libraries you're used to available and the best language for CLI tools is the one you already know.
Building CLI tools in C/C++ is silly. If you like Rust/Go, sure, knock yourself out.
But the obvious choices are the scripting languages with runtimes that are already distributed as part of the OS .On Linux most CLI tools are built in Python or Perl and Ruby or Node.js are decent choices too.
JVM languages aren't an ideal choice due to the startup time, but given the size of the ecosystem you can find a library for pretty much anything you need and now we've got GraalVM to help with the startup time. So not a bad choice either.