Err I would think the likes of C/Python/Java still being out there with jobs available in some decades are much higher than any Lisp language.
In fact there are probably more Cobol jobs than Lisp jobs today. After having played with Clojure (as in, read the book, and did some systems) I still don't know what the kool aid is about.
Maybe is because I have been doing python for a long time...
Jobs. You can build a house employing a crew of contractors. But would you let them redesign your garden? Perhaps, you wouldn't. They'd destroy it by walking around in their heavy-duty boots. There always will more jobs for contractors and fewer jobs for gardeners.
Going back to using Emacs as an example: You know that no one, not a single developer involved in Emacs, has ever gotten paid for it¹ to do it? There are precisely 0 jobs on the market for working on Emacs.
However, I agree with you on one thing - Lisp is a hard-sell if you've never done it before. It took me a few years to finally understand what the "kool-aid" is about.
I don't think I understand what you are trying to say :)
Either you're saying that the real garden designers can only use Lisp as a tool or you're saying that no other popular OSS projects have been mostly developed by volunteers.
Both cases aren't true so if you're trying to say something else then please elaborate.
I'm saying that measuring the success of a software language/methodology/tool in the long run (decades of time) based on the popularity of it at any given point in time is useless.
Also, I'm saying: Lisps allow you create "gardens", ergo would always require fewer people to build, grow and maintain projects. And in the long run, ROI from choosing Lisp would be much higher, even though languages that typically require more people would be always more popular.
It's a known fact - to build and support big Java projects you need to have in order of magnitude more people than to build similar projects with the same set of features in Clojure. ROI from choosing Clojure is higher. Although Java "generates" more jobs.
Disagree with me on what? That Clojure typically requires fewer people for projects of similar size?
There are plenty of companies building awesome, successful projects in Clojure today with teams of fewer than 10 engineers in them:
CircleCI, Pandora, Clubhouse.io, Walmart Labs, Apple, Pitch, Cisco, Gramarly, Ladder - these are just a few that come to mind.
All the other things I mentioned previously are simply facts, except the main point: "I haven't seen systems, built in other languages that are sufficiently malleable." That is an opinion.
I yet have to see a successful, big Java/C# project that withstands the test of time and built with a team of just a few engineers.
Yes. Clojure is just a tool. A programming language. Just like Emacs Lisp. And Emacs Lisp from a technical point of view is one of the worst programming languages you can think of:
- It has no static types
- Has no namespaces
- Until recently it didn't even have lexical scoping
- Its execution time is painfully slow
- It's a Lisp. The syntax of which many engineers describe as "harder to read"
- Majority of Emacs-lisp packages (like over 95%) don't even have any kind of automated tests
You pick just any kind of programming language with these traits and sooner or later any significant project would be buried under its own weight and would have to be re-written in a different, more modern language. Like I said before: "Emacs ecosystem defies any logic - it shouldn't work at all, yet it does."
Modern programming languages emphasize the need for IDEs with extensive re-factoring/re-structuring tools. Lisps somehow for decades didn't really require them. The only thing they need is structural editing tools and even that is an optional gimmick.
You ever thought about why no-one successfully was able to replicate and re-build a fully-featured clone of Org-mode outside of Emacs? There were several attempts, all of them are pretty lame (compared to one written in emacs-lisp).
You ever thought why every single attempt to re-write Emacs or create "a killer of Emacs" was unsuccessful?
I understand your skepticism. And I'm not selling this as some sort of "universal truth", I'm just telling you from my own experience. I am not one of those Lisper zealots who learned it years ago, I discovered it fairly recently. I avoided Lisp for a very long time. I've seen big projects in many PLs - ranging from Turbo Pascal/Delphi to Java, Python, etc. And I've seen big and really badly structured, extremely messy Clojure codebases.
There's something about Lisp that makes it extremely suitable to create big, malleable systems that can grow indefinitely. Something that I somehow never experienced with other languages.
In fact there are probably more Cobol jobs than Lisp jobs today. After having played with Clojure (as in, read the book, and did some systems) I still don't know what the kool aid is about.
Maybe is because I have been doing python for a long time...