top | item 24383919

Growing a Language (1998) [video]

167 points| tosh | 5 years ago |youtube.com | reply

34 comments

order
[+] tikhonj|5 years ago|reply
Absolutely my favorite tech talk—brilliant idea that's explained so well it seems obvious in hindsight, even though it really wasn't. It's rare for a single talk to change my fundamental way of thinking about an area I already care about (programming language design), and "Growing a Language" managed it in a big way.

It applies to more than just language design too. Why do I love Emacs so much? It isn't the idiosyncratic terminology or weird keybindings, it's the fact that Emacs is an editor that grows. Once I understood basic Elisp, there was no real friction to take Emacs and start molding it to exactly my needs and preferences. Something I don't like? Something that's missing? I don't have to spend hours setting up a plugin to fix it; chances are it will only take a few lines to change whatever I want to change, and I can use Emacs's remarkable discovery features to quickly find which lines those are.

Why do people swear by command-line invocations and bash? Bash is awful. But it's an environment that grows in a way that I've never seen with GUI apps. A small set of simple tools and a universal way to compose them is remarkably powerful, even if it's as awkward and error-prone as POSIX shell scripting.

Excel? I don't use it myself, but I've seen the same thing from Excel power users: it goes beyond mere calculations to letting people seamlessly build what they need on top of Excel. Excel is integral to the modern world in a way that no other pieces of office software is because it can grow to solve complex problems in a way other tools can't. (With, as I've seen working at a large company, occasionally terrifying consequences.)

What I would really love to see next is an alternative to Jupyter that can grow in the same way. Maybe gtoolkit[1] is a candidate? That's what I'm exploring now, and it's pretty exciting so far.

[1]: https://gtoolkit.com/

[+] DylanDmitri|5 years ago|reply
Thank you for sharing gtoolkit! I’m also looking for the sequel to Jupyter, something that gives the same speed of iteration but with the ability to scale to production systems.
[+] datalus|5 years ago|reply
I used to work for a company that made simulation based corporate training games. All the data was modeled in Excel and served as a database to read from and write back to during runtime.

The frontend was written in Flash. I was the sole frontend developer for one of the projects in this space and the backend had always amazed me. The Excel sheets were nuts :D

[+] dang|5 years ago|reply
[+] pfarrell|5 years ago|reply
This is a great example of content that should get reposted every six months or so. Every budding programmer should digest it.

Also, this line cracks me up every time.

“I have to say the full phrase “Java programming language,” for there is a guy who works where I do who deals with the laws of marks of trade, and he told me I have to say it that way.”

[+] mathgladiator|5 years ago|reply
This was good, and much needed.

I'm currently writing my own programming language, and I'm thinking about how to I encourage growth since I'm realizing that I'm still at the starting line.

I'm sorting out how I balance out "telling people and inviting people in" versus "how do I polish what I want to polish?" versus "use the damn thing to make things!"

The language is: http://www.adama-lang.org/ and it is a work in progress

[+] samatman|5 years ago|reply
Very cool. Focusing on a domain is a good idea and this strikes me as a good domain to focus on.

While I've never managed to write anything useful in Inform 7, I'm glad it exists; it stretched my idea of what a programming language can be.

Good luck!

[+] nabla9|5 years ago|reply
"And you're right: we were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. Aren't you happy?"

  – Guy Steele responding CL programmer criticism of Java
[+] roca|5 years ago|reply
I was lucky enough to be at that talk in '98. I distinctly remember the "what the hell is going on" vibe at the start. It felt like a Christopher Nolan movie.
[+] pixelmonkey|5 years ago|reply
One of my favorite tech talks of all time. Really worth just sitting down and truly listening to its full length, regardless of what programming tradition you come from. I wrote some commentary on it related to a different HN post here:

https://news.ycombinator.com/item?id=10568382

[+] balfirevic|5 years ago|reply
It's not often that "art" and "computer science lecture" sets overlap.
[+] nabla9|5 years ago|reply
Steele is the definition of "language lawyer". He knows programming languages. He has been part of ANSI C, Common Lisp, Scheme and Java language standardization.

