
Your Language Sucks, It Doesn’t Matter - Sindisil
https://matklad.github.io//2020/09/13/your-language-sucks.html
======
marvinalone
The _only_ factor to programming language popularity is how accessible it is.

Beauty and elegance don't matter. Performance doesn't matter. In fact, no
measure of "fitness for purpose" matters.

If Malbolge was built into every operating system, Stack Overflow would plug
the gaps, and major production systems would be built in it. People would give
conference talks about "scaling Malbolge to millions of transactions per
second". It would have a package manager, a deep learning framework, and
several UI toolkits.

In some sense, this has already happened.

~~~
wtetzner
> The _only_ factor to programming language popularity is how accessible it
> is.

> Beauty and elegance don't matter. Performance doesn't matter. In fact, no
> measure of "fitness for purpose" matters.

If that were true, C++ wouldn't be so popular.

~~~
Hemospectrum
The popularity of C++ took off at a time when its competition was C. Not
modern C, but C89 and older. Oceans of ink have been spilled describing the
quality-of-life improvements that early C++ made over contemporary C. It is
only with hindsight that we see how flawed these improvements were, and how
other languages might achieve them with more elegance (and fewer corner cases
that constantly explode in your face).

~~~
loopz
C++ is relatively easy to code in a plain way that don't blow up in your face.
It's just that java made much more business sense with GC, stack trace, safe
objects and built-in security model.

------
diego_moita
> What matters is characteristics of the runtime

I'd say what matters is who is your sponsor.

C/C++ had Unix/AT&T and Microsoft as sponsors.

Basic and C# had Microsoft.

Javascript had all browsers' makers.

Java had Sun and Google.

Fortran and Cobol had IBM.

Python, Go and Kotlyn have Google.

Objective-C had Apple. When Apple was in the ropes Objective-C wasn't popular.
Then Apple got big and Objective-C got big, also.

Turbo Pascal/Delphi had Borland when Borland was Borland. Now Borland is
Embarcadero and the language is fading.

Smalltalk, Lisp and Lua had great runtimes but never had great sponsors.

Ok, there were exceptions: Perl, Ruby, DBase... but some of these are falling
behind already.

~~~
mikestew
_DBase_

That was a different time, though, and by 1990 Ashton-Tate (makers of dBase,
and soon to be bought by Borland) was pretty much done. Microsoft bought
dBase-clone Fox Software in '93, which is pretty much the only thing that kept
anything dBase alive until FoxPro got put out to pasture sometime around
'05-'06.

IOW, were it not for the sponsorship of Microsoft, dBase would have been done
30 years ago.

~~~
tabtab
There were lawsuits flying left and right over the origin, which scared a lot
of resources away from it. (It turned out Ashton-Tate stole it from NASA's
JPL, who modified some of the keywords, but stole the concept from a defunct
company and product called something like TymeShare.)

I thought dBASE was a great language for small-project RAD and ad-hoc data
fiddling. I could crank out smallish apps in hours.

------
nepeckman
I propose a corollary to the author's thesis: a languages popularity is a
function of runtime advantages and time to implement an MVP for your domain.
This corollary explains the scripting language conundrum: Python is popular
because it's easy to implement an MVP in a number of different domains. Rails
helped Ruby to achieve widespread use because it made it easy to implement an
MVP for a web application. I think it's fair to say that to gain adoption, a
language needs either a killer runtime or a killer app.

------
jakelazaroff
Can someone familiar with the languages elaborate on "generics in Swift are
the opposite of the generics in Go"? It's an interesting offhand comment but I
have no idea what it means.

~~~
wtetzner
Maybe just that Swift _has_ generics?

~~~
jakelazaroff
I assumed they were contrasting Swift's generics with the proposed generics
for Go:
[https://go.googlesource.com/proposal/+/refs/heads/master/des...](https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-
type-parameters.md)

------
chubot
Unix shell is another good example. It’s a bad programming language, which is
not surprising because it didn’t start out as a language.

