
All Programming Languages are Wrong (2018) - jashkenas
http://users.rcn.com/david-moon/Lunar/all_programming_languages_are_wrong.html
======
mfDjB
Does anyone else consider these type of articles the clickbait of the
programming world? They tend to all follow the formula of

1\. Make over the top statement in title.

2\. Vaguely address the over the top statement in content.

For example the author hasn't shown us why "All" programming languages are
"wrong". They haven't shown how they would fix them to make them "right".
Their premises (e.g. "computation is almost always free") are flawed.

I wonder, if the title was called "A rant about some popular programming
language paradigms" would it be as popular?

~~~
nuclx
"computation is almost free" actually triggered me. that's the java argument
from 20 years ago, now we have go and rust. it implies electron is actually a
sane approach to ui development.

the author is very vague about why exactly numbers don't fit in the type
system, and in which languages. first class types for numbers exist in some
languages. is he advocating for default overflow checks, which bloat code
size?

~~~
dragonwriter
> the author is very vague about why exactly numbers don't fit in the type
> system

No, he’s quite specific: “hardware details such as the number of bits
supported by an integer add instruction show through in the language
semantics.”

Now, it's also true that there are quite a lot of languages where this is not
true, e.g., Scheme, Haskell (IIRC with the default numeric settings), Ruby,
Python, for instance, and many more have numeric types in core language or
stdlib that don't face this problem but don't make them the default for simple
numeric literals.

------
dusted
Computation is not almost free and people are doing just fine writing slow
code without the language helping them.

Taken that we've more or less stalled with regards single core performance,
I'd argue that computers are now getting slower (because software is bloating
faster than single core performance is increasing).

~~~
gridlockd
> Computation is not almost free...

In the vast majority of cases, it is. He's talking about the ALUs actually
performing work, as opposed to waiting on memory. He rightly points out that
cache misses make the biggest performance impact on modern systems. Most
languages these days do not address this, there's tons of indirection by
design.

> Taken that we've more or less stalled with regards single core performance,
> I'd argue that computers are now getting slower (because software is
> bloating faster than single core performance is increasing).

Again, if you can actually give your ALUs enough work to saturate them, your
problem is most likely embarrassingly parallel, in which case single-core
performance is not the bottleneck. Otherwise, you will want to optimize for
memory access.

------
hr0m
I wonder what the author would do, when performance is critical. Today too
many people rely on fast cpu and large memory. There are lots of applicants,
where you need to optimize.

------
bcrosby95
> For example, one cache miss might take as much time as a hundred add
> instructions.

> Today's languages contain far too many features that do almost the same
> thing but have slightly different performance characteristics, for example
> regular and virtual functions in C++.

Odd example. Virtual functions help enable certain designs, but avoiding
virtual functions is commonly recommended when writing cache friendly code.

~~~
spaced-out
Honestly it really hurts the author's credibility.

Virtual functions hurt performance (generally not significantly) but allow for
OOP design, in theory to make the program structure more clear/organized.
Exactly what the author is supposedly advocating.

------
rmist
Each programming language is suitable for solving certain type of problems. So
when I see a catch-all statement like "All Programming Languages are Wrong",
it seems to me the author is implying that "None of the programming languages
solve my (or this specific type of) problem."

> It does not reflect the realities of modern hardware, where computation is
> almost free, memory size is almost unlimited ...

Well, no, this certainly doesn't apply to all problems!

> ... because they seem to be in love with the idea of "object" or "abstract
> data type." ...

Again, there are many different paradigms of programming, OOP being one of
them with its own pros and cons.

------
bedobi
IMO the biggest problems with almost all popular programming languages are

1) null

2) exception based error handling

such that, when you call foo() where foo is

String foo(){ blabla }

you can get a String, null OR an exception (!!!) and most compilers happily
let you treat it as if it only ever returns a String.

I hope some day null is no longer a thing, and that Functional Programming
types like Option, Either, Try etc in the native libraries is the new default.

~~~
quelltext
I am probably in the minority here but I think Java was on the right track
with checked exceptions.

~~~
bedobi
I used to think so, but

* Java also has unchecked exceptions, and, incredibly, there's _still_ no consensus as to which exceptions should be used for what and when, though these days the most common approach is to simply stick only to RuntimeExceptions, which is terrible.

* Functional error handling using Option, Either, Try etc are arguably much simpler, safer and more powerful than exceptions.

Simpler because they don't rely on dedicated syntax- they're just regular
objects no different to any other object.

Safer because unlike exceptions, they force callers to handle all potential
outcomes, but no more. (no risk of ignoring errors and no risk of catching a
higher level of error than desired, ubiquitous bugs in exception based error
handling)

