
The Hundred-Year Language (2003) - zelah
http://www.paulgraham.com/hundred.html
======
dawidloubser
Ever since reading this essay 14 years ago (has it really been that long?!) I
have always thought:

Haskell. He's talking about something like Haskell - but with whatever
additional powers of abstraction and simplification mankind manages to dream
up.

I say this, because I have yet to find such an elegant way of expressing
computation. But, on the other hand, I have yet to find a "serious" language
with as many performance land-mines, which possibly might just _not matter_
given orders of magnitude more memory and computing power.

Given a couple of orders of magnitude, who cares that String = [Char]. It's
damned elegant.

For everything else, I'll bet we will use the "C" of the 21st century - Rust
:-)

JavaScript will probably continue tracking functional languages like Haskell
for many years, albeit remaining without the type system that make them truly
useful.

 __Thank you for re-posting this long-forgotten essay, and taking me down
memory lane... __

------
daly
There is a fundamental change in language coming. I believe that within 5
years the latest crop of programmers will begin to write PROVEN functional
programs. Program proof technology has taken a giant leap in the last few
years. These new techniques are starting to show up at Universities. Those
graduates will know how to prove programs and, after the old programmers like
myself die off, will simply expect that proofs are normal and required.

~~~
zzzcpan
This contradicts the evolution of languages, they don't evolve into making
people do more work. It's way more likely that writing proofs will never
become a thing, but academia will simply get too out of touch to be even
noticed.

~~~
throwaway729
_> they don't evolve into making people do more work_

They don't evolve into making people do less work, either! You really think
programmers work fewer hours today than they did 40 years ago? They don't.
They just build much more complex systems.

Languages evolve to meet people's needs. The question is, does the world need
less buggy code code? I think the answer is yes.

Furthermore, you've made a huge assumption -- that proofs = more work. I
expect that, eventually, our industry will become mature enough that the cost
of bugs, vulnerabilities, etc. is properly priced and the current "move fast
and break things" approach will fall by the wayside.

You can already see these methods being applied at scale in industries where
"beat the other guy by a month" isn't important, but "don't crash the thing
and kill 100 people" is.

~~~
mstolpm
> You can already see these methods being applied at scale in industries where
> "beat the other guy by a month" isn't important, but "don't crash the thing
> and kill 100 people" is.

This sounds to me like implying there are no recalls of goods by manufacturers
in "matured" industries. But we have tons of recalls for cars, toys, food and
gadgets. And that's just the tip of the iceberg, most bugs and vulnerabilities
are never fixed. Even banking (remember the banking crisis?), insurance,
infrastructure projects (airport BER) or utilities like power generation show
that they don't work like you suggest matured industries work by at scale.

So what are the industries you're talking about that work at scale by "don't
cash the thing"?

~~~
throwaway729
_> But we have tons of recalls for cars, toys, food and gadgets_

Most of these recalls aren't related to software. Regardless, systematic
quality issues in each of those businesses have their own unique cultural
origins.

 _> So what are the industries you're talking about that work at scale by
"don't cash the thing"?_

Aerospace, for one. Also chip design and fabrication.

------
mvindahl
"Beating the Averages" is also a good read.

I read these essays for the first time a some years ago at a time when I was
being assigned to a Javascript project and, much to my own surprise, had gone
from ridiculing the language to secretly kind of liking it. At the time I had
been working with Java for 10+ years and Javascript had always been regarded
as this inbred cousin from Kansas that you didn't really want to be seen in
company with.

Anyway, reading Graham's essays on computer languages helped me understand
that Javascript was actually one rung up the abstractness ladder compared to
Java, and that the language that I had always considered to be limited was
instead extremely flexible and hence, stronger.

BTW, a curious thing about Graham is that he measures the strength of a
language by how many features it shares with Lisp. Hence, no language will
ever surpass Lisp using that yardstick.

~~~
TurboHaskal
I also liked the article back in the day and drank the kool-aid.

Except that the averages ended up beating the nerds, which is empirically
observed by glancing at today's most successful and widely used software; and
Lisp today is a fringe idea with its most popular implementation being a JVM
transvestite.

As for Javascript being an acceptable Scheme, I'm personally happy to see it
merely running in the browser and the servers of a bunch of SV startups, where
it cannot do harm to society.

~~~
mvindahl
Dunno. I think for a startup it makes good sense to have a dynamic language
with a good package manager. For someone writing something which needs to be
performant, and the requirements don't change too much, C is probably a
superior choice. It's all about tradeoffs IMHO.

------
grzm
Article title: "The Hundred-Year Language"

(2003)

------
dang
Please don't use article titles to editorialize. From
[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html):

 _Please don 't do things to make titles stand out, like [...] adding a
parenthetical remark saying how great an article is. It's implicit in
submitting something that you think it's important._

~~~
zelah
Sorry about that. I would definitely change the title if I could but it seems
to be permanent now. Thank you for the feedback.

~~~
dang
Ok! We've changed it now.

