Is Clojure dying, and what has Ruby got to do with it?(lambdaisland.com)
lambdaisland.com
Is Clojure dying, and what has Ruby got to do with it?
https://lambdaisland.com/blog/25-05-2017-simple-and-happy-is-clojure-dying-and-what-has-ruby-got-to-do-with-it
260 comments
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
paredit doesn't require parentheses to do it's magic.
There seems to be a very nice solution to the parenthesis problem: https://sourceforge.net/p/readable/wiki/Home/
I have no idea why it hasn't caught on. As far as I'm aware, there's no Clojure implementation. Lispers like their parentheses.
I have no idea why it hasn't caught on. As far as I'm aware, there's no Clojure implementation. Lispers like their parentheses.
Perhaps because significant white space (e.g. Python) has quite a lot of detractors of its own.
I absolutely cannot stand significant whitespace... it is a step back in almost every area of usability.
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).
If you love Lisp & Python try Hy (hylang.org).
Why?
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 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.
This is a much more approachable syntax, reads much like a mix of Ruby and Python
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.)
(we) lispers LOVE our parentheses.
"Elegant weapons... for a more civilized age."
Ref: https://xkcd.com/297/
"Elegant weapons... for a more civilized age."
Ref: https://xkcd.com/297/
I love that particular xkcd
I'm not even a lisper.
I'm not even a lisper.
> I have no idea why it hasn't caught on.
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.
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.
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.
[0] https://en.wikipedia.org/wiki/M-expression
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.
[0] https://en.wikipedia.org/wiki/M-expression
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 don't hate emacs, I have however invested a lot more time and work into vim than emacs so that is why I do not use it.
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.
the only reason i didn't like spacemacs was the 3 keystroke combos for everything that I do with 2 strokes in vim.
Yea...I like the theory of emacs, but the reality of vim usage.
SLIME (for Emacs) is wonderful. I like Emacs, what i don't like is the key combinations, which are horrible.
Fortunately, you can redefine them. Emacs can be customized at will, and using Lisp :)
Fortunately, you can redefine them. Emacs can be customized at will, and using Lisp :)
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.
https://shaunlebron.github.io/parinfer/
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.
https://shaunlebron.github.io/parinfer/
I feel most syntax themes are designed for syntax based languages and make the parenthesis far too dark/prominent and it's visually overwhelming.
If you dial back the color of parenthesis and brackets to a lighter grey, the experience is almost like writing python with parinfer.
If you dial back the color of parenthesis and brackets to a lighter grey, the experience is almost like writing python with parinfer.
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...
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...
This is more an emotional response to me than it is functional or logical one since you can apply all of these points to any other language.
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.
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.
Contrast, for a moment:
Let's try something a bit harder.
Yes, "why all the [symbols]" indeed.
var x = fib(a, b);
(let x (fib a b))
Let's try something a bit harder.
function(a, b) {
return a * b;
}(6, 4);
((fn (a b)
(* a b)
) 6 4)
Yes, "why all the [symbols]" indeed.
[deleted]
For your second example, your JavaScript is wrong. Let's compare the ES2015 JavaScript:
((a, b) => a * b)(6, 4);
((fn [a b] (* a b)) 6 4)
If we're golfing...
(#(* %1 %2) 6 4)And a bit shorter version...
24
;)
24
;)
I wonder, does #(* %1) do anything sensible?
> I wonder, does #(* %1) do anything sensible?
It's a 1-argument function, so applying it to 2 arguments would give an error. Minus the arity error, 1-argument * is an identity.
It's a 1-argument function, so applying it to 2 arguments would give an error. Minus the arity error, 1-argument * is an identity.
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)
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?
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?
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
Heck even Clojure seems to agree, just the simple act of using vectors for various things (ie function parameters) helps with the readability
((fn [a b]
(* a b)
) 6 4)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.
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.
I disagree. The JS is easier to read because it has an easier to parse structure. I've been coding in clojure for several years now.
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.
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.
I think that's more an indication of _just how much the needle has been moved_.
5 years ago mainstream was something like PHP or Java 6.
5 years ago mainstream was something like PHP or Java 6.
Err, maybe 15 years ago, sure.
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.
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.
I don't think Rust's usage is large enough to fit into that category although it is growing and its followers are very devoted.
Go was around and buzzy (closer to the peak, even) 5 years ago.
Apologies if I've made you feel old!
Apologies if I've made you feel old!
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).
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.
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.
[1] https://trends.google.com/trends/explore?q=%2Fm%2F0_lcrx4,%2...
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.
[1] https://trends.google.com/trends/explore?q=%2Fm%2F0_lcrx4,%2...
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.
While not on the list above, there are certainly others like Opal (Ruby in js)
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
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
[deleted]
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.
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.
Also, WASM is just around the corner, which will probably make this a non issue.
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.
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.
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.
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.
To the best of my knowledge, there's no GC in WASM.
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.
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.
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.
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 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.
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 know for me the combination of RoR and the MacBook Pro caused me to never look back
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.
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.
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.
[deleted]
Lisp used to be the language for AI, could Clojure possibly steal the machine learning niche back from Python?
Definitely never.
Explain?
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.
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.
> 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."
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.
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.
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...
ML takes the needs for Lisp more-less in the same way Entity-Component-System architecture takes the needs for C++ and C# programmers...
> Lisp was invented by the guy who coined the term AI, not for AI.
Lisp was designed for AI programming.
http://www-formal.stanford.edu/jmc/recursive/node1.html
> 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.
Lisp was designed for AI programming.
http://www-formal.stanford.edu/jmc/recursive/node1.html
> 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.
> Lisp used to be the language for AI
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.
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.
Our industry is strange :).
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.
Our industry is strange :).
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)
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).
Have you played around with Numba (http://numba.pydata.org/)? It's speedy.
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.
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.
Incanter is not the only game in town, FYI.
For example? Not being snarky, just want to know what you'd recommend.
Dragan has an excellent platform for Bayesian Data Analysis:
https://github.com/uncomplicate/bayadera
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.
https://github.com/uncomplicate/bayadera
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).
[deleted]
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).
Lisp (and Clojure) is still great for exploratory programming (Python too, but Lisp allows you to dive deeper).
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 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.)
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.
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.
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.
ok, found it: https://stuartsierra.com/2008/08/08/clojure-for-the-semantic...
I think it was in reference to the java ecosystem, more than "a better way to write java," although I still see it that way.
I think it was in reference to the java ecosystem, more than "a better way to write java," although I still see it that way.
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?
> Clojure takes the good parts of Java's OO system.
Such as?
Such as?
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).
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).
clojure's killer app, datomic, is closed source
in my opinion, this is a key reason, why clojure is not thriving
i can't think of any (problem) domain, where clojure have a framework or library, than is significantly better than most other frameworks or libraries
if you are not number 1 at anything, it is hard to thrive
in my opinion, this is a key reason, why clojure is not thriving
i can't think of any (problem) domain, where clojure have a framework or library, than is significantly better than most other frameworks or libraries
if you are not number 1 at anything, it is hard to thrive
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.
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.
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.
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.
[deleted]
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.
Datomic should be open-source. They could always consult around it to continue making money on it.
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.
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.
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.
Agreed. I love work with clojure but no way I will pay a small fortune for a Datomic license.
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.
Is Ruby supposed to be an example of "not dying" language? Because it has certainly passed its glory days as well.
Also Common Lisp is better in every way ;) There's even a JVM implementation (ABCL) for people who like that sort of stuff.
Also Common Lisp is better in every way ;) There's even a JVM implementation (ABCL) for people who like that sort of stuff.
I don't know but it seems to me Ruby is dying the same way anything else with 200,000+ questions on Stack Overflow is dying (i.e. it isn't).
David, you have to put more bugs in ClojureScript - we need way more questions on StackOverflow ASAP! :)
... and 134,468 gems at a rate of 33 per day (http://www.modulecounts.com).
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.
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.
Does anyone actually use Arc? Racket, Common Lisp, Clojure, Picolisp even yes. Arc was just used for this forum right and is based on Racket?
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.
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.
If I remember correctly, you showed some kindness towards Clojure (the language). May I ask, what made you reconsider?
Why do you consider Common Lisp better in every way?
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.
[1] https://github.com/ruby/ruby/graphs/contributors
[2] https://github.com/rails/rails/graphs/contributors
[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.
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.
[1] https://github.com/ruby/ruby/graphs/contributors
[2] https://github.com/rails/rails/graphs/contributors
[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.
> Is Ruby supposed to be an example of "not dying" language? Because it has certainly passed its glory days as well.
It may have past the (or a local) hype peak, but it seems to be doing just fine. Not being the edgy flavor of the month isn't the same as dying.
It may have past the (or a local) hype peak, but it seems to be doing just fine. Not being the edgy flavor of the month isn't the same as dying.
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.
Well, clojure is better designed than javascript, that's for sure. But the holy grail for me would absolutely need static typing.
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?
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.
Sounds like I should revisit CLJS based on your comment.
Well at the moment, the tooling is all lein/JVM based.
That said, Figwheel hooked up with atom+protorepl+parinfer is pretty amazing if you haven't tried it.
https://github.com/bhauman/lein-figwheel
https://www.youtube.com/watch?v=0WMga5E7Vsk
That said, Figwheel hooked up with atom+protorepl+parinfer is pretty amazing if you haven't tried it.
https://github.com/bhauman/lein-figwheel
https://www.youtube.com/watch?v=0WMga5E7Vsk
Parinfer is a huge game changer. Everyone afraid of writing lisp needs to try again using parinfer.
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.
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.
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.
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.
In fact, I would say that if ClojureScript's interop with React Native could be made to be much smoother, that would be a real killer app.
> The JVM just feels slow and cumbersome compared to what I'm used to (Node.js, Erlang/Elixir, Python)
In what regard? Because the JVM is faster than all of the above.
In what regard? Because the JVM is faster than all of the above.
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.
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.
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.
JVM startup time is typically sub-second. Anything above that is not the JVM, it's something else.
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.
[0] http://www.lihaoyi.com/post/FromfirstprinciplesWhyIbetonScal...
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.
[0] http://www.lihaoyi.com/post/FromfirstprinciplesWhyIbetonScal...
JavaScript slow? Compared to what? ClojureScript is within 10-20% of JavaScript or less (virtually the same).
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.
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.
> with not very nice tooling
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.
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 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.
> The tooling is the best.
No, it's really not.
Have you tried other ecosystems? You should. If clojure is the best tooling you've ever used, look around, there's a wide world out there.
Heck, even the article linked above from lambdaisland lists tooling as one of the issues clojure suffers with.
> I mean, what are the options?
Haxe. Dart. Typescript. Elm. Scala. LivesSript. ES6. CoffeeScript. Flow. PureScript. ...
There must be what, 50 odd listed on https://github.com/jashkenas/coffeescript/wiki/List-of-langu...
...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.
No, it's really not.
Have you tried other ecosystems? You should. If clojure is the best tooling you've ever used, look around, there's a wide world out there.
Heck, even the article linked above from lambdaisland lists tooling as one of the issues clojure suffers with.
> I mean, what are the options?
Haxe. Dart. Typescript. Elm. Scala. LivesSript. ES6. CoffeeScript. Flow. PureScript. ...
There must be what, 50 odd listed on https://github.com/jashkenas/coffeescript/wiki/List-of-langu...
...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.
> What is clojurescript excellent at?
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.
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.
How much experience do you have with ClojureScript and other compiled to JS languages?
A lot. We use clojurescript and ES6 in production.
(the clojurescript is now considered 'legacy')
(the clojurescript is now considered 'legacy')
> 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!
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!
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.
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.
Also super easy hot reloading with figwheel.
Literally just 'lein new figwheel' and you've got a project ready for everything you mentioned with hot reloading ready to go
Literally just 'lein new figwheel' and you've got a project ready for everything you mentioned with hot reloading ready to go
Immutable.js when mori.js is available? :)
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.
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.
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.
I feel that Rich Hickey alone makes the Clojure community very healthy, friendly and warm. The JVM is solid, reliable and battle proven, is it not?
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.
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.
To me the JVM is battle proven unreliable and fidgety to use.
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.
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.
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.
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.
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.
Anything else is pure pain.
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.
Anything else is pure pain.
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.
Ultimately a thoughtful read.
Clojure's "killer feature" for me is the by-default persistent data structures.
Are there any other functional languages out there with similar features? Lisp or otherwise.
Are there any other functional languages out there with similar features? Lisp or otherwise.
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.
Erlang/Elixir also is immutable & persistent by default.
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.
That was true a few years ago, but not anymore: https://medium.com/@jlouis666/breaking-erlang-maps-1-31952b8...
(You would have to use a map though, the native lists are still plain old lists)
(You would have to use a map though, the native lists are still plain old lists)
[deleted]
Elixir has that, and you can't even drop into Java/JVM mode to violate it! ;)
Haskell as well, I believe.
Haskell as well, I believe.
In Haskell, data structures are immutable, persistent, and use structural sharing by default.
This is odd. I find myself moving to Assembly nowadays.
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
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 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.
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.
Certainly not this, but it's a great tune anyway: https://www.youtube.com/watch?v=8PLE3IjTRb8 - The Wurzels, Ruby
^ <step here> ^
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.
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.
Is this an ironic homage to some piece of alarmist writing about something else? If not, it seems way over the top. It was pretty fun to read though.
I feel old now: https://everything2.com/title/BSD+is+dying
This is great! Thanks for educating me :-)
Thank you for educating me too :)
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.
Damnit i put my life savings on clojure stocks!!
[deleted]
Was it that off the mark, though?
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?
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?
Thanks to their license model, lots of companies make use of BSD on their hardware and seldom give anything back.
Please don’t troll post.
This post is like reading a CNN kind of site which posts latest "what we know so far" every few minutes about some breaking news :)
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.
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.
That analogy can be used both ways!
"I'm an artist, and if you give me a tuba, I'll bring you something out of it” - John Lennon.
"I'm an artist, and if you give me a tuba, I'll bring you something out of it” - John Lennon.
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.
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.
[deleted]
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?
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.
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".
The source to if* is at (https://franz.com/~jkf/ifstar.txt).
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).
I don't understand: why can't you add a newsline andan indent?
(cond
(whatever)
(thing)
(something)
(more))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... :(.
Emacs is awesome, but making language design decisions based on Emacs (or any editor, for that matter) seems like it ought to be at best a non-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.
Beauty is in the eye, and all that, but CL code still makes me want to claw my eyes out.
Dim the parens in your editor. It helps if you're not used to them already.
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.
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.
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.
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.
So, a keynote on conference about a dying language has mentioned that another, unrelated language is dying. And people are taking notice.
It does not make sense.
It does not make sense.
This was a really well written article. Nice to see the nod to Larry Wall's excellent talk on postmodern languages.
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.
Yea...really wish Perl6 was more polished now.
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.
Yup, front end development is light years ahead of JS. sad
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?
It's true of everything in life. The best is never the most popular. The most popular is often, frankly, crap. Why would programming be any different?
Don't look for such an elaborate explanation, it's just the parentheses that set most JS programmers off
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!
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.
Yes, I know there is Chicken Scheme and Guile. I prefer Clojure over them though.
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!
That's the point, Clojure would not die if it were compilable in C / C ++ or had better startup time.
I used to love clojure, I think it has some great ideas, but I switched to Racket because of the lack of two features.
I don't think I'm the only one who did it.
I used to love clojure, I think it has some great ideas, but I switched to Racket because of the lack of two features.
I don't think I'm the only one who did it.
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.
Within the monthly HN "who is hiring" posts, Clojure and Ruby appear mostly flat[1], albeit with Ruby at a much higher level.
[1] http://www.ryan-williams.net/hacker-news-hiring-trends/2017/...
[1] http://www.ryan-williams.net/hacker-news-hiring-trends/2017/...
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).
“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 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.
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.
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.
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.
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.
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.
Front page rank #22 (after 18hs) with 208 points and 192 comments on HN on a dying language.
Shouldn't <put dying thing here> be met with a lack of interest?
Shouldn't <put dying thing here> be met with a lack of interest?
Some funerals are attended by a large number of people.
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.
>> 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.
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.
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.
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'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).
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).
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.