He has coauthored "C: A Reference Manual", Common Lisp the Language, Performance Fortran Handbook, and The Java Language Specification.

[+] gumby|5 years ago|reply
Also JavaScript, and is responsible for it technically being ECMAScript
[+] swyx|5 years ago|reply
so does anyone know why he apparently failed to get his proposed changes through? given that the talk was so well regarded, it's curious it had zero impact
[+] db48x|5 years ago|reply
Worth watching even if you hate Java.
[+] throwawaw|5 years ago|reply
I can't believe I had never seen this. Thank you.
[+] jdontillman|5 years ago|reply
For some reason that version has a large number of audio glitches.

But very recently the Computer History Museum published a cleaned-up version:

https://youtu.be/lw6TaiXzHAE

Good!

[+] pfarrell|5 years ago|reply
Thank you for that link. Even back to when this talk was hosted on google video, it’s always had the glitches. And because of the nature of this talk, they take away from Steele’s excellent timing.
[+] jecel|5 years ago|reply
It is interesting that the hand drawn retro-projector slides have been replaced with computer graphic ones. It reminded me of the upgrades in the original Star Trek series for the Blue Ray release.
[+] jdontillman|5 years ago|reply
And the old version still has some great comments.
[+] tosh|5 years ago|reply
wow, thank you!
[+] DreamOther|5 years ago|reply
Its funny, I enjoy python for different reasons. The import statement and all the "allowing the language to grow" is great, but not what makes me use it over competitors. In fact, I'd argue pip and virtualenv are kind of worse to use than npm, go get, rust crates etc - some might disagree here, but I feel the experience could be a lot better.

Main reasons I love and continue to use python...

1. Python 2/3 break. A breaking update sounds scary, but getting rid of the accumulation of "language warts" all at once was literally amazing. And by all at once, I mean a gradual transition over a decade. I also think Node's way of having individual API's have an independent "stability" metric that is unrelated to the platform or language is another decent way of handling this.

2. They've taken great care with the most common data structures, with regard to both performance and ergonomics. A python dictionary is wonderful to use and is actually quite fast (specialized for common cases and transparently alters hashing algorithms depending on input). You can use any immutable data structure as a key (tuples!). Its so nice.

3. For somewhat complicated work, the standard library actually has all the good stuff baked in. heapq, deque, bisect, permutations, combinations, lru, and the list goes on. Then convenience oriented data structures like Counter, defaultdict and such that other languages would balk at adding. When you have stuff like list and dictionary comprehensions layered on top of these baseline algorithmic tools, it feels so damn good. Do these things have warts? Yes, sometimes. Like heapq is default min heap with no way to change the behavior other than negating the input/output - but I don't care, its there, and its usable and you can explore it to the edges pretty quickly.

The only still-pretty-shitty parts that makes it less than perfect in my eyes is the GIL combined with asyncio/async/await being modal.

This is just a guess, but it seems like languages that over-specify internals paired with a goal of never breaking backwards compatibility are doomed to ... not fail, clearly, but to be a pain in the ass to use forever. Take unordered_map from C++: what an unholy mess made out of the most common data structure in computer science. Yes, you can use Google's swiss table impl in Abseil or some competitor, but the fact that I have an unwieldy poorly designed hash map baked into standard library for all time is such a missed opportunity. std::async was a huge missed opportunity as well (bad default arguments, not guaranteed to be backed by a thread pool).

In short, not allowing for mistakes is a tragedy that creates pressure to over-specify, which I think damages everything in ways you cannot predict.

[+] chubot|5 years ago|reply
At the beginning of the talk he needs to define "person" in terms of one word axioms. So he takes "man" as an axiom, and says:

A woman is like a man but not of the same sex

and

A person is a man or woman

How about just:

A person is a kind of ape. It can talk, make tools, and walk on two legs. It has hands and thumbs.

[+] buzzwordninja|5 years ago|reply
Because that does not illustrate the concept of building a language as clearly and succinctly.