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.
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.
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
It was back in '07-'09, we would take a few server laptops and a whole bunch of loaner laptops out to internal corporate seminars/conventions at like Bank of America, Hilton, etc.
It appears to still be active but using more modern devices and UX. [0]
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.”
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!"
"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
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.
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:
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.
language lawyer: n.. A person, usually an experienced or senior software engineer, who is intimately familiar with many or most of the numerous restrictions and features (both useful and esoteric) applicable to one or more computer programming languages. A language lawyer is distinguished by the ability to show you the five sentences scattered through a 200-plus-page manual that together imply the answer to your question “if only you had thought to look there”.
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
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.
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.
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.
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/