Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

(How to Write a (Lisp) Interpreter (In Python)) (2010)

norvig.com

Post reply on HN
Print view View original

91–100 of 101 posts

Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)

#91

Post by __rito__ »

pjmlp wrote: post #15

Given Peter Norvig's work on Lisp and Python, pity that after 24 years, his "Python for Lisp Programmers" essay from 2000 is still mostly true. Python might have overtaken Lisp's role in AI, but still needs some catching up in tooling. "The two main drawbacks of Python from my point of view are (1) there is very little compile-time error analysis and type declaration, even less than Lisp, and (2) execution time is mu…

> wouldn't recommend Python for applications that are (or are likely to become over time) compute intensive (unless you are willing to move the speed bottlenecks into C)

The compute intensive parts of AI already always happen in CUDA/C++/C.

Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)

#92

Post by CyberDildonics »

bitwize wrote: post #88
CyberDildonics wrote: post #80

Earlier quoted context omitted.

Sounds like most scripting languages.

Scripting languages typically do not retroactively update existing instances. Afaik Common Lisp and Smalltalk are the only languages that do this.

It's easy to just assign different functions to a metatable in lua.

That isn't the point though. You were saying lisp is some mystical thing and it is 66 years old. Its influence happened decades ago. It isn't about every language having every feature. Pretty much all software is made without lots of the features in lisp because not every tradeoff is worth it. Lisp itself is barely used because it isn't about a check list of features, but pragmatism of an ecosystem, syntax, actual compilation etc are all crucial. Lisp is not a modern tool, it is an influential invention from over half a century ago.

When people are stuck on an airplane, they don't try to watch citizen kane, they want to watch literally anything else. Influential isn't the same as being good by modern standards. People don't want to write lisp and people don't want to use software written in lisp. Sorry for the harsh reality check.

Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)

#93

Post by BrendanEich »

actionfromafar wrote: post #33
djtriptych wrote: post #32

At some point I translated this demo into es6 if anyone's interested [0]. The focus was really on writing the cleanest idiomatic es6 I could (at the time :)). Check out the tests to see how far I got [1] Pretty fun exercise =) [0]: https://github.com/djtriptych/es6-lisp [1]: https://github.com/djtriptych/es6-lisp/blob/master/test/lisp...

It's a fun thing to try, since Javascript almost was to be a Lisp at inception!

The Java deal killed any Scheme in the browser I might have done in ten days in May 1995. Almost 29 years ago!

Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)

#94

Post by throwaway87651 »

djtriptych wrote: post #36
actionfromafar wrote: post #33

Earlier quoted context omitted.

It's a fun thing to try, since Javascript almost was to be a Lisp at inception!

Someone once said Javascript is a "Scheme-like language with C-like syntax". Always loved that and ashamed I can't remember the original author of the quote. Not Crockford... Maybe Michael Fogus?

Crockford: "Lisp in C's Clothing"

https://www.crockford.com/javascript/javascript.html

Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)

#95

Post by pjmlp »

__rito__ wrote: post #91
pjmlp wrote: post #15

Given Peter Norvig's work on Lisp and Python, pity that after 24 years, his "Python for Lisp Programmers" essay from 2000 is still mostly true. Python might have overtaken Lisp's role in AI, but still needs some catching up in tooling. "The two main drawbacks of Python from my point of view are (1) there is very little compile-time error analysis and type declaration, even less than Lisp, and (2) execution time is mu…

> wouldn't recommend Python for applications that are (or are likely to become over time) compute intensive (unless you are willing to move the speed bottlenecks into C) The compute intensive parts of AI already always happen in CUDA/C++/C.

The difference is that Lisp doesn't require a two language syndrome.

Julia, Mojo, XLA, Triton,... are picking up speed, and the pressure for a JIT on CPython is increasing from Microsoft and Facebook, exactly because not everything is AI, and not everyone wants to write C++, C to speed up Python.

Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)

#97

Post by deosjr »

kingkongjaffa wrote: post #6

> The beauty of Scheme is that the full language only needs 5 keywords and 8 syntactic forms. Is there a learning resource that covers exactly this for those wanting to write software in lisp in 2024? As "first principle thinkers" in some ways all hackers crave for that "fundamental building blocks approach", a bit like wanting to know how we go from transistors to full computers and every step along the way. Most of…

My way of learning about Lisp was based on first principles, after reading Norvigs blogpost many times and working through SICP. What helped is that I had just finished the nand2tetris book, which is very much a first principles speedrun of how a computer works.

So I built my own Lisp machine based on the nand2tetris architecture, with lisp instructions supported on the simulated chip level. I'm currently in the progress of doing a writeup of the project, you can see my attempts here if you are interested: https://deosjr.github.io/

I have an almost working version of a REPL running on the machine now, including garbage collection and parsing Lisp with Lisp and passing the output to an eval function written in assembly (the operating system, if you will).

Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)

#98

Post by CyberDildonics »

bitwize wrote: post #87
kryptiskt wrote: post #75

Earlier quoted context omitted.

Scheme has pioneered a lot of stuff over the last 30-40 years that is still fresh for most of the PL world, hygienic macros (like Rust is trying to implement), delimited continuations (which underlies Java's new virtual threads, see https://www.youtube.com/watch?v=9vupFNsND6o ), efficient closure representations (used all over the place since everybody got lambda fever). Into formal verification? Scheme was there in…

Insert meme of Nolan Grayson, representing Lisp/Scheme/Racket programmers, pointing at fighter jets labeled "transpilers" and saying: "Look at what they need to mimic just a fraction of our power!"

I think the roles would be reversed when trying to make fast, small interactive software that people want to use. "Powerful" is interesting but clear, straightforward and fast is better. No web browser, database, video codec, or high end video game is written in scheme. At best it's inefficient ancillary software that someone wrote in scheme because they wanted to, not because that's what a user wanted.

Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)

#99

Post by ja321 »

pjmlp wrote: post #95
__rito__ wrote: post #91

Earlier quoted context omitted.

> wouldn't recommend Python for applications that are (or are likely to become over time) compute intensive (unless you are willing to move the speed bottlenecks into C) The compute intensive parts of AI already always happen in CUDA/C++/C.

The difference is that Lisp doesn't require a two language syndrome. Julia, Mojo, XLA, Triton,... are picking up speed, and the pressure for a JIT on CPython is increasing from Microsoft and Facebook, exactly because not everything is AI, and not everyone wants to write C++, C to speed up Python.

Ok the other hand, a good lisp implementation of neural nets would offer a specific set of macros dedicated to matrix operations. This set of macros is, in the lisp point of view, a domain specific language. So, you still have 2 languages.

Re: (How to Write a (Lisp) Interpreter (In Python)) (2010)

#100

Post by kazinator »

wtetzner wrote: post #74
CyberDildonics wrote: post #57

Earlier quoted context omitted.

You think lisp is "weird and sinister or ghostly" and that 'we' are still wrestling with something 66 years later? This sounds more like someone getting caught up in the pageantry of a niche that pragmatic people have left behind a long time ago. Lisp was very influential, but those advancement have made their way into practical languages and lisp has been impractical for many decades at this point.

> those advancement have made their way into practical languages I agree with this for the most part, though I've yet to see a non-lisp language support macros as nicely as Scheme's syntax-case. Also, while Lisp's features have made their way into modern languages, there are very few that contain all of them at the same time. > those advancement have made their way into practical languages I disagree with this.

A language that contains all Lisp features becomes identifiable as a member of the Lisp family, and is then removed from the discussion of languages that don't have all Lisp features.
Post reply on HN