LISP always makes me sad. It's a language from which all modern languages could learn so much (and currently a lot of features of LISP get cloned). LISP Machines pioneered basically 90% of what modern computers and the internet do today.
Yet, it's a very niche language, an almost forgotten artifact of time.
I get the impression that there's a sort of disconnect between what mainstream programmers want these days and what the Lisp community is offering. Not only in tech, but also in marketing the ecosystem.
I agree. The fraction of programmers that are tackling really challenging problems that push the limits of what's possible has probably always been small, but it has only gotten (much) smaller. Mainstream programmers don't do those things. They make websites for CRUD apps and maintain COBOL and other "obsolete" systems, solving the same well understood problems over and over. I see people writing compilers for quantum computers in LISP, compilers for automatically synthesizing complex chemicals in LISP, writing a TeX-looking, but completely dynamic scientific/math editor (TeXmacs) with LISP, writing a computer algebra system built on abstract algebra and types with LISP (Axiom/FriCAS), and writing a hyper fast scientific programming language with LISP (Julia). Mainstream programmers are just trying to maintain (and maybe modernize) systems built by their parents and grandparents. They don't need the tools that LISP offers to do that. They (or at least the people that pay them) need tools that turn themselves into easily replaceable cogs.
> need tools that turn themselves into easily replaceable cogs.
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.).
I don't know if I would call knowledge of regulations"deep". But I agree with the rest of what you are saying. I'm just want to point out that the problems most effectively aided by LISP are those that require orders of magnitude more domain knowledge about hard, subtle concepts like quantum mechanics, synthetic chemistry and abstract algebra. Those are where Domain Specific Languages become extremely useful. But, thankfully, mundane things like regulations absolutely don't need that overkill.
I don’t know if I would call regulations mundane work. In fact regulations are one of the most convoluted and more often than not ad-hoc pieces of requirements that could most certainly benefit from a DSL.
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?
The sheer quantity of edge cases, special cases and normal use cases when dealing with these "mundane" entities is a quality all its own. These use cases we automate or help automate are not by themselves all that complex normally. This is where they differ from quantum mechanics, synthetic chemistry, etc., in that use cases in those fields are usually not as accessible to the layperson.
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.
I just listed regulations, but it's not just regulations. It's regulations, business knowledge, various social aspects.
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 :)
A concrete example of a use case is F#, which is being used in the structured products business, where complex financial derivatives agreements need to be expressed mathematically in order to be valued.
Where I work, one of the benefits of Clojure is precisely how concise and accessible storing densely layered business logic is. We're able to have a faith that the code does what it looks like that just isn't approachable in any other language I know of.
In other words, they are equivalent to the people in the 1500s and 1600s using the new Gutenberg presses to reproduce Bibles. Still waiting for the explosion in computational literacy that has yet to take hold.
Clojure is past its hype phase, but it's certainly not dying. The yearly surveys consistently show more and more people using it professionally. It's used by large companies like Apple, Boeing, and Walmart for important large scale projects, and both the ecosystem and the community continue to grow at a steady pace. I've been working with Clojure for over 8 years now, and I've seen the community grow tremendously over that time.
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.
Clojure, like so many of the functional languages, struggles to attract beginners. I mean for rilz beginners.
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.
I think the rule is the more mathematics background you have the more natural functional programming will feel. Most programmers didn't take math electives in college.
I and a few others in my workplace are Clojure beginners. It's really not hard to pick up once you suck it up and stop bitching about parentheses. I don't think the language owners are terribly concerned about picking up beginners though, for all it seems they may actually like Clojure's reputation as belonging to Serious Programmers.
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.
As far as jobs are concerned I'm not sure Clojure was ever alive. Search the Indeed.com API for title:Clojure and Location:London and you'll find 10 Clojure jobs. Extend that to Location:United Kingdom and you'll find the same 10 Clojure jobs, ie. nothing outside London. For other countries it's: France:0, Germany:7, Netherlands:3, Spain:1, Italy:0, Japan:0, China:0, United States:22, Canada:2 . Elixir seems to have suffered a similar fate. In fact the only functional language which has any real adoption is Scala but even here the numbers are patchy and well below the figures for Ruby which some say is in decline.
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.
The whole point of lisp is competing with 500 programmers blub programmers with 5 lisp programmers.
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.
I find it odd to see Java and Python lumped together. The companies I've seen using those respective languages (by job listings) seem to be quite different. I'm a Python developer and I've only ever worked in small, fast moving teams (biggest team I've worked in had 4 developers).
You must not be in SF or NYC. Python and Ruby (and even Node, to an extent) have supplanted Java as the language of fungible mass-market headcount du jour.
Anecdotally I've seen quite a few job postings recently mentioning Elixir. That it can be seen, along with Phoenix, as a more performant, easier to maintain successor to Ruby/Rails gives it some legs imo.
Beyond the superficial syntax similarities and the fact that Jose Valim was a major Rails contributor I really don't get this Elixir = Ruby++ thing. The languages are poles apart, based on opposing paradigms (FP vs OOP) and data structures (immutable maps/lists vs mutable objects).
It's more about Phoenix than Elixir alone. The language is approachable enough, although clearly different, and the frameworks are similar enough (router, controllers, templates, gem -> hex, etc.) that a rails dev can become productive in this environment relatively quickly. And, the effort to do so comes with a number of serious benefits.
I am not sure about dying. Any time I need to use Clojure I have all the libraries I need and if I don't it takes me very little time to write a small wrapper around the Java library that provides the functionality. Saying Clojure is dying is the same as saying Java is dying. There are unmaintained libraries, no doubt of that, yet, it does not mean that the entire language is dying. Java8 was a great improvement for Clojure and I expect more coming down in the pipe for later Java releases.
A language cannot survive if it doesn't compete for adoption in the software industry, ie. paid jobs, and with so many languages competing for adoption Clojure's lacklustre marketing has cemented it's place in the history of also-rans. That doesn't mean Clojure isn't a great language. In fact I'd say it's the best language we have today.
Language viability isn't a zero sum game. What you ultimately care about is that the language is actively developed, and that there is a viable ecosystem around it. Clojure has both those things, with plenty of companies using it to do real world work.
You seem right. Every metric I can check says it is going downhill. Too bad, I used to go to the Clojure meetups in my area, I even had a talk about Clojure + Emacs.
Many reasons. S-expressions would be the least of my worries. Java is dying, not on the whole, but certainly in mindset of people who are picking new languages. It’s integration with OSs, which Clojure depends on, is arcane by today standards. Second, it’s tightly controlled by one person, and they happen to hate types. Similar to CoffeeScript, couple years after the language inception people figure out that they miss types. Adding them back in is super tough.
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.
Re macros, I had a similar thought this morning. Except for code instrumentation and boilerplate generation I've actually never found macros to be useful.
ADT DSLs + free monads or similar abstractions give you everything you need, in a more principled way.
> Java is dying, not on the whole, but certainly in mindset of people who are picking new languages
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.
I did not say that it's still not used heavily, just that it's slowing down. And C is the second on that list so I'm not sure I would believe this ranking, I have not seen much C jobs for a while now.
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.
> Look around your home. Right now. How many things have software in them?
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.
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.
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.
Battery charger. Camera. Camera lenses. TV. Blu-Ray player. HiFi/audio system. Radio. Dimmable lamps (probably). Electric toothbrush. Shaver. Possibly electric kettle. Blender. KitchenAid. Telephone (the wired one). Possibly door opener. Rice cooker. Garage door opener. Coffee machine. Toaster.
You post a lot of great submissions to HN, but if you continue to be uncivil in comments we're going to ban you. This is the second time I've had to warn you in as many days. Not cool!
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.
C jobs are certainly much more than 14%. Believe it or not.
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.
It most definitely is large. It's not just about all of the recent IoT devices. Firmware for all of the controllers on your motherboard is written in C. Most device drivers are still written in C. Many operating systems (linux) are written in C. Then you have all of the controllers in the devices in your home (e.g. microwave, oven, digital clock, entertainment devices, etc.)
Feel free to show me a link to a site with a better methodology to support your claim. Otherwise I'm going to continue believing you lack evidence to support said claim and are therefore wrong.
> Every metric I can check says it is going downhill.
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?
Shouldn't the proportion be your concern (assuming you actually have a horse in the race)? Steady absolute numbers basically indicates that nobody new is choosing it, which is just the first step to a decline of those absolute numbers.
Having just learned Clojure, I'm kinda sad to say that I agree... It kinda seems like there are a lot of unmaintained libraries and relatively few things being worked on (mostly in the web-tech space which I don't really know anything about)
I've come across my share of unmaintained libraries in Clojure, but for anyone reading, lack of activity doesn't necessarily mean that a library is unmaintained.
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.
Was about to say the same thing. It took a little while to get used to the idea that seeing `Last updated 2 years ago` didn't mean the library was dead. If I ask in the slack channel about a library I'll very often get a message back in a matter of minutes from the author confirming that it still works.
For me personally I gave up on Clojure because of the JVM. Had there been a Clojure, supported by its main author and community compiling to native, it'd probably be my main language today.
My concerns about the JVM aren't so much CPU, but memory usage and ease of distribution. Those two factors have, IMO, helped take golang where it is today. Today you cannot run your Clojure apps on a small 250 MB VM, and distributing it means getting the right version of the JVM, the right libraries etc...
I don't know how Graal will handle those two issues, it'll be interesting to watch.
That's really an interesting project, thanks for sharing!
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...
Modern languages have learned a lot from Lisp. In fact they've stolen just about every major feature from it, except for s-expr syntax. Which should tell you something about s-expr syntax.
Any language adopting s-expr would instantly be called a Lisp.
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.
As it turns out, you can have a powerful macro system without s-expr syntax (e.g. Scala, Nim). In any case, you jus need to write functions that operate over trees, which you can do in any language. That this tree is not immediately reflected in the actual syntax is just a minor hindrance
What problems do you run into? I'm familiar with lisp's macro system but didn't get to look into hygienic macros in other language, and was wondering if they are equivalent.
It tells me that the vast majority of software developers do not want to read or maintain code in raw s-expression format, for the same reason that the vast majority of software developers do not want to read or maintain code in machine code. S-expressions and machine code run, but when the argument is "you won't see the parentheses after a while" then clearly the parentheses shouldn't be there in the first place. For example, normal people find "a + b" easier to read than "(+ a b)", because they receive 12-18 years of training in infix notation AND practically all materials with math (books, papers, etc.) use infix. Lisp's current s-expression syntax is simply unacceptable to most software developers.
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/
I am tired of seeing this programmer's meme constantly being repeated.
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.
> 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.
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.
"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's possible to add additional abbreviations to s-expressions
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.
Maybe it's valid to think of Python (and Javascript, and R, etc) as a DSL, where the Domain is very large, almost as large as Lisp itself, but not quite, just missing the elegant metaprogramming. A DSL for "easy-to-use coding by non-Lispers".
To my knowledge, every inflix operation in R has a corresponding function. Together with the pipe operator, this is really, really nice, and is kinda similar to what you propose, but perhaps the other way around, so to speak.
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.
Yet, it's a very niche language, an almost forgotten artifact of time.