Yet, it's a very niche language, an almost forgotten artifact of time.
Sort of but not really.
Even though this mantra is repeated often, the greatest "cogs" actually have deep domain knowledge. That's how most mainstream programmers "level up". They become experts in the application they're developing and what it does functionally. Or in the domain in which the application operates (after having worked on several applications in the same field, for various companies).
HackerNews folks don't work in this kind of field, but in that domain Lisp is a liability. You want a plain and simple programming language, no meta programming, dumb albeit repeated code that does just what it needs to do. The rest of the brain cycles are needed to understand the often convoluted business logic ("due to this regulation the employee needs to be X", "the account is Y because our partner Zs", etc.).
On the other hand, linear algebra or “quantum mechanics” (not sure what exactly you mean in computational context) do not require DSL. For example, at least in computational chemistry and fluid dynamics things are very much FORTRAN (or C/++) under the hood (see Gaussian, GAMESS). I believe most of the linear algebra is already available for use through higher level APIs/language bindings (see BLAS/Atlas). I am not sure why one may want to learn a programming language for synthetic chemistry unless we have futuristic robo labs doing the grunt work. Perhaps I misunderstood your comment?
Synthetic chemistry language MC search language (which does use GAMESS under the hood): https://github.com/drmeister/cando
And this Mathematica plugin: http://iopscience.iop.org/article/10.1088/1742-6596/698/1/01...
Yes, go deeply enough into those "mundane" entities and you will eventually hit a abstraction strata high enough where it makes sense to apply a Lisp/functional language/<<insert favorite abstraction tool here>>.
But in the meantime, many times even the domain experts themselves don't realize there even exist higher abstraction levels of their domain. Incrementally getting there with the lower-abstraction-capable languages often better fit their organizations' staffing budgets today. Lisp programmers by and large I've found are scary-category smart. Consistently staffing that kind of smart takes bigger payroll budgets than most organizations are willing to stump up.
Today, the tooling around getting "good enough" results in most fields for most projects tends to even out whatever programmer productivity efficiencies Lisps brought to the table, enough to the point where most managers don't want to tackle the higher complexity of managing a Lisp team.
And I doubt there's anything we work more complex than human society. Even the most complex scientific models pale in comparison to real human interactions, business or otherwise.
I'd be happy to be proven wrong once we have an AI to take care of other pesky humans :)
My view is that Clojure has enough critical mass now that it's not going anywhere. There is a large community that's very active and enthusiastic about the language. There are many companies building their businesses around Clojure, and it's only going to continue to get better.
I don't think Clojure is ever going to become a mainstream language like JavaScript or Python, but that's very different from saying that it's dying.
I don't mean it's unsuited to them. My company has a developer with one year of Javascript programming experience productively working in Clojure. But, I think often about how hostile FP's vocabulary is to non-experts. (Personally, the baggage I brought from OO made FP incomprehensible for quite some time). Clojure documentation, and most tutorials aimed at it, for example, take for granted newcomers' comprehension. If we could measure the average number of languages a programmer brings to the table when he learns Clojure, I'd be willing to bet it's more than two.
Ruby and Python on the other hand are languages where beginners thrive! Not only are many of the language concepts self-evident, the communities are often driven by recently graduated beginners spawning beginner-level documentation, beginner-level sympatico, etc.
My biggest beef is actually with all the lisp true believers who wax on about their moment of clarity when all the pieces fit together and they realized that the universe is written in lisp. So far for me, it's just code.
I think the best we're ever going to see is mainstream languages like Kotlin, Swift, Ruby and Python which mix functional features with OOP. In fact Scala really falls into this category so it seems OOP is here to stay.
I wouldn't measure Clojure's success with those kind of numbers. The number of applications running Clojure code would come close to a real metric.
The whole point of Java and Python is to provide VPs with massive departments to bloat their egos with head counts. Clojure or Lisp don't aim for such goals.
And third, abstractions have costs. There is no wide-spread popular LISP, and people should really ask themselves why. We have lots of code generation, and depend on it more and more. But it’s “simple” (or “primitive”). It’s usually one step. You can read the input, and you can read the output.
I’m starting to get a sense that macros are like currying. Elegant, beautiful, powerful. But net negative if your concern is to get lots of people to create software together.
ADT DSLs + free monads or similar abstractions give you everything you need, in a more principled way.
Even as a whole it's slowing down heavily now, even Android is switching to Kotlin. The language is already not that trendy but Oracle's aggressive lawsuits is making it even worse.
Embedded software is a vast market, and it‘s mostly C with a rising share of C++.
Is it really? IoT still isn't taking off much and the more powerful the machines are getting (so every year), the less people are going to use C for that only tiny segment people are still using it for.
Where I've used C on a microcontroller 10 years ago, you would likely use a cheap Android board nowadays.
Look around your home. Right now. How many things have software in them?
How many things don‘t you see in your home? Everything in your home that doesn‘t include software has been manufactured and packaged.
My employer makes components for industrial automation. Have you ever thought about it? Nobody does, unless he has direct contact.
Building automation? Special machinery (huge presses or packaging machines). Whatever.
And re: your Android board: come back when your bricolage conforms to all kinds of requirements. Extended temperature range. Vibration. Electromagnetic compatibility (it‘s easy to accidentally broadcast in the naval emergency band). Etc. etc.
Not much as much as you think, apart from the routers, computers and phone, the only other thing I can think of is the dishwasher because it's half-recent. And I suspect the new ones just include a cheap Android board.
> And re: your Android board: come back when your bricolage conforms to all kinds of requirements. Extended temperature range. Vibration. Electromagnetic compatibility (it‘s easy to accidentally broadcast in the naval emergency band). Etc. etc.
I've worked on a company which manufactured their own card, that is much harder to do by yourself than buying a board which has been produced at millions of units where they solved all those issues directly. You can't compete with that easily. We had at least 5 iterations to solve the magnetic and heat issues, all of that comes for free in a mass-produced board.
I suspect you’re thinking at the wrong level. Your washing machine definitely does have software even if it’s not “recent”. When you press the buttons or turn the dials and it does stuff, even if it doesn’t have pretty graphics on the display, that’s software.
If you have a microwave, that has software, if you have a car that has a ton of software. Your car keys and your credit cards probably have software.
A developer board simply doesn‘t care about most of that, and if it does, to a much lower degree.
But we‘re done here, you‘re clearly not discussing in good faith. Stay in your web bubble if you want to.
Thanks for your well detailed argumentation, that was convincing.
Because your anecdotal evidence is more accurate than what this list (which describes its methodology) is showing you?
C jobs are very rare, and it's certainly not 14% of the programming jobs. Putting Java and C on the exact same level is a good sign something is wrong with what they are doing.
Most software developers don‘t hang out in internet forums, commit to GitHub or write blog posts about JavaScript frameworks. They just do their day job and go home to their family.
Outside of the web, mobile, desktop apps and even gaming (mostly C++) you mean? C is used mainly in low level computing and embed nowadays.
I've seen a fair number of metrics that show it's losing market share on a proportional basis, but holding steady on an absolute basis. Have you seen anything to contradict this?
E.g. the number of commits on Github vs percent of total commits on Github.
In JS in particular, activity is often used as a proxy for the "maintainedness" of a library. I think this is because JS is (currently) a moving target.
Clojure is one of those languages where, occasionally, problems get solved and don't require any significant further development.
Whenever Graal is mentioned, a host of reservations towards Oracle usually appears though.
I don't know how Graal will handle those two issues, it'll be interesting to watch.
Single data point, but nevertheless.
Cold Execution Times:
Java Function -> 660 ms
Native Java Function -> 460 ms
Go Function -> 470 ms
Java Function -> 30 ms
Native Java Function -> 30 ms
Go Function -> 30 ms
Java Function -> 17.8 MiB
Native Java Function -> 0.9 MiB
Go Function -> 1.2 MiB
Java Function -> 266 MB
Native Java Function -> 13.6 MB
Go Function -> 15.1 MBStill not a match for Hotspot and around me everyone still asks for .NET and Java projects.
And those data structures with indirect calls are never going to go away.
Now about all the other Clojure features...immutable, persistent collections by default, built-in async library, spec, standardized way of handling state and concurrency, and many more...
Arguably, the s-expr syntax is what enables the rich code-as-data metaprogramming that you find in Lisps. Working with full macros in a sexpr language is already complex enough, the an extra layer of complexity that non-sexpr language add really breaks that camel in half. The point is, you really need code == AST parity to make a powerful macro system workable. You don't necessarily need the parans, but complaining about parens is really missing the point.
Without that, it's certainly doable, but the result looks nothing like your non-macro code in that language.
Of course, s-expressions have a big advantage: homoiconicity. Homoiconicity enables the metaprogramming that is such a powerful and relatively unique capability of the Lisp family. But it's possible to add additional abbreviations to s-expressions to make the notation much easier to read by most software developers. Indeed, the original Lisp didn't have "quote", but no one would be happy today if you had to write (quote a) instead of 'a. (See the "LISP 1.5 Programmer's Manual" by McCarthy et al. of 1962 at http://www.softwarepreservation.org/projects/LISP/book/LISP%... ... and note that it has only QUOTE.) I think adding a few more abbreviations to the s-expression reader can make a big difference in the readability (and acceptability) of Lisps. E.g., "{a + b}" as an abbreviation for "(+ a b)" retains homoiconicity, while making code significantly easier to read for most people. For more information, see: https://readable.sourceforge.io/
Superfluous parens: Do not assume that the parentheses are superfluous, they are an excellent way to write down and communicate a tree-like structures. Code happens to be such a structure.
With regard to the readability, this probably reveals an initial training in an Algol-syntax language. It is really not self-evident that s-expr are harder to read, and find it hard to believe that is true. Most likely, if it is the case for you, it more likely means it is not leveraging years of brain-training on Algol/C style notation. Do not mistake this for anything intrinsic about s-expr.
To grab to personal experience: I have thought both Lispy and Alogly languages to complete programming virgins and have anecdotally seen less syntax-related mistakes in the former. The benefit of pre-learned infix semantics from mathematics courses is vanishingly small compared to the complexity of learning how to program. Unless your domain is actual mathematics (R, Matlab, ...), only a very small set of expressions in any program actually leverage that familiarity. The benefit in teaching/learning S-expr syntax is that is comparably uniform: whitespace breaks with paren ends. Infix languages introduce a set of context-dependent symbols. For example, a good portion of the errors I saw first timers make in class is mixing commas versus semicolon breaks. Even Python does this in the form of complex line breaking rules mixed with symbol-breaks (semicolon expression seperators, colon in conditionals, etc). It isn't hard when you are already familiar, but you definitely notice the complexity when holding the hand of a first-timer.
In short, the 'not seeing parens' is akin to not 'seeing commas, semicolons, colons, braces, parens, backspaces, ...' in Algol-syntax languages.
But honestly, things that are different should look different. Leveraging familiarity is a vital tool when designing a consumer-facing interface, but avoiding faulty preconceptions and ambiguities is more important for the professional tool that is a serious programming language. I personally think in C when handling low-level memory, Lisp when doing metaprogramming, Prolog when doing logic programming and something APL-like when doing linear algebra.
Actually, the people saying "you won't see the parentheses after a while" are a significant subset of advocates of Lisp, who know the language well! Here's a quote from the old Common Lisp FAQ: "After you've written and read enough Lisp, you stop seeing the parentheses. (Reports vary from a few days to a few weeks.) They don't disappear in some magical way, but you start to see the structure of the code rather than just "lots of fingernail clippings".
We all agree that it's important to be able to see the structure of code. But if your goal is to not see the only marker with important information, then there's a problem.
> Infix languages introduce a set of context-dependent symbols.
That is not required at all. That conflates infix with precedence. What developers want is infix, not necessarily precedence. In practice many developers avoid using precedence, in fact, a large percentage don't understand the precedence rules of the language they're using all. In Algol-like languages, they just use parens to force all evaluation orders even when they are not necessary.
If your infix system doesn't support a built-in precedence, there are no context-dependent symbols. For example, in curly-infix, {2 + 3 + 4} => (+ 2 3 4), but there is nothing special about "+". The expression {2 qwe 3 qwe 4} => (qwe 2 3 4). If you want precedence, you use another pair of curly braces to directly express it, just like you would in an Algol-like language: {2 + {3 * 4}} => (+ 2 (* 3 4)), while {{2 + 3} * 4} => (* (+ 2 3) 4). As a result, there's no dependence on context-dependent symbols, and you DO get infix.
SRFI-105, at <https://srfi.schemers.org/srfi-105/srfi-105.html>, quotes research about precedence use in "Developer beliefs about binary operator precedence" by Derek M. Jones <http://www.knosof.co.uk/cbook/accu06.html>. Some key points:
"They first measured the visible source code of a number of large C programs... only 1.9% of all expressions had at least two binary operators (where precedence would make a difference)... In those cases where precedence could have been used (the 1.9% of all expressions), 67% (102,822/154,575) of the operator pairs were explicitly parenthesized (making any precedence rule moot)."
"The authors then described a survey of developers at the 2006 ACCU conference to determine if they correctly applied the precedence and associativity of the binary operators common to C, C++, C#, Java, Perl, and PHP. In this experiment only 66.7% of the answers were correct (standard deviation 8.8, poorest performer 45.2% correct, best performer 80.5% correct); this was not much better than random chance (50%). Even many widely-used operator pairs had relatively poor results... (only) 69% when they combined / and +. These were far short of the 100% one might expect. These developers ranged from 5 to 25 years of professional experience, and the more-experienced developers did not do better (!). ... these results clearly suggest that precedence rules may harm, instead of help, the process of developing correct code."
It is, and infix notations have been added many times, going back at least to Vaughan Pratt's CGOL in the 1970s. Yet none of these notations have ever caught on very much among Lisp programmers.
I understand that the syntax is a barrier to newcomers, but there's no point in arguing that it should be changed, because one really does get used to it, and even to like it. You might as well tell the Mexicans (or Indians, or Thai, or Chinese, etc.) not to make their food so spicy. Yes, it takes some getting used to, but to change it would be to ruin it.
I feel like this helped me understand the power of "everything is/as a function" to the point of wanting to go back and try lisp again.
Sibling post suggest making Python-esq DSL on top of lisp, and I really like that idea.
Julia-lang: Hold my beer. [1]
[1] https://docs.julialang.org/en/latest/devdocs/ast/#Surface-sy...