Live data from Hacker News

The Hundred-Year Language (2003)

paulgraham.com

11–20 of 22 posts

Re: The Hundred-Year Language (2003)

#11
post #2

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 proo…

Does "proven" here mean the same thing as "no runtime errors"?

I've recently tried out Elm [1] and have come away with a similar perspective on functional programming and static typing. The benefits I noticed are:

- Because of the static typing and strict management of data/state, the compiler is very good at telling you where the errors in your code are.

- If the compiler is happy, there are essentially no runtime errors.

- While I didn't write any tests, unit testing seems like it would be trivial because every function is stateless.

- You're forced to write better code. I find that Elm is pleasantly constraining. It's an opinionated language that forces you into certain design patterns, but they always seemed like the design pattern I should be using anyway.

Overall, I haven't been more impressed by a language since I discovered Ruby a decade ago. If you could do backend development in Elm I would probably try using it as my primary language.

1. If anyone else is interested, I went through the Pragmatic Studio Elm course: https://pragmaticstudio.com/courses/elm. I have no affiliation with them, just thought it was a really well done course and would recommend it to others who want to try out Elm.

Re: The Hundred-Year Language (2003)

#12
post #4

Earlier quoted context omitted.

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.

> 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 -- t…

> 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"?

Re: The Hundred-Year Language (2003)

#13
post #11
post #2

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 proo…

Does "proven" here mean the same thing as "no runtime errors"? I've recently tried out Elm [1] and have come away with a similar perspective on functional programming and static typing. The benefits I noticed are: - Because of the static typing and strict management of data/state, the compiler is very good at telling you where the errors in your code are. - If the compiler is happy, there are essentially no runtime e…

No, it's referring to formal methods. Elm will prevent you from writing a binary search that returns a string, but will happily admit a broken binary search that (say) never terminates, or always returns 0. Formal methods allow you to catch that class of mistakes.

I don't see any case for a functional-programming inspired change now. 30 years ago programmers were enlighten by LISP, 15 years ago I was enlightened by OCaml, and today's generation is enlightened by Haskell, or in your case Elm. What's different now?

If anything I think we're moving in the opposite direction. Development speed is now king, and deployment is easier than it's ever been, which means that bugs are less costly to fix. Bondage-and-discipline type languages that promise fewer bugs for more work are just less relevant.

Re: The Hundred-Year Language (2003)

#14
post #4

Earlier quoted context omitted.

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.

> 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 -- t…

What industries are using formal methods to not crash things? Honest question. What I see is the opposite - Uber and (to a lesser extent) Tesla cowboying their way towards autonomous vehicles. The idea of formally verifying a DNN image classifier seems absurd.

And the old guard is even worse - recall Jeep's entertainment unit remote hack, or Toyota's 10,000 global variables? Those guys can't handle basic software engineering practices, let alone formally verified programs.

Re: The Hundred-Year Language (2003)

#15
"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.

Re: The Hundred-Year Language (2003)

#16
post #12

Earlier quoted context omitted.

> 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 -- t…

> 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…

> 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.

Re: The Hundred-Year Language (2003)

#17

Earlier quoted context omitted.

> 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 -- t…

What industries are using formal methods to not crash things? Honest question. What I see is the opposite - Uber and (to a lesser extent) Tesla cowboying their way towards autonomous vehicles. The idea of formally verifying a DNN image classifier seems absurd. And the old guard is even worse - recall Jeep's entertainment unit remote hack, or Toyota's 10,000 global variables? Those guys can't handle basic software eng…

> What industries are using formal methods to not crash things?

Aerospace and chip design are the two major industries that make regular use of formal methods.

> Uber and... Tesla... cowboying... And the old guard is even worse - recall Jeep...

Yes, most of the auto industry has been slow to the table when it comes to taking software quality and capability seriously.

Uber has a prototype, not a product, and Tesla has a young product. We'll see what engineering practices they adopt over the next 15 years.

> The idea of formally verifying a DNN image classifier seems absurd

https://www.google.com/search?q=verification+of+deep+neural+...

Re: The Hundred-Year Language (2003)

#18

"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 b…

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.

Re: The Hundred-Year Language (2003)

#19
post #10
post #7

Please don't use article titles to editorialize. From 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.

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

Ok! We've changed it now.

Re: The Hundred-Year Language (2003)

#20
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...

Post reply on HN