Hacker News Reader

Comment by kitd | Hacker News Reader

It is a pedagogical experiment to see just how well the interpreter (actually EVALQOUTE/APPLY) defined on page 13 of that book really works. The answer is: perfectly, of course.

Well timed! I've just been trying this out myself after reading Maxwell's Equations of Software [1]. It's fun realising that the "base" functions you're doing in Go can be reduced to even more fundamental forms using the Lisp you're implementing.

[1] http://www.righto.com/2008/07/maxwells-equations-of-software...

View on HN

Well-timed for you, but Pike could have benefited from doing this experimentation forty years earlier. Who knows where he would be now?

It's not like this is Pike's first contact with Lisp, he wrote an APL interpreter in it: https://www.youtube.com/watch?v=PXoG0WX0r_E

Note, that's not the topic of the talk, it's just mentioned in it.

I spoke to Rob shortly after he wrote this code (a few weeks ago). He said he had been wanting to do some coding over the weekend and pulled his copy of the LISP 1.5 Programmer's Manual - which he bought long ago, in grad school I think he said - off his shelf, and this code was the result. He also talked about how reading that book back when he bought it was incredibly eye-opening at the time and had such a significant influence on almost everything he's done in his career.

When I look through what Rob has done, I see a few patterns clearly traced to LISP, including a strong emphasis on recursive approaches and simplification by relying on functional (immutable) semantics. Look at the bitmap layers work, Newsqueak, Sawzall. There is of course also a heavy dose of pragmatism, which seems to be what you are criticizing.

Your question is therefore answerable: since he was in fact exposed to all that material forty years ago, he would be exactly where he ended up.

Not that there's much type theory in that book, but I'll note that Rob has also worked with type theorists in the past as well, notably Luca Cardelli on Squeak. And he was the one who suggested we approach Phil Wadler to help us work on the semantics of generics in Go. So again the ignorance about programming languages that your comment implies simply isn't accurate.

This pattern of assuming what other people know about is endemic on HN (and the internet more broadly, but especially so here), and it is harmful to productive discussion.

It's not worth responding to people like that, but it's funny now to point out that Wadler says in the Featherweight Go video that Go's type system has something that Haskell's type system may like to borrow, i.e. that interface types are open:

https://www.youtube.com/watch?v=Dq0WFigax_c

It's somewhere in the first 10-20 minutes (if someone wants to give a timestamp link)

(Also, my experience is that such comments usually get downvoted/flagged on HN, you just have to wait awhile)

https://youtu.be/Dq0WFigax_c?t=912

(on closed vs open and haskell)

I'm not sure what Philip meant there, but I don't see this as a particularly notable weakness of Haskell's type class system. We can already encode an open world through the standard "HasX"-style classes. There's a good reason that we don't use them much, though: type classes are typically not just interfaces but come with laws expressing how they should behave. It's not clear to me how those laws interact with an open world.

I wish I could upvote this twice. The classic "blub" post by Paul Graham is usually read in "upwards" direction where people using a language without some abstractions (say, monads or borrow checkers) can't understand why they would need it when looking at a language that has them. There is probably also a "downwards" interpretation where people using such a language can no longer understand that it's possible to be productive in languages that lack the advanced abstractions. Choosing just the right abstraction can be a distraction that gets in the way of "just building stuff", but if there is only one abstraction available then that's what will be used.

Interestingly, preaching the benefits of "simplicity" is also a very popular pastime on HN but that apparently does not extend to the languages used.

> The classic "blub" post by Paul Graham is usually read in "upwards" direction where people using a language without some abstractions (say, monads or borrow checkers) can't understand why they would need it when looking at a language that has them. There is probably also a "downwards" interpretation where people using such a language can no longer understand that it's possible to be productive in languages that lack the advanced abstractions.

Thank you, this is a very helpful framing of something I've recently been struggling to articulate about languages with sophisticated type systems after having surprisingly positive and productive experiences with Clojure and Go.

It looks a lot like a manifestation of incommensurability as observed by Kuhn:

https://en.wikipedia.org/wiki/Paradigm_shift#Incommensurabil...

This is exactly what we see. People adhering to different computing paradigms use some of the same words (e.g. "type"), but they have different meanings and basically they talk past each other as a result.

> This pattern of assuming what other people know about is endemic on HN (and the internet more broadly, but especially so here), and it is harmful to productive discussion.

That's not really what my comment is about; and I know very well who Pike is, and I'm assuming everyone here does. (Come on, legendary!)

Note that the phrase I used, "doing the experimentation", specifically avoids speaking to what Pike knows or doesn't know.

Yes, he might be a famous programmer like kazinator instead of the co-author of The Practice of Programming and one of the fathers of Go.

don't forget those insignificant little 'Unix' and 'Plan9'/'Inferno' things...

Whilst Pike contributed to Unix it was Thompson's and Ritchie's invention - at least originally

He also co-invented an obscure encoding called "utf-8" that nobody uses.

Only half as good as UTF-16.

Reply on news.ycombinator.com