Is Clojure dying, and what has Ruby got to do with it?
lambdaisland.com
lambdaisland.com
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.
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?
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...
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
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.
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.
That all said, I think all 'piles-to-JS language bets are off in the face of WASM.
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.
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.
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.
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.
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.
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.
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.
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.
So I don't have a reasonable doubt when I say "Clojure will take not the machine learning niche from Python."
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.
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 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.
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.
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 :).
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)
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.
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.
Lisp (and Clojure) is still great for exploratory programming (Python too, but Lisp allows you to dive deeper).
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.
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?
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.
(cond
(whatever)
(thing)
(something)
(more))Beauty is in the eye, and all that, but CL code still makes me want to claw my eyes out.
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.
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.
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?
Sounds like I should revisit CLJS based on your comment.
That said, Figwheel hooked up with atom+protorepl+parinfer is pretty amazing if you haven't tried it.
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 what regard? Because the JVM is faster than all of the above.
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.
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.
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...
Missed?
Yes.
Pick a thing.
Be excellent at it.
What is clojurescript excellent at?
Its a nice language, with not very nice tooling, that is hard to maintain and significantly different from the existing javascript code base you already have, with poor interop to the existing js ecosystem (it is poor, compared to some other compile to js languages).
On the JVM, java sucks, but your choices are limited; what, maybe groovy, kotlin, scale, clojure?
Clojure has pride of place as the best dynamic language in that space.
For javascript, that crowd of alternatives is so much larger, clojurescript needs to actually be good to stand out amongst all the others.
...and I don't think it really does.
The people who use it seem to just like it as a language; and I get that, that's a thing.
...but aesthetics are personal preference and its difficult to ague they make a compelling use case.
The tooling is the best. Figwheel is hot reload that never goes down, devcards is revolutionary, and a browser repl for live in editor evaluation...
> significantly different from the existing javascript code base you already have
It actually isn't. Clojurescript is basically javascript that's immutable first, has underscore in it's core library, and then a bunch of other awesome language constructs. The libraries use the same patterns, re-frame is a nicer, more succinct abstraction over react-redux.
> poor interop to the existing js ecosystem
The interop might be the best out there. Seriously you can write javascript in clojurescript. you can straight up import es6 jsx javascript into your clojurescript code. (thanks Google Closure)
> For javascript, that crowd of alternatives is so much larger
I mean, what are the options? Clojurescript's benefits are so much more than the language. The real pluses for clojurescript are the Google Closure compiler, hot reload, browser repl, devcards, front end libraries. The language is the cherry on top. There are no alternatives that have a comparable platform not completely alien to JS developers.
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.
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.
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.
(the clojurescript is now considered 'legacy')
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!
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.
Literally just 'lein new figwheel' and you've got a project ready for everything you mentioned with hot reloading ready to go
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.
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.
It didn't make me want to do Clojure, but I definitely wanted to fully understand the message.
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.
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
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.
There are, however, libraries and patterns which are very common, ring for example.
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.
Datomic should be open-source. They could always consult around it to continue making money on it.
Making Clojure open source but Datomic closed is, for me, still the equivalent of building a beautiful world you can wander around and explore for free forever, but whose roads and and signs all lead up to a single temple at the center, which in turn has a big sign on it saying: 'magic happens here; don't look under the covers; don't mess with it; and also... please pay.'
If that weren't the case I can only dream what people like Nikita Prokopov would be able to build and open-source around Datomic ... and the many more like him who would probably emerge from the woods if they knew their contributions could be further built upon.
I 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.
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.
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.
I'd love to know where you learned this, or why you believe this. I'd be very interested to hear what he had to say about the change of heart.
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.
5 years ago mainstream was something like PHP or Java 6.
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.
Apologies if I've made you feel old!
Yes, unfortunately there are a few that I'm aware of. I don't want to go into detail, but I've definitely gotten more SOS calls than I care to count. I'm okay cleaning up messes, but Clojure allows developers to really hang themselves in ways that they can't in other languages simply because you can't do those things in other languages.
Clojure isn't an easy language to get, or rather, it is easy to reach for very complex, totally passing up the very simple tools the language gives you. The language is very simple, and I think that throws a lot of people, especially if they come from languages with more boilerplate baked in.
Personally, I love Clojure, but I never considered it practical for any team that is larger than a handful of developers, and it is certainly not safe for every developer to use. I'm using it on my current project because I'm working alone, and in keeping it small and focused, I have no plan to change that.
Is Clojure dying? I don't really know. I've never met enough Clojure developers that stuck with it long enough to move the meter to "massive uptick," so there isn't much of a down-slope relative to "alive." I've always seen it as a niche language with a wonderful community. I sometimes joke that I know all 50 people in the US who actually know how to use the language.
I 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 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.
Are there any other functional languages out there with similar features? Lisp or otherwise.
(You would have to use a map though, the native lists are still plain old lists)
Haskell as well, I believe.
I guess in the US there is/was an assumption that everyone coming out of the computing education system is already experienced with Java.
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 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 definitely found it to be true. Clojure takes the good parts of Java's OO system.
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.
Such as?
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).
It does not make sense.
[1] http://www.ryan-williams.net/hacker-news-hiring-trends/2017/...
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).
Shouldn't <put dying thing here> be met with a lack of interest?
I think that only works for concrete things, so in OO that would read: objects can die, classes can't.
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.
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.
"I'm an artist, and if you give me a tuba, I'll bring you something out of it” - John Lennon.
assembly new project
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.
Also Common Lisp is better in every way ;) There's even a JVM implementation (ABCL) for people who like that sort of stuff.
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.
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.
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.
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.
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.
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 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.
"Elegant weapons... for a more civilized age."
I'm not even a lisper.
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.
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.
Fortunately, you can redefine them. Emacs can be customized at will, and using Lisp :)
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.
If you dial back the color of parenthesis and brackets to a lighter grey, the experience is almost like writing python with parinfer.
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...
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.
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.
((a, b) => a * b)(6, 4);
((fn [a b] (* a b)) 6 4)
(#(* %1 %2) 6 4)24
;)
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.
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?
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)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.