Yet people use it as one and write tens of thousands of lines of code in it.
See [https://github.com/oilshell/oil/wiki/The-Biggest-Shell-
Progr...](https://github.com/oilshell/oil/wiki/The-Biggest-Shell-Programs-in-
the-World) and [https://oilshell.org](https://oilshell.org)

~~~
Wowfunhappy
Unix shell also has a natural learning ramp. You start out just using the the
shell to do standard computer tasks: install software, manage files, etc.

Then, one day, you're trying to do some sort of repetitive task, and you use a
for loop. Or you realize it would be nice if cron could run a command for you
at a set time.

Then, some time later, you realize it would be useful if cron could execute
five commands in sequence, or decide that your for loop is complicated enough
that you'd like to write it out on multiple lines. And just like that, you've
started developing shell scripts.

------
stmw
I agree that the quality of language runtimes are neglected all too often, as
opposed to language features. I had similar reasoning when I wrote about it
earlier this year -
[https://blog.commure.com/whycommureusesrustforhealthcare/](https://blog.commure.com/whycommureusesrustforhealthcare/)

------
marmaduke
> yeah, we’ll just JIT highly dynamic language to suuuper fast numeric code at
> runtime

This is the impression one gets sometimes, but the recommendations for fast
Julia actually seem to revolve around ensuring type stability (another way to
say “static strong typing”) and avoiding heap allocations, in fact Julia seems
like just another nicer syntax for C++

~~~
amkkma
You must be thinking of Julia pre 0.5

------
commandlinefan
Another point in favor of the authors thesis: pure functional programs
continue, two decades into the 21st century, to not be widely used in spite of
their syntactic popularity. Software still continues to not be written at
significant scale in Lisp, or Haskell, or even Scala.

~~~
pklausler
Pure functional programming is (IMO) more of a style than a language phylum.
One can (and I can argue should) write C++ in a pure functional style, esp.
now with C++17 having sum types.

~~~
wtetzner
C++17 has sum types?

~~~
pklausler
You bet; see std::variant<>. Great for closed-world polymorphism with
compilation-time checking of completeness!

------
ngrilly
I like this hypothesis.

This is exactly why I switched from C++ to Java, and from Python to Go, and
why I’m using JavaScript in the browser.

But it doesn’t fully explain why I switched from Java to Python: that was
partly for the runtime, but in that case the language itself played a big
part.

------
pklausler
I'm going to have to think more about the author's thesis about runtimes. It
reminds me that I would love to see more language implementations with region-
based memory reclamation instead of garbage collection, if only to be able to
have more predictable overhead. A pure functional language would seem to be
amenable to performing little collections over new objects that aren't
reachable from function results, for example.

~~~
dnautics
You're basically describing the erlang runtime, which is more popular than
"totally niche" but not as explosively popular as, say JVM, .NET, JS, or even
Dart. In fact despite being a practitioner of the erlang runtime, I would say
that its lack of popularity is a point against the author.

------
smaddox
Interesting hypothesis. There certainly is at least some truth to it.

On the topic of Zig, he seems to ignore that Zig provides several unique
"runtime" features:

* unlimited comptime code execution * error sets and error return traces * choice between blocking or async runtime, using the same code * runtime checks for undefined behavior * debug allocator

And probably more that I'm not thinking of or am not aware of.

------
ramino
I wonder where Kotlin would fall in this case. It offers a lot of compile
targets and it has some authority over Android (but Dart is getting more
popular by the minute/ Java is shrinking only slowly). Will it be the Android
language or the next cross platform language?

~~~
mr_tristan
If Kotlin can set up adequate tooling and performance in native and JavaScript
backends, its approach of building libraries for multiple platforms could be a
new wrinkle, and fulfill the "write once, run anywhere" better than Java ever
did.

As it stands, it's _not_ easy to use the multiple platform setup. You really
need to be both an expert in Kotlin, Gradle (and their plugins are _barely_
documented), and the target platform.

But if the build process becomes easy, and, they can build a rich ecosystem
that basically can create abstraction layers on top of the target platforms, I
see it going far. It's still not there yet, but it's moving quickly.

I'm still in a "wait and see" place with Kotlin. I've enjoyed working with it
on the JVM, where the tooling is fantastic. But the JS and native toolchains
are still not up to my standards. Just being another JVM language isn't good
enough for me.

------
fhood
This is too bold a claim. Not an inaccurate one, as with some languages
runtime does play a huge factor in widespread adoption, but as with many
things, it's just more complicated than that. Obviously scripting languages
like python do not depend on runtime for popularity, except when they do. How
can you even separate Go's syntax and paradigms from its runtime when it's
defining attributes (parallelism) are so tightly coupled to it?

I don't really disagree with any of the overarching points here, other than
the supposition that "runtime" is anywhere close to the one factor to rule
them all. Adoption is determined by....mostly adoption. You generally choose
the most popular language that fits your needs, however stringent they might
be, and initial adoption has so many factors that go into it, and if syntax
and paradigms were irrelevant, then why would C++ have superseded C, only to
be replaced itself by a variety of languages addressing a variety of needs?

------
boring_twenties
I don't know anything about Emacs Lisp. Why is it "objectively bad?"

~~~
DonaldPShimoda
I assume that the author, like many people, has an allergy to parentheses or
something like that.

As far as I'm aware, there is no way to measure whether a language is
"objectively bad" except if that language does not allow you to do what you
want to do (or, maybe, if the language makes doing what you want to do
unreasonably difficult). Emacs Lisp has been successful for decades and by all
appearances is going to continue being successful, which in my mind makes it
objectively _good_ by any empirical measure.

(By this measure, we could consider languages like the assembly languages,
ALGOL, etc as "bad", so long as the context for analysis is "writing modern
high-level software." They are mostly no longer used except when necessary,
which seems to me the only measure worth considering until we develop a theory
of language usability analysis.)

I wish the author had not been so vague in this dismissal. While their article
is certainly allowed/encouraged to be full of opinionated conjecture (as they
defend in the opening), I think such a strong position is deserving of at
least a little more justification.

~~~
gamegoblin
I think the quibble here is about "objectively bad" vs. "objectively worse".

I believe the author somewhat elaborates on what he means by "objectively bad"
with his example of Javascript having two "null" sort of values, which under a
reasonable definition is objectively worse than a theoretical Javascript with
a single null.

So if we read the author charitably, taking into account his example of
Javascript having two nulls being objectively worse than a theoretical
Javascript with one null, we can interpret his statement as "Emacs Lisp is
objectively worse than other Lisps, which have essentially identical
functionality and fewer sharp edges".

~~~
DonaldPShimoda
But the author does not elaborate on the "objectively bad" statement
explicitly, leaving it to the reader to discern what makes Emacs Lisp bad. And
I think "worse" makes less sense, because it is not being directly contrasted
against any other language. The author simply takes it for granted that
readers will agree Emacs Lisp is "bad" and leaves it at that, which I think is
unfortunate.

Your example wrt. JS's two null types doesn't exactly generalize. What are
Emacs Lisp's "sharp edges", as you say? What does it prevent people from
doing? In what way could it be made more ergonomic? I would argue that its
long-term proven stability is an indicator that the language does _not_ have
sharp edges; at least, not ones which discourage its use significantly. When
you go into discussions about programming languages, you can't throw a stone
without hearing somebody bemoan Javascript or PHP, but I never hear Emacs Lisp
being brought up (and people who do bring up Lisp are often just upset about
the abundance of parentheses, it seems).

I dunno, it just strikes me as the author acting as though this is a given
assumption, and I don't quite see it. I'm not saying they're wrong (because,
of course, the entire article is an opinion piece and the author is entitled
to their opinion), but rather that I just wish this claim had gotten a bit
more justification.

~~~
matklad
Yeah, I agree that not elaborating on this was unfortunate (but elaborating
would be tangential, as relatively few people are familiar with Emacs Lisp).

I think Emacs Lisp is in the "easy to improve upon" category because of:

* lack of namespaces * dynamic binding by default * spartan standard library

I do love parenthesis though :)

------
29athrowaway
I disagree.

If you compare languages that implement the same programming paradigms you can
mistakenly arrive to the conclusion all languages are the same.

They are not the same.

Compare C with Prolog, Erlang/Elixir and Haskell and you will know what I am
talking about.

------
blewboarwastake
I thought it was gonna be this:
[https://wiki.theory.org/index.php/YourLanguageSucks](https://wiki.theory.org/index.php/YourLanguageSucks)

