Hacker News new | ask | show | jobs
by logicprog 2537 days ago
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.

3 comments

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.