Robpike/Lisp: Toy Lisp 1.5 interpreter in Go • Hacker News Board

Re: Robpike/Lisp: Toy Lisp 1.5 interpreter in Go

#41

Post by rsc » Wed, Jun 17, 2020, 4:33 PM UTC

kazinator wrote: post #28

kitd wrote: post #14

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

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

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.

Re: Robpike/Lisp: Toy Lisp 1.5 interpreter in Go

#42

Post by mseepgood » Wed, Jun 17, 2020, 4:52 PM UTC

monocasa wrote: post #40

mseepgood wrote: post #36

Earlier quoted context omitted.

I thought that maybe he is teaching Google employees.

I'm pretty sure it's a small project to teach himself.

Maybe, but the phrasing is "I plan to use this as a teaching tool" and not "I did this as a learning experience".

Re: Robpike/Lisp: Toy Lisp 1.5 interpreter in Go

#43

Post by libria » Wed, Jun 17, 2020, 4:55 PM UTC

melling wrote: post #17

chewxy wrote: post #7

I hope one day when I grow old I get to engage in fun pasttimes like what Rob did.

Balance is important too. He won a Silver Medal for archery in the Olympics.

I was impressed at first, but then I saw the David Letterman bit. An olympic medal is far more believable than a talk show host interested in a computer scientist.

Re: Robpike/Lisp: Toy Lisp 1.5 interpreter in Go

#44

Post by earthboundkid » Wed, Jun 17, 2020, 5:09 PM UTC

kazinator wrote: post #28

kitd wrote: post #14

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

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

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.

Re: Robpike/Lisp: Toy Lisp 1.5 interpreter in Go

#45

Post by chubot » Wed, Jun 17, 2020, 5:12 PM UTC

rsc wrote: post #41

kazinator wrote: post #28

Earlier quoted context omitted.

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

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

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)

Re: Robpike/Lisp: Toy Lisp 1.5 interpreter in Go

#46

Post by chubot » Wed, Jun 17, 2020, 5:15 PM UTC

kgwxd wrote: post #32

chewxy wrote: post #7

I hope one day when I grow old I get to engage in fun pasttimes like what Rob did.

A few weeks ago, I went through "Make a Lisp" [1] using C#. It only took a few days to get to a pretty useful implementation. I "cheated" quite a bit using the existing C# implementation from the repo as a reference, but my end result looks pretty different. Learned a TON. Highly recommended. [1] https://github.com/kanaka/mal

As of a few days ago, the mal bash implementation runs under Oil :)

https://github.com/kanaka/mal/pull/518

Re: Robpike/Lisp: Toy Lisp 1.5 interpreter in Go

#47

Post by WJW » Wed, Jun 17, 2020, 5:20 PM UTC

rsc wrote: post #41

kazinator wrote: post #28

Earlier quoted context omitted.

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

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

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.

Re: Robpike/Lisp: Toy Lisp 1.5 interpreter in Go

#48

Post by morelisp » Wed, Jun 17, 2020, 5:20 PM UTC

klodolph wrote: post #37

Interesting: https://github.com/robpike/lisp/blob/master/lisp1_5/parse.go... // Expr represents an arbitrary expression. type Expr struct { // An Expr is either an atom, with atom set, or a list, with car and cdr set. // Car and cdr can be nil (empty) even if atom is nil. car *Expr atom *token cdr *Expr } Instead of using interface types for expressions, there is a simple expression structure type with fields that ma…

See also: Nearly every time I see someone trying to use `oneof` in protobuf...

Re: Robpike/Lisp: Toy Lisp 1.5 interpreter in Go

#49

Post by cat199 » Wed, Jun 17, 2020, 5:28 PM UTC

earthboundkid wrote: post #44

kazinator wrote: post #28

Earlier quoted context omitted.

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

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

Re: Robpike/Lisp: Toy Lisp 1.5 interpreter in Go

#50

Post by kodablah » Wed, Jun 17, 2020, 5:29 PM UTC

klodolph wrote: post #37

Interesting: https://github.com/robpike/lisp/blob/master/lisp1_5/parse.go... // Expr represents an arbitrary expression. type Expr struct { // An Expr is either an atom, with atom set, or a list, with car and cdr set. // Car and cdr can be nil (empty) even if atom is nil. car *Expr atom *token cdr *Expr } Instead of using interface types for expressions, there is a simple expression structure type with fields that ma…

> I probably never would have done it that way, I would probably use an interface type instead

I think when you're all in the same package and accessing unexported fields you know about, this is much clearer than an interface. I often add unexported mutually exclusive fields that local code has advanced knowledge about to prevent unnecessary over-abstraction.