It is now official. Netcraft has confirmed: Clojure is dying.
One more crippling bombshell hit the already beleaguered Clojure community when Lambda Island confirmed that Clojure market share has dropped yet again, now down to less than a fraction of 1 percent of all new code. Coming on the heels of a recent Netcraft survey which plainly states that Clojure has lost more market share, this news serves to reinforce what we've known all along. Clojure is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent comprehensive programming languages survey.
You don't need to be the Amazing Kreskin to predict Clojure's future. The hand writing is on the wall: Clojure faces a bleak future. In fact there won't be any future at all for Clojure because Clojure is dying. Things are looking very bad for Clojure As many of us are already aware, Clojure continues to lose market share. Red ink flows like a river of blood.
Due to the troubles of Lisp, abysmal sales and so on, Lisp Machines went out of business and was taken over by GigaMos Systems, who sold another troubled Lisp. Now GigaMos is also dead, its corpse turned over to yet another charnel house.
All major surveys show that Clojure has steadily declined in market share. Clojure is very sick and its long term survival prospects are very dim. If Clojure is to survive at all it will be among programming language dilettante dabblers. Clojure continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, Clojure is dead.
Nice E2 reference. Hard to believe now, but back in the day there was serious debate about whether it should compete with the upstart Wikipedia. Glad they went the creative writing direction instead, there's some great stuff in there.
BSD is indeed not what it used to be. Or rather, the market for UNIX (including Linux) servers expanded quite a lot, but BSD (basically FreeBSD and co) didn't rise as much.
At one point, a couple of decades back, it was more head-to-head with Linux, while no does anybody think they're even in the same order of magnitude?
Clojure's not dying, but it's also not thriving[1].
I think it will continue on as a solid niche language for the foreseeable future, but it's highly unlikely that the language will grow by leaps and bounds barring some must-have innovation in the Clojure language and/or ecosystem that gets the tech world to take it more seriously.
There are so many options these days that it's tough to stand out from the crowd. Clojurescript, while interesting, is a dime-a-dozen with Elm, Purescript, Scala.js, Typescript, etc. all on offer, and with static types to boot. Also, Lisp itself is a tough sell, mainstream adoption isn't in the cards without a major paradigm shift.
I don't really have anything to say about your other points, but the only comparable compile-to-JS tech in your list to ClojureScript is Scala.js. The other options assume you don't see significant value in using the same programming idioms across client and server.
The point is that most server languages these days compile to javascript. OCaml has Bucklescript, Haskell has GHCJS, Kotlin and Rust compile to JS, etc.
Clojurescript and Scala.js are probably the most mature, but getting developers to make the switch when their server language is not Clojure or Scala is an uphill battle. Case in point: I find Bucklescript to be absolutely amazing (generated binaries on par with size of hand written JS) but Scala.js is a better fit since I've been writing Scala for 6 years.
That's exactly what I'm saying. You don't choose ClojureScript or Scala.js haphazardly, you're already using Clojure or Scala. Thus it doesn't make sense to lump them into choices that are primarily client-centric like Elm or PureScript.
As someone who chose ClojureScript over many of the other compile-to-JS languages without using Clojure on the server, I disagree.
Especially if ClojureScript could become more attractive than (or at least have a real solid standing amongst) Elm/PureScript/etc., I could see that being a big boon to Clojure development as well.
With CLJS on Node booting up as fast as it does, I can envision a world where CLJS is vastly more popular than CLJ, since it's able to deliver a class of experience prohibited by the slow JVM startup. All the other common criticisms are shared by both CLJ and CLJS, so there's a chance that, eventually, CLJ only has the startup time as a knock against it, and CLJS has no such shortcomings. (Ignoring, of course, "Lisp is weird".. don't get me started.)
That all said, I think all 'piles-to-JS language bets are off in the face of WASM.
There are also things that clj has and cljs doesn't have and this is the top-class virtual machine. lots of us really appreciate JVM, and are not impressed at all by node, and especially its ecosystem.
That just depends on your background. For a bunch of us folks who come from a non-JVM background, we could say the same about Java. Really, Java and JS are the two biggest language communities in the world, with phenomenal feats of engineering in their runtimes, and a whole host of things to complain about. Since CLJ and CLJS are tied in this regard, I still think the startup time is the only differentiable factor in my proposed hypothetical future.
So nice to hear someone else say this, and I feel the same about CLJS.
And yeah WASM is looking pretty promising (threads/gc/efficiency), and a CLJ like language that targets it directly would be so interesting for the very long term future.
I've used Opal for client-side validation of a server-side game's rules. (player makes a move on the client, game rules are played out, just the move is sent to server and server plays the same move again using the same game class)
That said, it wasn't a breeze to work with. The compiled object's properties were hard to access. I actually had to serialize it to json
I'm a Rubyist and don't know much Clojure, but that sounds pretty reasonable. I'm not sure if Ruby would have taken off if it wasn't for Rails. AFAIK, Rails pushed forward a lot of new ideas in web development and really brought Ruby into the mainstream. Going by that comparison, I would think it'd be hard for Clojure to really catch on without a revolutionary framework that you need it to work with, which may be tough to pull off considering that it's all on the JVM.
Rails was definitely responsible for Ruby going mainstream, without it, it would slide below Python.
More than that: I think that combination of TextMate and Rails brought a huge number of web devs from Windows to MacOS as well. I remember around maybe 2005/6 people were switching from Intel based Windows to, at that time, PowerPC based Macs (transition to Intel was about to happen) just to use TextMate and Rails - image how huge change it was for developers - and they did it and liked it. Good times.
It has always been a pain to develop with Ruby on Windows, especially if targeting a Linux server. Gems that don't build on Windows, little help because almost everbody is on a Mac, Linux or a Linux VM on Windows. I knew many people that switched to a Mac because of that. They didn't want to manage a Linux desktop, which was more painful to do than today and with some glitches even today. I switched to Ubuntu instead and I'm still there. Emacs instead of TextMate, which was really big at the time.
That's pretty much how I've found it. Ruby works fine on Windows, until you hit a gem version that doesn't build. It usually works all right if you can stay a few Ruby versions behind and carefully pick the gems you use, but it'll likely fall apart if you try to collaborate with anyone using Mac or Linux, updating to the latest Ruby and gems and grabbing any gem they feel like.
Although now, there's WSL on Windows 10. Ruby works great on that for me, every version, every gem. It's kinda like the equivalent of Wine, so it just sits there and doesn't hog resources like a VM.
I was one of them. I was doing some web design/frontend at that time (2005-2006), and the whole Ruby on Rails movement seemed so different, easy to learn, and yet quite productive.
And you could develop on a Mac (!!!. Windows XP was my OS at that time). All the rails screencasts I saw featured TextMate, on a Mac.
And so the first ActionScript gig I did was to pay for my shiny new Mac Mini.
Looking back to it, it seems like a stupid cargo cult effect, but Rails is the main reason I switched to the Mac since then.
Ditto, thanks to my first job, and I don't regret it, either. Despite recent software hitches, Mac OS has been far and away a superior experience for development than when I was trying to run RailsInstaller on my Windows machine.
It's not really clear to me why, but lisps keep trying and keep dying. Best guess is that in the end, syntax really does matter and lisp just doesn't have enough of it.
Whether it's scheme or clojure or arc, every once in a while a new lisp comes along, and they never make it. This through decades and generations of programmers.
My (half-serious) take on this is that LISPs are too easy. A lot of little things that are hard in other languages are easier in LISP, which results in you writing the code yourself instead of pulling in a library some else wrote. This greatly reduces both the need and offering of a package manager which usually plays an important role in establishing a ecosystem and community in other languages.
In all seriousness, I think that package managers play a big role in the success of modern languages, espcially if the package managers are there from the beginning. As far as I'm aware Clojure was the only attempt at a LISP where a package manager was included from the beginning.
IIRC, when Lisp was a leading language for "AI", it was specifically a leading language for expert systems, not ML. Even to the extent that was due to language features being well-suited to the domain, there's still no real reason to expect that suitability to translate to the radically different approaches to AI today.
> Even to the extent that was due to language features being well-suited to the domain, there's still no real reason to expect that suitability to translate to the radically different approaches to AI today.
People these days use Python for ML, which is even less suited for the domain (and lacks the ability to re-suite itself), not to mention being significantly less performant than popular Common Lisp implementation.
Python is well suited for ML, just not in technical sense:
it is a very simple language that's easy to use by people who have a strong academic background, but not much of programming experience (AKA: Data Scientists). Also it has a lot of numerical libraries (numpy, pandas)
ML problems are those where people benefit from the assistance of thinking more like the computer does. Python helps people think more like the computer. (corrolary: although a very similar language, Perl helps the computer think more like you do).
Very unlikely. Incanter is basically dead, so I don't think Clojure is one of the go-to numerical computing platforms. Therefore I just don't see it getting the mind-share required to thrive for these sorts of applications.
Besides, at the technical level AI in the age of Lisp was a very different beast than AI today. If you take Eurisko to be the apex of Lisp-based AI, it benefited from code-as-data, dynamism, creating and mutating more or less human digestible heuristics on the fly. AI today is linear algebra. Clojure/Java have perfectly good linear algebra libraries but there's nothing about the language that specifically lends itself to solving these problems. I'd certainly love to see a nicely done deep learning library in Clojure using lots of macros to give a succinct, and it probably even exists, but there are no fundamental advantages over Python.
I've always felt some sadness that Clojure presented an extremely sensible way of programming in a multicore world, just as distributed and GPU computing began to take over for really heavy workloads. Personally I love the immutability anyway, and there's no denying those extra cores are _there_.
Anyway, I love Clojure and it'd be great not to have to use Python (and especially R), but it's just not realistic.
I first learned about it while moaning about Incanter in previous Clojure threads! But I don't think it's broad enough (I realise it doesn't aim to be) to usefully capture enough mindshare that Clojure is a first-class citizen in the numerical computing space.
There is no direct replacement, because there are different libraries tackling different aspects of what you may need: high performance computations, data munging, distribution, probability stuff, ML, deep learning etc. Most are on github, some have websites and lists/communities. Google is your friend there. Most of them are still in heavy development, but other than cutting edginess, they do their things much better than incanter would do it (but I never found Incanter useful for beyond helloworld-ish programs even in its glory days so that's not a particularly high bar).
Lisp was invented to produce AI. Machine learning is a better way to produce AI. So in a sense, Machine learning takes the needs for Lisp (in AI) away.
Lisp was invented by the guy who coined the term AI, not for AI. Its popularity in AI circles in the past stems from a) being developed by the same groups of people and b) being well-suited for symbolic computation; something that many mainstream langauges suck about to this day, even though it's nothing AI-specific.
ML takes the needs for Lisp more-less in the same way Entity-Component-System architecture takes the needs for C++ and C# programmers...
> A programming system called LISP (for LISt Processor) has been developed for the IBM 704 computer by the Artificial Intelligence group at M.I.T. The system was designed to facilitate experiments with a proposed system called the Advice Taker, whereby a machine could be instructed to handle declarative as well as imperative sentences and could exhibit ``common sense'' in carrying out its instructions. The original proposal [1] for the Advice Taker was made in November 1958. The main requirement was a programming system for manipulating expressions representing formalized declarative and imperative sentences so that the Advice Taker system could make deductions.
So it was designed for the 'Advice Talker'. The AI domains were natural language processing and common sense reasoning.
The way we did AI in the 70's was well suited for Lisp. The way we do it now - with numeric-heavy techniques - isn't so much or, at least, isn't that much better than Python/scikit-learn.
Lisp (and Clojure) is still great for exploratory programming (Python too, but Lisp allows you to dive deeper).
There is basically no foreseeable way for the state-change model of language adoption to see a palpable uptick in Clojure.
Python is easier to learn. Python is more useful for data munging/cleaning (lower startup time, loads of input libraries). Python has a repl and eval so code-as-data/data-as-code is not an advantage for Clojure as it is over C-alikes. Python FFI is almost free to call into C so end-to-end performance is better than Clojure. Python has the better libraries for ANN (TensorFlow, Theano) and ML (sklearn).
Of course, you can apply "arguably" to every statement in the previous paragraph but the evidence appears to bear it out.
I currently use Python much more than any other language and regularly advocate for its use as a learning language both for formal education and for self-teaching. That said, I don't think most of the below supports your assertion that "Clojure [could definitely never] steal the machine learning niche back from Python"
> Python is easier to learn.
I have not seen a learnability comparison between Python and Clojure as first languages. Python is definitely easier to learn as a second language if you're already a trained programmer coming from the C family.
> Python is more useful for data munging/cleaning (lower startup time, loads of input libraries).
Startup time is indisputable, but also barely matters for interactive programming. In Lisps and in Python, I usually just have a repl going for days at a time.
The availability of libraries is not a "never" thing -- it's a "we'll see" thing.
> Python has a repl and eval so code-as-data/data-as-code is not an advantage for Clojure as it is over C-alikes.
You're conflating two different things that people like about Lisps here. Homoiconicity is a separate benefit from having a repl. And though I use it daily, I think Python's repl kind of blows.
> Python FFI is almost free to call into C so end-to-end performance is better than Clojure. Python has the better libraries for ANN (TensorFlow, Theano) and ML (sklearn).
Clojure is free to call into Java. And I'm sure there's a route to C if that small performance boost really makes a difference for what you're doing. Again, availability of libraries is an obstacle, but not a "definitely never" obstacle.
Well these are the hurdles that Clojure needs to get over. And it's not good enough that Python fails because R and Julia are competing with Python. So is Matlab. So to take the ML pole position, Clojure would need to gain traction beyond all of these.
So I don't have a reasonable doubt when I say "Clojure will take not the machine learning niche from Python."
I don't think it's likely. The libraries are the real issue. It's not that they couldn't emerge, it's just that they're not likely to emerge out of the current situation.
Actually, it would be even harder for Clojure to overtake Python: appearance of new ML libraries for Clojure is not enough.
Look at Torch for example. It has been a well established library, and yet because it uses Lua, its future is bleak. PyTorch, on the other hand, is gaining popularity.
Oddly, as someone who was reasonably into Common Lisp, what really viscerally turned me off to Clojure was the use of square brackets.
This sounds petty but I actually have some rationalization for it. Once you learn to read Lisp (mostly looking at the indentation and ignoring the parens) it's really nice that there's only one kind of delimiter in the language. It allows a lot of easy structure editing with a decent editor. I had emacs set up to use the unshifted square bracket keys to create and exit balanced parenthesis pairs. Once you got used to this, this was really pleasant to write and mutate code.
As soon as I saw Clojure, I knew that my setup would unavoidably get twice as complicated because they added another delimiter that's used in random places in the code. (Why are function arguments a vector instead of a list? Just because the designer thinks it looks better? Why are let bindings a vector? Why are ordinary function calls and function bodies a list? It just feels arbitrary.) That in and of itself really turned me off. (The fact that it's the JVM really didn't help either, but that was actually secondary to the above.)
Other issues for me were the lack of two layers in the LET statement (i.e. it's (let [a 1 b 2] ...) rather than (let ((a 1) (b 2)) ...). To some that probably "looks better" but it kills the ability to use emacs's transpose-sexps to swap the order of your let bindings around.
All in all the syntax just didn't seem well thought out to me. OTOH to non-lispers it probably looked better, so maybe that was the goal.
What's interesting is that for me Clojure was my first lisp. One of the main reasons I never learned lisp before Clojure was all the parens that made the language impossible to read. Clojure cleans up the "normal" lisp syntax quite a bit, and that made it a lot more palatable.
Beauty is in the eye, and all that, but CL code still makes me want to claw my eyes out.
People complain about the parens in Lisp but what kills me about Lisp in general is not the parens but the fact your brains has to read the code from bottom to top and/or right to left. This is because of prefix notation.
And while I do not like object oriented languages its far more natural to English readers such as myself to write and read things from top to bottom and left to write.
Now of course some FP languages have operators to (Haskell, F#) to allow left to right function application and you could of course make macros in Lisp in whole it doesn't really fix the problem entirely.
You can also of course mitigate the above with judicious use of let expressions but more often than not people inline anyway.
I feel the same. Clojure had lots of valuable reasons for using [] but it made it step one foot aside from the lispiness I got to like; and it's not really about editor support it's something else.. I kinda loved the idea of sexp being 99% of the idea of lisp.
Regarding the second point, why didn't you just define your own let macro?
As a Java->Clojure guy I find better readability of Clojure's let compared to CL's support of transpose an acceptable tradeoff, but the point of being a lisp is that you are not constrained by all decisions of the boss?
Well yes, in theory, but it's generally considered in somewhat bad taste to replace fundamental basics of the language. At that point you're not really writing Clojure anymore, it's hard to read other people's code, it's hard for other people to read your code, etc. See the somewhat controversial Allegro CL IF* macro for an example of this (I think that's what it was called; turns out that's really hard to search for).
It's a little different if you're either creating a domain-specific language (at that point you've already made the decision to have a new language, so go nuts) or if you're adding new control structures that you can't have in the base language without excessive boilerplate (see for example the somewhat common AIF macro, which binds its conditional result to a variable). But I'd consider making a new MY-LET macro because I don't like what the built-in LET looked like to be a bit gauche.
Regardless, I just decided to stick with the Lisp dialect that already worked the way I wanted.
Using an entirely different language because you don't want to use the macro features of the language you are using to modify a small detail due to it feeling "a bit gauche" seems much more extreme to me than just making that change... FWIW, I work with an old-school Lisp/Scheme hacker who learned at MIT and worked with some of "the greats", and he has often argued that if I really wanted Lisp to look like anything I said I liked that day I should have just done that with Lisp as at least then we would be using the same underlying execution engine, and he never seemed to feel it was "a bit gauche".
I agree, the decrease in editor-friendliness is really frustrating, coming from Lisp. The lack of parens around cond clauses is also annoying to me, because it makes it so that you can't really insert a newline after a predicate for legibility, since it makes the then-part flush with the other predicates (and similarly for let bindings).
There's nothing preventing you from manually doing that when you type the code, but editors and pretty-printers won't know about it. Special-casing them to have "if the car of a list is cond, or this vector was preceded by let, ..., then every second element gets extra indentation if it's on a different line" vs just using the regular list formatting rules just squicks me.
FWIW, running code through machine-formatting is an idea that squicks me enough that I hadn't even considered that you would be trying to do that... :(.
As a former CL dabbler I didn't mind the square brackets in let but I really liked the use of them for vector and curly braces for map. To me bringing two useful data structures beyond lists into the language syntax felt very powerful and simple.
Common Lisp does have syntax for vectors, they're written #(1 2 3). It doesn't have literal syntax for hash tables, but it's a trivial read-macro if you can't live without it (although alists have some other nice properties like easy shadowing/popping of bindings, and the kind of associations you would want to write as literals are generally small enough that their O(n) lookup isn't a problem).
CLTL2 gives a rationale for using #(...) instead of [...] for vectors:
Many people have suggested that brackets be used to notate vectors, as [a b c] instead of #(a b c). This notation would be shorter, perhaps more readable, and certainly in accord with cultural conventions in other parts of computer science and mathematics. However, to preserve the usefulness of the user-definable macro-character feature of the function read, it is necessary to leave some characters to the user for this purpose. Experience in MacLisp has shown that users, especially implementors of languages for use in artificial intelligence research, often want to define special kinds of brackets. Therefore Common Lisp avoids using brackets and braces for any syntactic purpose.
I think Clojurescript might be the thing. With advances in the Google Closure compiler, it's getting better and better. And the front end developer tools and libraries in Clojurescript are _the best_ out there. The holy grail for javascript exists in Clojurescript. Until then I'll keep making my Javascript env look like Clojurescript. With janky react devcards, Immutable.js, and react-redux.
I just finished watching this talk "ClojureScript for Skeptics" (https://www.youtube.com/watch?v=gsffg5xxFQI) that laid out the pros of ClojureScript and completely sold me on trying it out. Weird seeing this article about Clojure dying right after, too.
In this talk I watched, the speaker argues for ClojureScript for SPAs because it has:
* an excellent standard library (great functional programming so no need for lodash or other hacks, no issues with things like map(Integer.parse), solid date support, etc)
* Go-level easy concurrency
* Immutable types built-in for a fast React experience (immutable.js by default)
* built-in Google Closure Compiler for optimizing, (also with sourcemaps and devtools)
* built-in tree-shaking (only import what you use) from Google Closure Compiler
* built-in code-splitting (don't import the code for the settings page on the home page, automatically load it when the user goes there), also from Google Closure Compiler
And the talk is from 2015! So there's probably been even more added I don't know about yet.
Then again, in 2017 I feel like we have an embarrassment of riches of programming languages. I'm already playing around with Elixir (loving it), wanna try out Rust's zero-cost everythings, and have finally finishing learning Haskell on my back burner.
As someone who writes JavaScript for a living (among bits of Java and Swift), I'm loving ClojureScript. I'm currently building a side project with it. But I am still a bit skittish of Clojure (JVM). The JVM just feels slow and cumbersome compared to what I'm used to (Node.js, Erlang/Elixir, Python). The lack of good error messages is manageable when combined with figwheel on the CLJS side, but there doesn't seem to be something comparable on the server side.
I feel like Clojure needs a really good use case or story to have it become more popular. It feels really nice to program in, it's just that for specific needs - native UI programming, CLI apps, concurrent programming, data processing, web programming - other languages are better in those areas, and are good enough in other areas, that Clojure just doesn't seem compelling.
I think that Elixir's (which is really the same story as Ruby's) success is worth looking at. Elixir is really cool, but it's main hype train really doesn't have anything to do with it's technical strengths (concurrent programming) - it just has a really compelling web development story through Phoenix.
It's the startup and REPL time, typically. The JVM is super-powerful when it comes to compute tasks, but define a function on the REPL and Clojure will compile it, which is necessarily slower than what Python does.
So yeah, Clojure's faster, but perception matters. Erlang's a different case because it optimises for responsiveness for small tasks. It's very hard to write Clojure or even raw Java code as good at that as an easy Erlang program.
But yeah, a Mandelbrot set will be faster in Clojure.
I agree with you, it's the startup time. It is felt when running unit test too.
That's why JRuby is still a niche and most developers keep using MRI despite JRuby being eventually faster. It's a different example of developer happiness.
I hear this a lot from the clojure community... but I think it's a missed attempt to pivot off the JVM and have clojure be useful for more people on a more popular platform.
Missed?
Yes.
Pick a thing.
Be excellent at it.
What is clojurescript excellent at?
Its a nice language, with not very nice tooling, that is hard to maintain and significantly different from the existing javascript code base you already have, with poor interop to the existing js ecosystem (it is poor, compared to some other compile to js languages).
On the JVM, java sucks, but your choices are limited; what, maybe groovy, kotlin, scale, clojure?
Clojure has pride of place as the best dynamic language in that space.
For javascript, that crowd of alternatives is so much larger, clojurescript needs to actually be good to stand out amongst all the others.
...and I don't think it really does.
The people who use it seem to just like it as a language; and I get that, that's a thing.
...but aesthetics are personal preference and its difficult to ague they make a compelling use case.
The tooling is the best. Figwheel is hot reload that never goes down, devcards is revolutionary, and a browser repl for live in editor evaluation...
> significantly different from the existing javascript code base you already have
It actually isn't. Clojurescript is basically javascript that's immutable first, has underscore in it's core library, and then a bunch of other awesome language constructs. The libraries use the same patterns, re-frame is a nicer, more succinct abstraction over react-redux.
> poor interop to the existing js ecosystem
The interop might be the best out there. Seriously you can write javascript in clojurescript. you can straight up import es6 jsx javascript into your clojurescript code. (thanks Google Closure)
> For javascript, that crowd of alternatives is so much larger
I mean, what are the options? Clojurescript's benefits are so much more than the language. The real pluses for clojurescript are the Google Closure compiler, hot reload, browser repl, devcards, front end libraries. The language is the cherry on top. There are no alternatives that have a comparable platform not completely alien to JS developers.
I am beginner to Clojuresript/Clojure. I am not that impressed by JVM Clojure (it is bloated, slow and laggy) and frankly there are better choices on the JVM - Ex: Kotlin offers more possibilities.
But I do like Clojurescript. However, it needs to wean itself away from the all the Java tooling and not require a JDK. We need a lein/figwheel written in node CLJS. An extension that supports REPL like Lumo and step through debugging within visual studio code. A good Clojurescript book. A good React-based UI component library written in CLJS.
...but I mean, even if we accept that the things you say about clojurescript are true (and I don't agree that they are, but even if I did), the point I'm making is that it doesnt stand out from the crowd in terms of features.
Nothing you've described is something that would be missed particularly using say, typescript, webpack and npm.
ClojureScript excels when writing frontend UIs, in my opinion. There are so many good ideas in Reagent and Re-Frame. JS tries to be like Re-Frame, with Immutable.js, react-redux, etc.
> Clojure has pride of place as the best dynamic language in that space.
Yes. The only other JVM dynamic language in your list is Apache Groovy. Last month it released version "2.5-alpha-1" with Groovy's very first macro facility, something Clojure's been doing since its inception. And I can't imagine how long a version tagged "alpha-1" will take to be suitable for actual use!
You should look into Clojure Spec. It's a very nice balance of trade-offs for helping developers build correct software. While it uses a different approach than static typing, it seems a more natural fit for dynamic languages. Plus it's sort of a toolkit to be used in many different ways.
Agreed. I suspect one current thing hurting adoption from the JS community is the very heavy JVM based tooling. With the Google Closure compiler now running on top of JS, there would seem to be a path for the CLJS(not clj) tooling to become more JS ecosystem friendly.
For the JS developers out there, is this something that's of interest? Or is the existing tooling(lein) good enough? What would be your ideal tooling story?
As a JS programmer with some Clojure experience I can confirm that the JVM is absolutely the biggest turn-off for me personally. Lisp syntax, immutable data structures, laziness, all splendid. The build/runtime environment, not so much.
Sounds like I should revisit CLJS based on your comment.
As a JS developer using CLJS in my spare time, I've found that once I got my project setup with figwheel and everything, I can pretty much ignore the JVM. The moment that "classpath" is mentioned I usually try to find another way, though.
I like leiningen. The stability is something I never saw anywhere. You have plugins without updates for like 2 years and working like it was updated recently. Although it is becoming less common for clojure/script projects to be unmaintained.
I don't know. Javascript is pretty slow as it is, and clojurescript is even slower. There is an inherent problem with compiling a dynamic typed language to another dynamic typed language...if your target language doesn't have the same semantics as your source, you end up having to embed a bunch of runtime code into your compiled output, or sacrifice compatibility. [0]
With a strong statically typed language like scalajs or elm, you have a lot more static reasoning that can be done at compile time, allowing you to omit a lot of runtime support.
Having tried both I really prefer mori, mori imports some core clojure functions with it. I found working with iterators which was recommended with immutable.js very awkward.
The issue is more that I have to add, and use an immutable library vs it being just baked in to the language. I have to convert from and to JS. Worry about setting a deep value that is regular JS. It's janky is all.
> Elm, Elixir, JavaScript, seem to be better at prioritizing the humanistic aspect. Both in the affordances of the software (Elm’s famous error messages), and in person-to-person interactions.
Can't stress that enough. I have observed Elixir community and I have to say Jose and others did an excellent job fostering a healthy, friendly and warm community. That is such an essential component. That combined with standing on a solid, reliable, battle proven platform (Erlang's BEAM VM) makes for a powerful combination. You see them interact and learn, and ask for help and you think as a new comer "Right on, I want to hang out with these people". Then you run some benchmarks, check out some docs, tutorial and think "Yeah I made the right choice".
So my recommendation if you want to build programming language community - copy what Elixir did and it will be a good start. That means both community, outreach, documentation as well a technical foundation.
He gave the Simplicity Matters talks at Railsconf (https://www.youtube.com/watch?v=rI8tNMsozo0) and opened my eyes to a lot of important issues. He's accessible yet challenging.
It didn't make me want to do Clojure, but I definitely wanted to fully understand the message.
Rich Hickey is really, really smart and friendly enough, but he doesn't engage with the community nearly as much as Jose Valim or Chris McCord (Elixir and Phoenix devs) do.
Jose and Chris really go above and beyond. Almost every elixir/phoenix question I see on stackoverflow has a really solid response from one of them with not just an answer but often insights into the why something works a specific way as well.
I tried Clojure and literally within the first hour got a super ugly Java stack trace from trying to add two numbers, and that was after already being a bit miffed by JVM startup time (i'm very big on instant unit test feedback). Meh.
If you attempt to use edit/compile/restart method of development that most languages use, in the words of south park, "You're gonna have a bad time".
Clojure doesn't make it nearly clear enough that development needs to be performed interactively against a running instance of your application, with a REPL integrated into your editor. And yes tests run instantly when doing this.
That indeed was a complete turn-off. I had it in five minutes. Also, I'm sort of done with the JVM - it seems to breed large, complex things that are hard to manage. If I want a Lisp, I'll install Emacs and SBCL - there's not much the JVM has to offer that makes it a must-have.
In Clojure, you do not need (and should not) restart JVM to run unit tests. You evaluate them (manually or automatically, from the prompt or a file) inside your REPL.
The instant feedback you get from Clojure repl driven development is light years ahead of Ruby. Try sticking to Clojure, you'll see the joy of testing. Stack traces are indeed ugly.
I use Datomic everyday. While it's certainly a stunning piece of technology and you could pry it from my cold dead hands, I don't think it has that much bearing on the growth of the Clojure community.
Sure, but that's the point: if Datomic is "the best thing Clojure's got" as far as killer-apps go—and it's not really that important to the community—then Clojure doesn't really have a killer app.
A killer app is something that looks like Rails does in Ruby, or Phoenix does in Elixir: a thing where 50%-or-more of the people learning the language are only learning it in the context of using that one framework, and so often get confused as to what's a feature of the language vs. a feature of the framework.
Which is, y'know, an awful annoyance for the people who use the language for other things—but boy does it pull people in.
Clojure, and lisp in general, tends to avoid the "framework" way of thinking prevalent among object-oriented languages. It's therefore no surprise that something like Rails hasn't taken off.
There are, however, libraries and patterns which are very common, ring for example.
I'm not sure that Clojure avoids it, per se; a framework isn't something you set out to build by saying "this shall be a framework." A framework is just a library, exposed directly as functions and data in a given runtime, that has enough internal structural complexity and "active" logic that the framework offers high-level abstractions that pre-compose its components into functional arrangements, rather than expecting you to DSL-glue them together yourself.
Consider: OpenGL/DirectX are essentially "frameworks." They rely on you to specify the high-level (scenes) by calling the library APIs; the library does the medium-scale logic of managing the GPU; and then the library calls back to your code (shaders) to get the low-level details of textures and vertices specified to it. That's a framework! And there's really no way that it could be anything other than a framework.
If Clojure doesn't have any "frameworks", that's not because Clojure does something to avoid making libraries into frameworks; it's more because nobody has built a library that inherently is a framework, specifically for Clojure.
As it stands it indeed doesn't because it's closed source and not that much ends up being built around it.
Making Clojure open source but Datomic closed is, for me, still the equivalent of building a beautiful world you can wander around and explore for free forever, but whose roads and and signs all lead up to a single temple at the center, which in turn has a big sign on it saying: 'magic happens here; don't look under the covers; don't mess with it; and also... please pay.'
If that weren't the case I can only dream what people like Nikita Prokopov would be able to build and open-source around Datomic ... and the many more like him who would probably emerge from the woods if they knew their contributions could be further built upon.
I have spoken to many developers from other programming communities and many of them admire Datomic at least in principle. Hell, as an Elixir guy, the first time I had to talk to the DB was jarring because it was "oh shit, it's a deep mutable data puddle again"
Datomic should be open-source. They could always consult around it to continue making money on it.
And even if they go fully LGPL now, the perception of closedness tends to stick around. I have for years thought I'd need a license to develop commercial Qt applications and not evaluated it seriously for that reason, even though by that time it was already LGPL.
“What is right is not always popular and what is popular is not always right.” -- Albert Einstein
I love Clojure, am more productive in it than any other language (and I've done a lot in my time, including the other FP languages mentioned in this thread) but I have to concede that most people will just not like it or get it. And that's fine by me.
I also like alternative music. Most people will never like it. Most people like mainstream pop. This is also fine by me.
Oh and I certainly would never go back to a mutable-by-default language like Ruby. I mean if it works for you, do it. But I think you are crazy.
I heard somewhere that over half of developers are new to the field.
What disheartens me is that the majority of developers care very little about programming. They care about things going out the door fast, quality be damned!
I never thought of Clojure as a language that would catch on to the 90% of shops out there. That's what ruby and python are for (and of course Java, but that's for historical marketing reasons.)
What I have thought the niche of Clojure and other languages like it are larger scale projects and established places that care about robustness and correctness. Where the wishy washy ways of the pythons and rubies of the world can can a real issue when not done correctly.
I really hope it isn't dying since it's by far the most pleasant language I've ever worked in. Now that I've spent enough time on it I'd very much like to use it for the rest of my career. I suppose if it does die out there are other Lisps available despite the claim that Lisp is dead.
Why would you expected a dialect of Lisp to become popular in the Packer's and Pointy Haired Bosses Paradise (a ready-made ecosystem for sweatshops and coding factories of easily replaceable coding drones)?
A bit more seriously (which does not mean than anything in the previous paragraph is less true) the Java ecosystem has been grossly oversold from the very beginning, and even Rich himself has been converted (I still remember how I spat when I listened to his praise for Java as the best target platform in his very first marketing videos).
Clojure has been very well positioned and cleverly promoted (basically bringing decades of research by very bright people culminating in the Common Lisp to the Java Land of packers) but there was (and is) no demand for it and very few of those who could understand and appreciate the principles and ideas on which it has been founded.
It is dying for the very same reasons that the Common Lisp is still dying - The Worse Is Better or Idiots, Idiots Everywhere.
No one really needs a perfection (approaching perfection) of the great languages. The popular crap to get shit done for a paycheck (Java, Javascript, Ruby you name it) is what is in demand.
But this is rather a common pattern. This is exactly how the Upanishadic philosophy has been degraded into cryptic meaningless tantras, how Buddhism has been transformed into debased Lamaism, how western philosophy ended up with Hegelian nonsense and Marxism or what a sophisticated noise we have instead of Bach. The very same pattern. The world is dominated by idiots and will always be.
Going further, it seems like the whole category of alternative languages hit a peak about three years ago, and interest has been dwindling since. It's like coders got their fix of "new ways of thinking about code", and now have gone back to whatever they feel most productive in.
Moreover, the buzziest alt languages now (Elixir, Go, Kotlin) seem to be much closer to existing mainstream languages than the buzzy ones of a couple years ago.
Ultimately, the value of a piece of code is decided by the functionality it offers, rather than what language it is written. Thus, project with 'I made X using Y' formula, while it might be a cool personal achievement, doesn't make it go beyond the confinement of its intrinsic functionality. A web server written in clojure, doesn't make it a space rocket, and certainly not making you a rocket scientist.
Alternatively a programming language shapes your way of thinking about a problem which can in turn affect the quality of the end product. If immutable data structures and a functional approach produce easier to test, less buggy code it can be argued those language features contribute to making the world a safer place.
5 years ago it was the same applicants as today, only minus Go and Rust. Python and Ruby were strong in the dynamic region, Perl 6 was still an inside joke, C++ still dominated game development, Javascript was still the mainstay of web development, and so forth.
Ha, I'm definitely old. And you're right, the peak in alt-languages was closer to five years ago. Then came alt-databases. Next I think is alt-transactions (blockchain).
>> Someone asked if their were any Clojure failure stories.
Yes, unfortunately there are a few that I'm aware of. I don't want to go into detail, but I've definitely gotten more SOS calls than I care to count. I'm okay cleaning up messes, but Clojure allows developers to really hang themselves in ways that they can't in other languages simply because you can't do those things in other languages.
Clojure isn't an easy language to get, or rather, it is easy to reach for very complex, totally passing up the very simple tools the language gives you. The language is very simple, and I think that throws a lot of people, especially if they come from languages with more boilerplate baked in.
Personally, I love Clojure, but I never considered it practical for any team that is larger than a handful of developers, and it is certainly not safe for every developer to use. I'm using it on my current project because I'm working alone, and in keeping it small and focused, I have no plan to change that.
Is Clojure dying? I don't really know. I've never met enough Clojure developers that stuck with it long enough to move the meter to "massive uptick," so there isn't much of a down-slope relative to "alive." I've always seen it as a niche language with a wonderful community. I sometimes joke that I know all 50 people in the US who actually know how to use the language.
I really hope this isn't true, Clojure is my favorite programming language. I feel that it spoiled me. Builds are easy, code is elegant and easy to parse, functional programming combined with immutable data structures is beautiful. It also is great for "full-stack" devs in that there is little context switching between server and client.
I think the "killer app" that Clojure needs is that it should be compilable into C/C++ with the same great interop it has with Java. It would be amazing to be able to utilize all those libraries, all those frameworks, all that code... in a Clojure REPL!
Further extrapolating on this idea, it would be neat to have "one lisp to rule them all" which worked something like the LLVM where you could write a module for each language you would like to compile into and then Clojure could be the glue between all of them.
For the niche that Python enjoys (data science, devops, machine learning) there's also Hy (hylang.org) which has more or less the same syntax as Clojure. With Clojurescript, Hy and Clojure you can use Clojure syntax in all 3 major layers: front-end, scripting and compiled/back-end.
Haven't seen Hy yet, thanks for pointing it out! I have been getting back into machine learning recently and Python dominates. Great to see a Python lisp!
It is immutable and persistent, but not with the same performance characteristics. It lacks Bagwell's data structures that allow structural sharing. Take a 10 million item list in elixir and 'change' (return a new) the 5 millionth element. Time how long it takes. Do the same with clojure. Compare.
Scala has a collections library that heavily emphasizes immutable/persistent data sructures. You aren't forces to use them but it is idiomatic Scala to be "pure"/non mutating.
One of the best things about ClojureScript is the build process using lein. I've had a very stable build for years now, whereas JS has had grunt, growl, webpack, etc.
Exactly. Wave goodbye to Webpack, Babel, Redux, Gulp, Grunt, Browserify, Brunch, Yeoman and the rest of the usual suspects. I'm baffled as to why Clojurescript + Leiningen isn't the preferred way. Javascript Stockholm syndrome perhaps?
I do wonder how much the purchase of Sun (Java) by Oracle and/or the slow down in Java advancement has affected those languages that a primarily hosted on the JVM.
I always thought the Java tie-in was a double-edged sword. For some potential Clojure users, in addition to learning the language they were interested in, they'd also have to half-learn a language (and its tooling) that they probably weren't interested in.
I guess in the US there is/was an assumption that everyone coming out of the computing education system is already experienced with Java.
I feel like Clojure is more of a language that just happens to exist in the same package ecosystem as Java, and which offers a good syntax for fluently calling into the APIs those packages offer. Like Elixir with Erlang, or Rust with C.
You don't really need to know Java to write Clojure, though you do need to know things about the JVM and about the particular (Java) types that the JVM's reflection and concurrency primitives are built on. Just like Elixir still requires you to understand BEAM and OTP primitives, or Rust still requires you to understand the "C Abstract Machine" and (usually) POSIX primitives.
In at least the Clojure and Elixir cases, I don't think the runtime was chosen because anyone was expected to be familiar with the relevant abstract/virtual machine; they were chosen because BEAM and the JVM are just well-engineered VMs that have decades of research and bug-fixing and stress-testing put into them, and it's a "free win" for your language's production-readiness if you build on such a runtime. Interoperability with existing code in that ecosystem is also nice, but secondary; people using your language want to use your language, after all; if they wanted the best interoperability with Java, they'd just use Java.
(In the Rust case, [zero-overhead] interoperability with C code really was the paramount concern; but still, that's interoperability with existing C code, not the expectation that anyone would want to "take advantage of C" by writing hybrid Rust/C projects. If you're using Rust, you probably want to be writing Rust, not C.)
Yeah - I didn't mean to imply that that was Hickey's main motivation for the tie-in. Ultimately the sheer real-world prevalence of Java might make my original gripe irrelevant.
You say you don't really need to know the de-facto language of such "host" platforms, but that strikes me as putting a developer into a rather fussy and boxed-in posture if they're going to try and use the NewLang seriously/professionally.
I can't find the quote for the of me, but it was from Rich Hickey and went something like: "First, you use Clojure to escape Java. Then, you use Clojure to write better Java."
I definitely found it to be true. Clojure takes the good parts of Java's OO system.
Doesn't make any sense as Rich makes a big point of having wasted years writing large applications in Java and C++ before discovering Lisp and FP. If anything Clojure is the ultimate anti-OOP which, I think, partly explains its lack of adoption sitting, as it does, on top of a mass of libraries designed with OOP.
How can Clojure be reduced to "a better way to write Java" when you can live quite happily in Clojureland without writing a line of Java or importing a Java library?
Protocols from interfaces and multimethods from overloading. Although, to be honest, I've barely ever used them because FP is so easy in clojure. The few times I have, they make sense.
Java advancement is separate from JVM advancement.
Quite a few things (the invokedynamic bytecode for example) were added to the JVM that aren't even used in Java.
In fact Oracle has done more recently than Sun did in regards to hosting other programming languages on the JVM (see: https://github.com/graalvm/truffleruby).
I had never touched Clojure until a few weeks ago. I started learning it because Spec got me really excited and I want it or something a lot like it right now.
I spent the better part of 2013 - 2015 learning and working with Clojure. I love the language and the feeling I got solving little problems like Project Euler or 4clojure. However, I could never quite transition to feeling productive making larger projects and found myself using reverting to Scala or JS instead.
I'm try to understand how Ruby has any relation to Clojure's purported dying other than I guess a few critical things were said at a Ruby conference.
What is becoming less popular is dynamically typed languages or perhaps more correct to say languages who's types are not statically analyzed at compile time.
So if there is anything hurting Clojure I believe it is the increased uptake of languages with much better type systems than in the past (Scala, Swift, Rust, and even Go).
Particularly Go as clearly it is eating a lot of the jaded JVM crowd (that .NET core should be taking up but for various reasons have not).
Hell even Python is moving towards being more type oriented or at least having support for optional typing.
That being said I think out of all the dynamic languages Lisp, and thus Clojure are the best. I even like Elisp. Its the only time I do like a dynamic language (other than quick shell like scripts) and that is because the runtime is integrated so heavily with the development that essentially you are getting your types constantly checked (as well as auto completion and code lookup).
A lot of people who have never used the language sneer at Perl but I worked with it almost exclusively for the first 10 years of my programming career and still have a deep appreciation for the elegance of its design and the great mind that gave birth to it. Perl is the original linguist's programming language, superseded by Ruby, some would argue, which in turn was superseded by Perl6 with its built-in grammars.
I think Clojure's mistake is to sell itself as a JVM language. Sure, there are lots of people who love or need to use the JVM, but for everyone else it is a downside. There is already one language that is the queen of JVM, Java. Every other language is faded to become a second class citizen.
There is something missing in the "simple vs. easy" argument. You need to put things in the perspective of evolution.
Designing an "easy" language is easy because you can usually resort to human intuitions, yours or somebody's else. Everyone can tell your language is easy or not; although there is no single criteria of what is easy, it's still possible to come up with something that many people agree are easy.
Evolving easy languages is also not hard. Just follow the trend and keep making it easy to do whatever just became popular. Statistics, backend development, machine learning, whatever. If some early design choice turns out to be a bad move, just provide alternatives. People don't have very high expectations about the internal coherency of your langauge, so you have much freedom in evolving your language.
Designing a "simple" language is much harder because it requires a very deep understanding of the underlying structure of your runtime environment, the kinds of systems you want to build with the language, and the structure of computer programs in general. Appreciating easiness requires experience and insights, and simple things can appear complex when looking from a different perspective.
Even if you are super smart and came up with a amazingly simple language, that's only the beginning. Sooner or later, whether it's new area of programming or a design mistake surfacing, you need to evolve your language. And that is hard, because blindly adding features will destroy the simpleness and your language degenerates into an "easy" one. Instead, you need to carefully think about the natures of the new requirements, challenge the assumptions underneath the original design, and restructure your design. This process is often slow and can be more challenging than the original design process.
Of course as the article says, "simple" and "easy" is hardly a dichotomy; what I described are extreme cases, and most if not all languages fall somewhere in between and exhibit properties from both sides. But I think it's helpful to think the two dimensions in this way.
I have to say, it's been long since I searched for Hickey or clojure conf talks. Maybe that's just me and there are lots of new valuable stuff, but in a way it's hard to top cljs, core.logic, datalog in terms of brain wow.
I quit using clojure because (i) no C/C++ FFI, (ii) lack of strong type system, and (iii) horrific startup times (although clojure itself is fast, its startup time is not fast).
Once modern languages like Crystal, Elixir and probably all the rest begin to allow AST manipulation, the appeal from Lisp dialects diminishes even further as like when mainstream languages began to ship with a garbage collector.
Clojure like all Lisp is not dead or dying, it's not just for everyone, and that's fine.
I wonder if a microservice library or framework could become the killer feature to break clojure out of its niche. It could still be used by other jvm languages, possibly js languages, and wouldn't require betting the farm on it to try it out.
Clojure is a tool for people who know their doing by people who know their doing.
Just like a fine Stradivarius violin. For me the violin would be indistinguishable from an entry level violin but for the master it's a very powerful tool.
There will always be room in the market for trendy, abstracted languages like Assembly that provide simple syntax and garbage collection to sort memory management. Sometimes I think it's too user friendly though:
assembly new project
When you scaffold an app like this in assembly you hardly know what it's doing under the hood.
I thought programminggeek was making a joke. There's a high level language called Assembly? If so, it's 100% unsearchable. Or are you joking too? Got any links?
These decline and declare articles are programmers equivalent of alien-abduction tales in dive bars.
I was - sniff- abducted by a foreign framework - sniff- they made me do this - sniff- they made me learn - sniff - put there knowledge everywhere in my brain. It was horrible.
- sob -
It sounds horrific but you are not bound by oath and vow to the framework you love. You must not jump ship, you can ride two or three, depending on where your money comes from.
For me, there are a number of ideas in Clojure that I think are wonderful. I just really hate reading and writing lisp code. I can't think of a syntax I like less, unfortunately, even including junk like Visual Basic.
Funnily enough Ruby is doing not too bad - according to contributions [1] it's at stable speed since 2008 (!) without any slowdown. Similarly Rails [2] looks like healthy, steady project.
Ruby/Rails, for rapid prototyping [3] with minimal friction [4] it's still, after years, considered by many, as the best tool for the job.
[3] rapid prototypes land as production systems - that's a pro tip.
[4] minimal friction on all levels that you, as a programer care - from reading and writing code, scaffolding, dev/staging/production deployment, database migrations, testing to caching etc. - not many setups give you all of this.
I agree with you, Common Lisp does seem better and ABCL does well with Java interop (as does Clojure).
While the community around Clojure is fantastically good, I don't like the language itself as much. Personally for my hacking pleasure, Haskell, Common Lisp, Chez Scheme (or other Schemes), and Ruby are all more fun for me to use.
True, Common Lisp is better in every way, but still Clojure has its uses (in my opinion, mainly when you need to interact with a lot of Java libraries and don't want to submit to the sadism of the Java language.)
Also, the more Clojure users out there, the more people are potentially able to "jump" to the other Lisps like Racket, Arc, Scheme, and CL.
I'm still left with the question of "why all the parenthesis?"
While it might sound silly and reductionist, it is ostensibly the single hurdle I could never overcome when it came to lisp languages. The majority resides with the fact that it could work without them, so I see it as an ancient artifact.
For Lisp, parentheses are a big plus. They allow the following advantages:
TL;DR: Once you start programming in Lisp for long enough, you end up loving and embracing the parentheses.
0. They allow for an extremely simple syntax, which in turn allows the source code to easily manipulate source code. No simple syntax, no really easy way to write macros. And macros are one of the most essential keys to Lisp's power.
You can argue that, without extremely simple syntax, a Lisp language is not possible.
1. Syntax, being so simple, is extremely easy to learn. Yesterday i explained Lisp's syntax to a friend, in 3 minutes.
2. No need to care for special operator precedence rules. The precedence of operators is obvious by looking at the code.
3. IDEs, like SLIME, can easily traverse the code in many powerful ways. Due to this syntax, the IDEs can "understand" expressions and expressions within expressions. This means that the IDE can 'understand' any part of your code, not just big constructs like functions, methods or classes.
4. IDEs will also easily complete the parentheses for you, and will warn you of a missing parenthesis.
5. It is also dead simple to understand which parenthesis closes which one. It can be done with most source code editors -- Even a simple program like Notepad++ can do it, Visual Studio Code can do it, etc.
6. Parentheses also enable IDEs to automatically apply "pretty" format to the code rather easily.
7. As anything, you get used to it. Many people, for example, think that, in Python, whitespace as a block delimiter is a bad idea, however I never had any problem with that, it was just fine. Unless you are using Windows Notepad to edit code...
It's not emotional, no. After just a few months of using Lisps it feels like parentheses bring some structure and order. In non-lispy languages things feel "all over the places" - there you do have to deal with punctuation - not just parens but: semicolons, dots, commas, brackets, curlies, indentation.
Programming in a Lisp is like writing a prose. Your brain is occupied with ideas, you just need to type them down. You don't need to think about structure (until later), it's a flow - you're looking for right words (functions), you can immediately try them out in the REPL, pretty much like a writer would review usage of a word in a thesaurus or a dictionary.
But to be fair I met a few people who claimed that even after months of using a Lisp, they just couldn't get the parentheses. I dunno, guess some people's brains maybe just not suited. You can call it dyslisplexia or whatever.
I'll plug Parinfer as the best tool I've found for removing the pain of editing s-expressions. It's done wonders for my own workflow, and there's almost nothing to learn before you can use it effectively (compare to Paredit which requires you to know quite a few shortcuts before becoming productive)
I almost never have to think about the parentheses while editing, any more than I would braces in a c-like language. It's really freeing. It's also fully integrated into Cursive so there isn't even a setup step if you're using that already.
Parentheses exist because it is the easiest way to represent the raw AST in text form. S-Expressions were originally an intermediate form for a more algol-like syntax[0], but became the primary form of representing Lisp because allowing the programmer to manipulate the AST is extremely useful, arguably what makes Lisp Lisp. There are homoiconic languages like Prolog and Julia that have more familiar syntax styles, but S-Expression Lisps are unmatched in making homiconicity readily apparent.
Another reason Lisp programmers tolerate parentheses hell is that Lisp development has often paralleled that of emacs and emacs-like editors that make manipulating s-expressions extremely intuitive.
The parentheses end up serving as a tool to speed up the development process with tool like paredit. You end up manipulating the "tree" of code vs the characters on a line. Check this out: https://www.youtube.com/watch?v=D6h5dFyyUX0
Quantity is only one aspect. Structure and ability to mentally parse out patterns matters too. I don't mind Lisps and use Clojure regularly, yet I'd still argue your JS examples are easier to read than the Lisp ones.
Heck even Clojure seems to agree, just the simple act of using vectors for various things (ie function parameters) helps with the readability
Well, vectors are a workaround for the challenges in creating homeoiconic lists that the JVM understands.
And if I'm frank, the JS examples are easy to read because you're familiar with the syntax. When you first started to learn C style syntax, it was likely just as confusing. I've spent a fair bit of time with lisp now, and the parenthesis are no more or less confusing than any of the symbols used in other languages. They're just scope delimiters.
The clojure example is really (* 6 4) since * is already a function, not an operator as in most languages.
On the other hand, you can trivially create a macro that would implement the exact es2015 syntax (or at least a very close match), but why would anyone do this?
Clojure's * can accept any number of arguments, including zero (returns 1 in this case), one (acts as identity function on numbers) or more than two (returns the product of all arguments). This helps to simplify arithmetic expressions in some cases (e. g. polynominals) and allows to calculate a sum or product of any sequence, including empty one, using (reduce * xs)
It took me an afternoon to get used to the prefix notation (not to parentheses; those are used even in python), and after that afternoon I would refuse to program without it. Makes the code way more regular.
Use Emacs and optionally avail yourself of a structural editing mode like paredit. Then, at a minimum, the editor will help you match parens and you barely even have to think about them. Seriously, get over your Emacs hate (if you have any) because Emacs is to Lisp family languages what IntelliJ is to Java.
I use spacemacs. before I had to have a vim plugin in every ide. But seeing the incredible power of emacs and the ease of integrating vim with it (pretty much a "pick your style" at the beginning of spacemacs installation) I'll never go back.
Because there is no parenthesis problem; there's a newb problem. The people who complain about parenthesis haven't used a Lisp long enough, that's all. Parens are a feature, not a problem, and everyone eventually figures that out and stops complaining or they move on to a language more suited to them.
It hasn't caught on is because for all the talk about parens, they aren't really a decisive barrier, just an easy thing to latch on to, and because S-expressions are more clear (note that more algol-inspired M-expressions were the original proposed programming syntax for Lisp, with S-expressions as an behind-the-scenes representation, but programmers preferred using S-expressions directly.)
I have done two major (commercial) software projects in Python, with a good amount of code, several months of work, and I've never had ANY kind of problem with the indentation/whitespace.
Any Python IDE (like Pycharm) will easily highlight you where each section of code sits relative to the indentation level, so it's really pretty simple. Really, really simple.
I love both Lisp & Python. I'm not sure about large projects, but to me, nothing is easier to read than Python and a lot of people agree. It is so strict and authoritarian that nearly everyone ends up writing similar code. Good for sharing scripts on my team. If I write Perl, only I can understand it...and even that is temporary lol (I joke, but you get the point).
One more crippling bombshell hit the already beleaguered Clojure community when Lambda Island confirmed that Clojure market share has dropped yet again, now down to less than a fraction of 1 percent of all new code. Coming on the heels of a recent Netcraft survey which plainly states that Clojure has lost more market share, this news serves to reinforce what we've known all along. Clojure is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent comprehensive programming languages survey.
You don't need to be the Amazing Kreskin to predict Clojure's future. The hand writing is on the wall: Clojure faces a bleak future. In fact there won't be any future at all for Clojure because Clojure is dying. Things are looking very bad for Clojure As many of us are already aware, Clojure continues to lose market share. Red ink flows like a river of blood.
Due to the troubles of Lisp, abysmal sales and so on, Lisp Machines went out of business and was taken over by GigaMos Systems, who sold another troubled Lisp. Now GigaMos is also dead, its corpse turned over to yet another charnel house.
All major surveys show that Clojure has steadily declined in market share. Clojure is very sick and its long term survival prospects are very dim. If Clojure is to survive at all it will be among programming language dilettante dabblers. Clojure continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, Clojure is dead.