Powerful because they support map, flatmap, applicative etc, making it easy to
eg chain multiple computations together in desired ways, which is unwieldy and
bug prone when using exceptions.

It could be that, when learning Java, Python and any other language, we learn
that methods return objects... and that's that. No weird dedicated syntax and
magic, special treatment for returning anything other than the happy path, and
the HUGE complexity that comes with it, eg the dedicated syntax itself and how
it behaves, differences between checked and unchecked exceptions, hierarchies
of exceptions etc etc.

When lists and booleans also implement map, flatMap etc, you can actually
reduce syntax of languages even further- there's no need for looping syntax
like for, while etc, and no need for if else either. This is probably too
extreme for most people, but think about it!

~~~
dkersten
Slightly off topic, but what should a map or flatMap implementation on boolean
do? Presumably run on true and skip on false? That’s not really what I expect
from map (that it’s filtered the input). I could imagine book.filter.map as a
way to conditionally execute

~~~
karmakaze
I rather like that, `if condition` is a 0/1 iteration with no input. flatMap
can return empty, what should map return when run on false, None?

~~~
mrgriffin
I'd probably think of Bool as being isomorphic to Maybe (), which would mean
your map implementation looks a bit like:

    
    
        map :: Bool -> (() -> b) -> Maybe b
        map True f = Just (f ())
        map False _ = Nothing
    

Or, in Haskell because you've got laziness you could go with:

    
    
        map :: Bool -> b -> Maybe b
    

Which already exists as a combination of Control.Monad.guard and
Data.Functor.(<$).

    
    
        map tf b = b <$ guard tf

------
codr7
This is part of the introduction to a language he's been designing since
forever. I attended the International Lisp Conference in Boston around 2005
and he did a presentation there of what seems like a precursor to this.

Some of his views might be controversial, but he has plenty of Lisp
implementation experience and clearly knows his stuff.

And from what I've read so far, he writes excellent documentation. I'd
recommend anyone to at least skim the whole thing [0].

