Was Pascal a failure? Lots of programs were written in it. It had killer apps. Lots of programmers learned it. It made its way into the education system.

Lisp might be viewed similarly. It’s not a fad and big companies don’t use it widely, but does that make it a failure?

Google uses Common Lisp. (They even host a style guide!) So does Rigetti Computing making quantum computers. So does/did DWave, another quantum company. There are a handful of companies that have existed between 15–30 years developing Lisp compilers (LispWorks, Franz Inc, etc). Lisp also seems to be making HN front page at least once a week.

Pascal had two killer apps.

First, it was used for teaching, like Java today. So you had a wide base of programmers knowing it.

Second, there was Turbo Pascal which made it an extremely popular language on PC platform (also used to have significant presence on Mac, but I'm less familiar there.

Three: Delphi. Programming has never been as fun as with Delphi.

Pascal was also used to program Mac OS.

Classic MacOS, it should be noted, not the recent rebranding of OSX.

> Google uses Common Lisp

Which projects at Google use Common Lisp? I didn't even know it was an approved language.

Google acquired a large Common Lisp codebase when they bought ITA. I doubt they would have chosen Common Lisp if they had started from scratch.

https://en.wikipedia.org/wiki/ITA_Software

But they also chose to not rewrite it, and double down in investing in it.

They tried to rewrite it, reportedly: https://twitter.com/fare/status/1112477563056779265?s=20

Ironically, Yahoo didn't re-write Viaweb's lisp for a decade either after they bought it. (Ironic because HN.)

But that doesn't make Yahoo a lisp company.

As a side note: Pascal was not a failure. Currently it is incarnated as Go, that has a clear succession line to Oberon, Modula-2, and Pascal.

(Free Pascal is also alive and kicking.)

Go is direct successor of a long line of alternative C evolution (Bell Labs didn't stop evolving the language or experimenting with new ones, and Go pretty much initially was a syhtax sugar for Plan9 C and its runtime and style)

Then it's a case of convergent evolution then, because coroutines were even a part of Modula-2, and the type of class / interface approach that Go sports looks very much like Oberon's.

I won't wonder if the ideas were circulating between Oberon and Plan 9 communities back in the day.

Griesemer, one of the three original Golang developers, did his dissertation on extending Oberon to, I think, massively parallel computers. Golang has a bunch of constructs that weren't in Plan 9 C; some of the syntactic sugar comes arguably from Oberon, but most of the semantics come from Newsqueak and Alef.

IIRC after Alef went "bust" due to disagreements about GC, its thread semantics got ported to C as libthread, as well as used in Limbo. Then Go kinda resurrected it but with GC?

The end of the line from Plan 9, which tends to be ignored, was Inferno, with a GC userspace implemented in Limbo.

Go at its base is a fusion of Limbo and Oberon-2.

Yeah, I should have mentioned Limbo. But it's been so long since I looked at it that I don't remember what its semantics are like.

The big difference versus Go, is that Limbo is like Java, in the sense that it favours dynamic linking.

Go nowadays supports dynamic linking, but it isn't the default, the plugin package is quite basic and only supported on Linux and OS X..

Go uses Oberon-2 syntax for methods and unsafe is a kind of subset from SYSTEM.

In that case we could just say: "Pascal was not a failure; currently it is incarnated as C". :)

I guess, although in the case of Java I'm not too sure. It seems like what you're really pointing out isn't so much a killer app but a captive market. If programmers are forced to use a language, they'll use it, is basically what you're pointing out. But think about C++, or Python or Java(!) or any number of other languages that didn't actually have a captive audience or a killer app and still became popular--- interestingly, in one of the other comments they say that the "killer app" for Java is safety and GC. That doesn't sound like a killer app, that's a language feature.

What I'm getting at here is that it's pretty clear that language features are an integral part of what makes a language successful. In fact, apart from some extreme, extreme outliers like JS which just happen to be the most visible, features are the only deciding factors outside of luck (and marketing). So if you ask why a language isn't successful, saying that it doesn't have a captive audience isn't a very descriptive or helpful metric. Yes, without a captive audience or maybe won't be as successful as JS but that's not the real deciding factor at all.

Aside from a captive audience based killer app, projects don't lead to language choice necessarily. Why did the person who created Numpy choose Python? Python didn't have a killer app for that. They chose it because of language features.

So we're back to the OG question: in the arena where languages normally compete (besides outliers), LISP looks amazing, so why isn't it as successful as we'd expect? I'd honestly suggest it's just bad luck, no marketing, and a fragmented community.

Now, we could talk about why the LISP community is fragmented, and in this case I think it's due to too much of an emphasis on extending the language. DSL-building based programming paradigms are actually really effective, they're essentially what FP and OOP are all about. In OOP you build a custom type system and language to represent the problem. For FP you do the same, just with less internal state. LISP's only difference is it has more powerful abstractions for formalizing the process. The problem is they confused DSL building with language building and so multiple different general purpose dialects proliferated.

C++ had a captive market.

It was bundled by C compiler vendors early on during the 90's, and it was on the rise as all desktop vendors were jumping into it as the way to write GUIs on.

Mac OS, BeOS, OS/2, Windows, they were all moving into it.

Had it not been for the rise of C based FOSS and the respective free UNIX clones, and it would have spread even more.

>Now, we could talk about why the LISP community is fragmented (...) The problem is they confused DSL building with language building and so multiple different general purpose dialects proliferated.

The Lisp community isn't fragmented. There are two main lisp dialects (Common Lisp and Scheme), three if you want to add Clojure, and each of them has a faithful community.

Well, yes, but look at how fragmented the Scheme community is. And then also, fragmentation between 3 dialects is still a good bit more fragmentation than most language communities have.

A fourth distinct Lisp is Emacs Lisp.

I don't think anyone has "chosen" to implement Numpy (or any of the hundreds of C and C++ modules) in Python because of its language features. On the contrary, they specifically avoided using pure Python because of its low performance and opted for more performant languages used through FFI.

The reason people have gone through the effort to implement those modules is absolutely because of "captive audience based killer apps" which for Python were ML and scientific computing. And while Python is decent in its role as a glue language, it succeeded mostly by being easy to pick up and very forgiving, which shouldn't be the main factors for choosing a language for anyone who is a software engineer and not a scientist.

But what made the people who chose it for ML and scientific computing choose it? What made it better for that? There has to be a reason to choose it in the first place, and before Numpy it wasn't awesome at ML and scientific computing that I know of.

Also, being easy to learn is very much a language feature that put it in good standing for non-software-engineers, and I'm not sure why you brought up if it's good for software engineers.

The reason to choose it in the first place is, as I said, ease and convenience of use when used as a glue language. It's easier than in say, C or C++, to call some functions operating on Numpy arrays and make a graph based on that.

I just think saying "the person who created Numpy chose Python" is a bit weird, when all the heavy-lifting code is in C. Following this logic that person also chose all the other languages that have bindings to Numpy. Yes, the creators of Numpy probably had Python in mind when creating the library. But that just means they chose Python as their glue language of choice, not as their platform for implementing algorithms used in ML or scientific computing.

I did say that being easy to learn is a great language feature that made Python succeed in scientific circles. It's just that using Python for science exposes its shortcomings much less often that using it more generally, which is in most cases done by "full-blown" software engineers, who spend more time programming than, for example, creating a scientific model.

Yeah I mean I agree with you on basically all of this, I just think this proves my point that to whatever extent languages are used, it's more about features of the language, not killer apps.

And yeah, saying the author of Numpy chose Python is a little weird, since it's mostly written in C and Fortran (IIRC) but I'm pretty sure it was made with bindings to Python in mind, as you say, so the point still stands.

Actually, Matlab pulled educational licenses from research institutions like Fraunhoffer. This created a need for an alternative to Matlab. This made python popular in ML and scientific communities.

Yeah, we geeks like to think the concepts and technical design of a language in itself is what makes or breaks it. But JavaScript could have been similar to BASIC or it could have been similar to Scheme - people would have grumbled but used it regardless. Objective-C was considered a pretty obscure niche language until the iPhone made it mainstream.

The article cites fragmentation as the reason Lisp didn't become mainstream. But consider SQL - a severely fragmented language. Each implementation have major incompatibilities with every other. But it is still ubiquitous and rules its niche.

Scheme was almost that language of the web. Unfortunately, politics prevented that:

https://www.reddit.com/r/programming/comments/b7khq2/i_just_...

That's interesting. The author of Javascript wanted something lisp like. That must be why Javascript feels a bit like lisp to me with functions and closures being primary building blocks, notwithstanding the recent misguided attempts at making Javascript look more imperative with promises and the like.

I think there is something to the argument in the article about Lisp being too expressive and allowing developers to have too different styles making it difficult to read other peoples code. I wonder if another part of the problem with Lisp is that newbie developers struggle to follow continuation-passing style programs. This would explain why the promise crutch is so popular in Javascript.

I don't think it's the brackets that people dislike, it's having to understand the layers of scoping and closures that the brackets imply. Once you get used to it though it becomes very powerful.

Continuation passing isn't suitable for humans. Callback hell is a thing. Leave it for compiler SSAs and use something more sensible for reading.

>I think there is something to the argument in the article about Lisp being too expressive and allowing developers to have too different styles making it difficult to read other peoples code.

Rest assured this doesn't happen in Common Lisp, because what often happens is that the program is done in the style where it makes more sense.

For example, if the program lends itself to be easily done using OOP, then it is written using CLOS (the lisp OOP system).

If, for example, there is a part that is a state machine, it might be written in the old "goto <label>" style.

If it lends to functional programming, well, lisp was the first FP language, so fine.

If a part of the program requires generation of HTML, the source will resemble HTML.

etc.

> misguided

Could you recommend a resource that explains why these features are misguided? I've found them to be much nicer than callbacks but it's possible that I'm misguided too. :~)

With CPS it seems like you have to build and then instrument a lot of additional machinery (CPSMath.pow, seriously?) and occasionally turn your code inside out (the loop completion example) in order to rarely get a more convenient way to extend certain types of computations.

The author also seems to lay the fact that Javascript is often implemented in an odd way in browsers (the iframe complaint) to find fault with the entirety of the concept of Promises in general, which doesn't seem appropriate to the discussion here.

Finally.. he suggests that CPS shows it's power in a "probabilistic programming language" that executes blocks of code in a random order. Perhaps I shouldn't judge an author by their contents, but I think this author is so in love with the idea of CPS that he can't see how ugly and mostly mismatched it's implementations are.

Don't use CPSMath.pow. It's just in there to demonstrate that it's easy to turn direct style into CPS style. When a function doesn't need to be asyncronous, just use direct style.

Friendly recommendation: when writing examples it's much nicer to use a real use-case rather than abstract functions like `cps4()` or `CPSadditionalProcessing()`.

Anyway, it seems that your point is that you'd like to recommend passing continuables a la callstep: https://github.com/ahdinosaur/callstep

Continuables are a great pattern, but you haven't really answered the question of why you think promises are "misguided".

We don't know that, it is very likely that Mozillas language would never have become standard if it was scheme instead of Javascript.

Even if it wasn't, we wouldn't have ended up with JavaScript and the odds are we'd have something better.

IIRC, the only actual browser scripting language competitor to Javascript at the time was Microsoft's VBScript, and that probably would have won. There was never really a third option on the table, just "what Microsoft did" and "something else."

Actually there was, you could use Perl and Python as well via browser plugins. ActiveState used to develop them.

It would probably have been FutureSplash Animator, which became Macromedia Flash and then Adobe Flash. For a long time Flash was the de-facto web scripting language.

Flash is scripted with a language eerily similar to JavaScript -- so similar that I assumed it was derived directly from JavaScript. In the hypothetical world where JavaScript was lisp... wouldn't Flash use that?

I think you're probably referring to Actionscript, which came much later in Flash's evolution and was indeed very much similar to javascript.

> I think Lisp failed because it had no killer app.

As a vim user I love to think of all of the emacs peoples' heads exploding when they read lisp has no killer app. However it should be noted that lisp still has strong use cases in education and language design and even if not commonly used in industry its principles and design ideas come through in many modern languages.

What do you mean? Emacs Lisp doesn't even have explode!

    (explode 'head)

    Debugger entered--Lisp error: (void-function explode)
      (explode 'head)
      eval((explode 'head) nil)
      elisp--eval-last-sexp(t)
      eval-last-sexp(t)
      eval-print-last-sexp(nil)
      funcall-interactively(eval-print-last-sexp nil)
      call-interactively(eval-print-last-sexp nil nil)
      command-execute(eval-print-last-sexp)

You forgot to (require 'explode-mode).

Didn't they sell ITA again?

I think they just retired it. [1]

[1]: https://skift.com/2017/11/01/google-to-retire-ita-software-f...

They retired public access and private access for "small clients". The engine is still there, Google just decided it's not going to keep the vendor-client relationships.

Android -> Java? Java dominated well before mobile.

Also JVM languages are surging even though none have a specific killer app.

But Clojure is still niche. And is the most powerful/simple of them all. I think there’s something else going on, too much power & simplicity in a language doesn’t yield to mass appeal - why?

Java's big thing was "same code, run everywhere". Even before Android, apps and games on my 2002 flip-phone were written in Java Micro Edition.

Also Java is not c++, I was a c++ programmer in 1994, in 1996 I was a Java programmer. I cannot explain how much my quality of life had changed. I know that c++ isn't the way it was then, now, but holy heaven, working with it then was like shaving with a hover mower.

Java had a lot of "big things" going for it:

1. Write Once, Run Anywhere

2. GUI in the standard library

3. Way less complex than hyper-complex C++

4. Garbage collection

5. Memory safety

6. Applets that ran in the web browser

7. Comprehensive standard library

8. Free compiler and JVM for all major (at the time) operating systems

Some of these things have ultimately not worked out, but at the time, all of the aforementioned features helped propel Java to huge success.

this was a huge deal sometime back.

the fact you could get roughly the same order of magnitude performance as C in an environment that didn't need tons if #ifdefs to work on various platforms was amazing.

Yeah, that's a great way to look at it. Just to add to your point, why in hell would someone use Emacslisp? Well, it has a killer app (Emacs / org-mode / etc.) and people learned and used it.

I wonder if ClojureScript -> [Node, Web-js] is how lisp will be saved? Or maybe lisp doesn't need to be saved and it'll always be this non-mainstream language. (To be clear: I say non-mainstream but I don't mean it negatively.)

I think you’re on to something, but maybe missing a historical detail: Lisp had a killer app: AI.

Unfortunately, the massive investment of time, money, attention, etc that went into Lisp and AI came too early, faltered, and left both high and dry for a few decades. It’s called “AI Winter”.

Thank You, Which is basically my economic theory of PL that I have been trying to explain across to many people.

An ecosystem forces you to program in a language, as long as the ecosystem grows in market value, it will require more developers, more people learning it and more jobs for it. A positive growing circle, and once it reaches a certain threshold it should become self sustainable, there will be interest from many parties to try and improve on it.

On the other hand, if a languages ecosystem does not reach that threshold, there will be doubt if new project should be built on it, there will be less opening for developers, less in demand means people are not learning it, market wants experience dev but experience dev would have moved on to other ecosystem. Lack of hireable Devs meant PM should choose something else that makes hiring easier. And the ecosystem shrink, what we call a languages is dying. It really isn't dying, it should be accurately described as shrinking. The Negative circle.

And in most cases languages lives on in other form. People call Ruby as Matz's Lisp.

I'd argue that none of those languages are the most appropriate for any problem at all. As long as the language itself is somewhat usable it's mostly the ecosystem (and hype) that counts: Libraries, editor support, build tools, etc.

> In my entire career (25 years), I've never had a project that directed me towards learning Lisp.

emacs

Either that or people know a language and they get given a new project which is generally not written in that language and they find some compiler/bridge/some other tool that allows them to write what they need to write in the language they are accustomed to writing in.

So why not choose a Lisp.

Lisp had Symbolic AI, which got killed.

For what it's worth, the "Android -> Java" part is now obsolete. Especially as you do mention Swift in the context of iOS development. Kotlin is now the default language for Android, officially recommended ahead of Java.

Ok... so why wasn't Lisp chosen over Javascript for the web, why wasn't Lisp chosen as the language for Android, iOS, or Windows?

Well, .NET GC was originally implemented in Lisp.

https://github.com/dotnet/coreclr/issues/401

And NeXTSTEP Interface Builder prototype was done in Common Lisp

https://en.wikipedia.org/wiki/Interface_Builder

https://vimeo.com/62618532

So it definitly had an influence on iOS and Windows.

Regarding Android, as Guy Steele puts it on his ClojureTV talk about Java.

"We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp."

Finally, regarding the Web

https://thenewstack.io/brendan-eich-on-creating-javascript-i...

"He later calls Scheme “that beautiful research language I was tempted with.” But by the time he’d joined Netscape, they had a deal with Sun Microsystems, which was now pushing their newly-minted language Java. “And suddenly the story was, ‘Well, we don’t know if we want Scheme. We don’t know if we even need a little language like we wanted you to do. Maybe Java’s enough.'”"

> Interface Builder prototype was done in Common Lisp

It was actually a Lisp product by a company, which was shown to Steve Jobs.

Thanks for the correction.

That still doesn't explain Java's popularity as a backend language. Unless J2ME or Applets was the killer app.

Yes, applets looked promising, but server-side, you might say Java was the Node.js of its time. Back in the early dot-com era, we were looking for a way for inexperienced programmers (us) to do Internet programming easily, and with its built-in threads and easy-to-use network libraries, Java looked pretty good. (And where it wasn't good yet, we thought Sun would improve it.)

This is around the time when Apache was popular with its original process-based concurrency model. You could waste a lot of memory running mod_perl with a pool of a hundred processes.

Java performance was pretty bad compared to C, but writing a select-based C server looked convoluted, and using threads in C looked obscure, non-portable, and bug-prone. We wanted a friendlier language than that.

I would say cross platform apps, and an 'alternative to C/C++' was Java's killer app. Popularity as a backend language comes as a side effect of its general popularity (a la Node w/ Javascript, though there's something to be said about Node's 'different' approach)

> alternative to C/C++

Safety and garbage collection.

In very practical terms, dependably obtaining a stack trace that says "NullPointerException" or the like instead of silent and intermittent memory corruption was more than enough to attract shell-shocked C and C++ programmers.

This. Also the libraries - in 1994 c++ toolkits were very poor - I was there, it was terrible - the Java libraries and in particular AWT were just fantastic. Basically features and deliveries that required weeks of heartache and grind could be delivered in hours.

Java features that have yet to show up in other languages: Scalability - both horizontal and vertical. Memory utilization (you can have humongous heaps without having to worry about managing all that memory). Managability - easy to "divide and conquer": you can plop a jar and start using it right away. Something that's practically impossible in other languages. Third party ecosystem (both free/oss and paid). Speed. Java is one of the fastest managed languages.

Yes it is verbose, yes inexperienced developers do the wrong things, but it does a great job preventing you shooting yourself in the foot, and most importantly, once you have a stable codebase, it can keep running for months/years.

> you can plop a jar and start using it right away

I'm mostly a Java developer, so I think this explains why Docker always looked a little silly to me. I also write some Python, and once I have to set up a virtualenv, that's when Docker's existence makes more sense.

Erlang/BEAM has all that (and does it better)

Enterprise -> Java + XML

They got in early, largely split the market with .NET

I think Java was unique as it was the first language with a major corporation behind it and a large marketing campaign.

That was COBOL with Univac, IBM and Honeywell.

Single platform (OS360 / zSeries/zOS).

Java is (famously) multi-platform. As disputed by Sun and Microsoft.

What about VisualBasic, for example? Or ObjectPascal/Delphi. Or Objective-C.

Objective C didn't have a major corporation behind it until 2006-2009. Apple wasn't really relevant (outside the iPod/iTunes) until OS X gained traction and the iPhone (and app store) came out.

Apple was not a major corporation in 2000? (But it's true that would be post-Java.) Then neither was Sun. (Or maybe FigBug meant IBM which pushed Java heavily a few years later? They also pushed Smalltalk before, by the way.)

In 1994 Apple was about to go insolvent after failing multiple times to create a next generation OS, and spending the remaing money acquiring NeXT, which happened to be a reverse acquisition in the end.

What do you consider a major corporation? In (fiscal year) 1997 when it merged with Next and started to push objective-c the company had $7bn in revenue (down from $11bn a couple of years before, that’s true) and more than 8000 employees. The next couple of years sales were around $6bn but increased to $8bn in 2000.

Right, but had not Steve Jobs "bought" Apple back, and we probably wouldn't be speaking about it anymore.

It would have turned into another Commodore, Atari, SGI, DEC,...

Also, to add to what everyone else is saying, you have to remember (or try to imagine) what it was like back then. When Java first came out it was hella cool! (Like MTV.)

Java was super heavily marketed

Java has good concurrency support and scales well.

Applets were the lever which propelled Java to a popular mainstream language.

Probably the closest they got was Autocad's AutoLisp

emacs -> lisp autocad -> lisp

Standard open-in-new-tab warning applies.