[HN Gopher] Growing a Language (1998) [video]
___________________________________________________________________
Growing a Language (1998) [video]
Author : tosh
Score : 92 points
Date : 2020-09-05 14:46 UTC (8 hours ago)
(HTM) web link (www.youtube.com)
(TXT) w3m dump (www.youtube.com)
| nabla9 wrote:
| 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.
| dang wrote:
| Doesn't language lawyer usually imply pedantry? That's not Guy
| Steele. How about language ascended master?
|
| https://en.wikisource.org/wiki/Lambda_Papers
| agumonkey wrote:
| btw to all the curious with enough time on their hands, these
| lambda papers are really worth a read.
|
| 40 pages.. high density of ideas.
| nabla9 wrote:
| _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".
|
| http://catb.org/jargon/html/L/language-lawyer.html
| [deleted]
| gumby wrote:
| Also JavaScript, and is responsible for it technically being
| ECMAScript
| [deleted]
| DreamOther wrote:
| 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.
| ngrilly wrote:
| One of the best tech talk ever. Great example of a mise en abyme.
| gjvc wrote:
| https://en.wikipedia.org/wiki/Mise_en_abyme
| chubot wrote:
| 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._
| [deleted]
| jdontillman wrote:
| 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!
| tosh wrote:
| wow, thank you!
| pfarrell wrote:
| 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.
| jdontillman wrote:
| And the old version still has some great comments.
| dang wrote:
| Changed from https://www.youtube.com/watch?v=_ahvzDzKdB0.
| Thanks!
| mathgladiator wrote:
| 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
| balfirevic wrote:
| It's not often that "art" and "computer science lecture" sets
| overlap.
| pixelmonkey wrote:
| 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
| dang wrote:
| Previous threads about this classic, but HN has perhaps not
| really done it justice yet:
|
| 2018: https://news.ycombinator.com/item?id=16847691
|
| 2015: https://news.ycombinator.com/item?id=9918286
|
| 2015: https://news.ycombinator.com/item?id=10153391
|
| 2012: https://news.ycombinator.com/item?id=3744125 (seanmcdirmid
| was there!)
|
| 2011: https://news.ycombinator.com/item?id=2359174
|
| 2009: https://news.ycombinator.com/item?id=626380
|
| 2009 (2 comments): https://news.ycombinator.com/item?id=827107
|
| 2008: https://news.ycombinator.com/item?id=152311
|
| 2007 (1 comment): https://news.ycombinator.com/item?id=92542
| db48x wrote:
| Worth watching even if you hate Java.
| tikhonj wrote:
| 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/
| pfarrell wrote:
| 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."
___________________________________________________________________
(page generated 2020-09-05 23:00 UTC)