[0] [http://users.rcn.com/david-
moon/Lunar/index.html](http://users.rcn.com/david-moon/Lunar/index.html)

------
valenciarose
Referring to David Moon namelessly as "the author" in comments about language
design (on Hacker News of all places) does not inspire confidence. Whether or
not you agree with him, Moon has been involved in language design and
implementation for decades. His perspective is directly relevant to discussion
that's primarily focused on large scale trends in language design. I don't
necessarily agree with everything he says here, but it is definitely worth
thinking about, especially where it challenges accepted dogma.

------
mogl1
Is this just my feeling or this this text completely ignore languages which
are of functional / declarative nature? Iirc Prolog doesnt "care" so much
about performance (on a language level at least). Haskell knows Integer,
Rational, Num etc. Same goes for Idris Languages from that area (lambda
calculus) are, by definition, not based on the idea of some specific computer
architecture. Totally possible that i missinterpreted something tho.

------
user2994cb
To put the original in more context, David A. Moon is a major figure in the
Lisp world:
[https://en.wikipedia.org/wiki/David_A._Moon](https://en.wikipedia.org/wiki/David_A._Moon)

------
perfobotto
What a bunch of bs. There are so many places where computation is far from
free and size matters (embedded, HPC for example). And the end of Moore law is
just gonna emphasize the need for performance even more. This article just
tells me that the author didn’t have to write any performance critical code in
his life and he just extended his experience to everything

~~~
patrec
Yeah, what would David Moon of all people know about performance critical
code.

[https://www.h2o.ai/blog/a-brief-conversation-with-david-
moon...](https://www.h2o.ai/blog/a-brief-conversation-with-david-moon/)

~~~
perfobotto
It doesn’t really matter who wrote it. It’s a comment about the article , not
the author himself and the article is approssimative at best. It makes a
statement that’s not true in a lot of cases (“computation is almost free”),
makes some statements that while agreeable are too high level in how they are
expressed like “cost of communication is high” and then the piece ends without
any explanation or examples on what he means exactly or what is wrong and how
to solve it in enough details to actually be an informative article. It seems
like an oversized rant a programmer would make after a bad day at work on
Twitter.

------
erezsh
The author has a good point, although he miscommunicates it: The common use-
cases, such as servers, business logic, glue code, etc., don't usually require
hyper-optimized performance. It only needs to be reasonable and predictable.

They need a language that is easy to work with, and share with others, and
there are few that really do that.

But of course, there are. Go, Python, Julia and others I'm sure, all
prioritize comfort over performance. Although, as compilers improve, they
might one day actually become faster -- since the user writes more abstractly,
there is a wider search space for optimizations.

~~~
random_guy1234
> But of course, there are

Your statements are contradictory.

> they might one day actually become faster

faster compared to C/C++ ? Of course, Performance is improving day by day.
What's the point?

~~~
erezsh
It's not contradictory. I'm saying that the things he says are true, and there
are many languages that follow that line of thought.

Yes, faster than C++. Better abstractions can, sometimes, give the compiler
more flexibility to optimize.

------
_bxg1
Pretty vague and empty argument (rant?). Doesn't really say anything I haven't
seen complained about (and disputed) elsewhere and doesn't really propose any
actual solutions.

~~~
gridlockd
> ...doesn't really propose any actual solutions.

The proposed solution is the language he designed:

[http://users.rcn.com/david-
moon/Lunar/introduction.html](http://users.rcn.com/david-
moon/Lunar/introduction.html)

~~~
_bxg1
Ah. That could've been made more clear in the link title

------
random_guy1234
> Most current-day programming languages seem to be based on the idea that
> computation is slow, so the user and the compiler must work hard to minimize
> the number of instructions executed.

Instructions executed is not the only metric to consider! It doesn't makes
sense to have loads and stores in the program with all of them having a cache
miss.

Does the author mean that the memory hasn't caught up with the computation
here? I don't think so.

> For example, one cache miss might take as much time as a hundred add
> instructions.

This is why compiler must work hard!

> Today's languages contain far too many features that do almost the same
> thing but have slightly different performance characteristics, for example
> regular and virtual functions in C++. This just encourages programmers to
> waste time on micro-optimization when they could instead invest time
> understanding the large-scale behavior of their program and optimizing that.

Not all programs need to worry about insane performance. But most do. It is
totally upto the developers to choose the features of the language which they
need. Choosing the right features/language for the right kind of programs is
an important skill. Efficient code generation for all possible hardwares and
all possible workloads with a restricted language features is not going to
work or else Python would have been one of the very few languages to survive.
Elon Musk wouldn't have tweeted that he needs C/C++ engineers ;-)

It seems the article suggests that neither the hard working compiler nor the
hardware friendly language is required to get good performance!

~~~
pasquinelli
There's also energy consumption. Maybe the inefficient implementation isn't
noticably slow to me, but i'll be unhappy if it drains my battery.

~~~
random_guy1234
Yes, there are so many things to consider. Another would be size of the
binary..

Different kinds of problems are solved by different languages. Simply
rejecting them without stating the details doesn't fly!

------
terminaljunkid
I can't agree about the dot.

Dot makes it easy to chain things left to write, and also almost always dot
based syntax is more readable than stuffing all arguments in parenthesis.

xs.delete(x)

vs

delete(xs,x)

And virtual / regular function distinction exists in performance centered
languages for a good reason. Either you have to go out of your way to prevent
dynamic dispatch or use clunky function pointer syntax and manage vtables
manually. Similar can be said to many features he complains about.

------
pkolaczk
He claims all programming languages are wrong and then he bashes C++ virtual
functions vs regular functions, C++ templates, single dispatch and fixed
precision arithmetic. Looks like "all languages" means C++ to him.

There exist languages with arbitrary precision arithmetic, e.g. Python or
languages with much sophisticated polymorphism e.g. Haskell, Scala or Rust.

~~~
lazyjones
> _There exist languages with arbitrary precision arithmetic, e.g. Python_
    
    
      Floating point numbers are implemented using double in C.
      All bets on their precision are off unless you happen to 
      know the machine you are working with.
    

[https://docs.python.org/2.4/lib/typesnumeric.html](https://docs.python.org/2.4/lib/typesnumeric.html)

------
imtringued
Yeah exactly, we all know that the most used programming languages like Python
and Javascript are way too focused on performance.

------
juancn
Computation is definitely not free. I spend a lot of my time avoiding non-
essential computation as much as possible.

I actually would like more control in many of the current languages.

------
dboreham
Hmm...BCPL isn't from the 50s. C++ isn't from the 70s.

~~~
Taniwha
yeah that was my immediate thought, stopped reading at that point.

BCPL was from the late 60s, most people were introduced to it in the 70s, C++
from the mid-80s

~~~
pjmlp
And it was never intended to be used as full programming language rather to
bootstrap the CPL compiler, hence the B.

[https://en.wikipedia.org/wiki/CPL_(programming_language)](https://en.wikipedia.org/wiki/CPL_\(programming_language\))

In an alternative universe, had the CPL project not suffered management issues
and C would never had happened.

------
lejalv
While computation might be sometimes pecuniarily cheap, it is often
environmentally costly.

------
jeffrallen
But some are wronger than others. (I'm looking at you, Brainf*ck.)

------
StreamBright
Is there a cached version? I could not find it anywhere.

