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

Crafting Interpreters

craftinginterpreters.com

Post reply on HN
Print view View original

101–110 of 193 posts

Re: Crafting Interpreters

#101

Post by kccqzy »

lifeinthevoid wrote: post #98

What bothered me a little bit while following the book was that copying the code doesn’t result in compilable code all the time because there is code missing that is only introduced later. I get why the author chose to follow this path, but I’m from the club that every commit should compile and was annoyed a bit by that.

I am the opposite. I think pedagogical materials like this should introduce things in the order that makes intuitive sense, and most of the time that means from the easiest to the hardest.

Re: Crafting Interpreters

#102

Post by kccqzy »

fooker wrote: post #76

This book should be the second or maybe third step of your journey into PL compilers. The first step is to write an interpreter yourself, for a simple language you create, without knowing anything about interpreters or language design. The second step is to rewrite it, and make less mistakes! :) If you don't do this, you are never going to appreciate the nuances of this topic. And you are going to skip over concepts…

That's exactly what I did. My own experience with the first step is to write a TeX-like language with macro definition and macro replacement. About a few days into the project I kept running into so many bugs that really instilled a more academic culture in me and I started to read books. But it was still a wonderful first step: without it you might not have even realized that this is a book-worthy topic.

Re: Crafting Interpreters

#103

Post by kccqzy »

xigoi wrote: post #56

Does anyone know of a good resoucce for creating a statically typed language with stuff like parametric polymorphism and basic type inference?

The main crux of parametric polymorphism and type inference is just implementing Algorithm W. Just find a toy implementation online and poke at it.

For me, when I learned it myself, I simply took the toy implementation at https://github.com/wh5a/Algorithm-W-Step-By-Step/blob/master... realized that it was written in an extremely outdated style, modernized it, cleaned up, and ended up with https://gist.github.com/kccqzy/fa8a8ae12a198b41c6339e8a5c459... Then I proceeded to change various things to "break" the algorithm and see how they are broken.

Re: Crafting Interpreters

#104

Post by cdcarter »

ayhanfuat wrote: post #82
tusharsadhwani wrote: post #47

Earlier quoted context omitted.

I finished this book, wrote the two implementations in Python and Zig, genuinely one of the best set of projects I've ever built.

How was the Zig experience? I am looking for an intermediate Zig project to practice Zig. Does this require advanced features of Zig?

I’ve also ported the lox vm to Zig and had a great time working through it.

Since the project is designed in C, you can mostly write the exact same code in zig, with minimal modifications. If you want to use zig features, they’re easy to integrate, but Nystrom obviously won’t be giving you any hints.

But the language offers a lot of useful features (slices, optionals, error types) and makes some C paradigms syntactic realities (tagged enums, explicit pointer casts). Even more so, the standard library comes with very useful stuff (an ArrayList, a handful of different allocators, heck I replaced the trie of keywords with a StaticStringMap).

it’s a fun project, I would definitely recommend it!

Re: Crafting Interpreters

#105

Post by cdcarter »

chasil wrote: post #10

The lex and yacc utilities are part of POSIX.2; is there any reason not to reach for them first? https://pubs.opengroup.org/onlinepubs/9699919799/utilities/l... https://pubs.opengroup.org/onlinepubs/9699919799/utilities/y... All the POSIX.2 standards for shell utilities can be found here: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ The original introduction to lex and yacc was in the book by Kernigan…

The Unix Programming Environment tutorial for building hoc doesn’t even come close to what Nystrom gets into in Crafting Interpreters. Hoc is a very fun little language, but as Nystrom describes several times in the book…parsing just isn’t the interesting part of the game.

Re: Crafting Interpreters

#106

Post by eyelidlessness »

metadat wrote: post #100
lifeinthevoid wrote: post #98

What bothered me a little bit while following the book was that copying the code doesn’t result in compilable code all the time because there is code missing that is only introduced later. I get why the author chose to follow this path, but I’m from the club that every commit should compile and was annoyed a bit by that.

What do you think the author's intention was behind doing it this way?

Doing it the other way is a common pitfall in teaching programming concepts. A very common example is the historically necessary boilerplate in Java’s Hello World, where quite a few concepts are present but handwaved away as you don’t need to worry about this now. The problem with this is twofold:

1. It is challenging to distinguish the pertinent from the impertinent. People who are just starting won’t be able to tell what parts of the code deserve their attention now.

2. It is challenging to retroactively draw attention to previously dismissed details once they do become pertinent.

I think there are other ways to address this, with additional formatting considerations in the presentation of example code. But there’s still a problem once the reader wants to tinker with the code, as any such formatting will be lost between a carefully tailored example rendering and the user’s code editor.

Re: Crafting Interpreters

#107

Post by ufo »

runevault wrote: post #29
chasil wrote: post #10

The lex and yacc utilities are part of POSIX.2; is there any reason not to reach for them first? https://pubs.opengroup.org/onlinepubs/9699919799/utilities/l... https://pubs.opengroup.org/onlinepubs/9699919799/utilities/y... All the POSIX.2 standards for shell utilities can be found here: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ The original introduction to lex and yacc was in the book by Kernigan…

Does a single production compiler use lex and yacc to generate any part of their system, beyond maybe a first pass to test out syntax before it gets rewritten into a hand written parser/lexer? I'm not going to say none exist since I don't know literally every production compiler ever written, but I have never heard of one that used them for the final code.

Python notably switched from hand written recursive descent, to a PEG based parser generator.

But indeed, last I checked, recursive descent was the most common choice overall.

Re: Crafting Interpreters

#108

Post by apstls »

liamilan wrote: post #21

Read Crafting Interpreters when building Crumb ( https://github.com/liam-ilan/crumb ). It was indispensable, especially the sections on scope and local variables. The balance between technical implementation and conceptual insights is super helpful, especially when trying to go off of the book’s set path. It’s inspiring to see technical writing done like this. As an aspiring engineer, this sets a really high standard…

> when building Crumb (https://github.com/liam-ilan/crumb)

> As an aspiring engineer

I’ve got some good news for you.

Re: Crafting Interpreters

#109

Post by BoiledCabbage »

eyelidlessness wrote: post #106
metadat wrote: post #100

Earlier quoted context omitted.

What do you think the author's intention was behind doing it this way?

Doing it the other way is a common pitfall in teaching programming concepts. A very common example is the historically necessary boilerplate in Java’s Hello World, where quite a few concepts are present but handwaved away as you don’t need to worry about this now . The problem with this is twofold: 1. It is challenging to distinguish the pertinent from the impertinent. People who are just starting won’t be able to te…

> Doing it the other way is a common pitfall in teaching programming concepts.

100% disagree

If someone is brand new to programming and you're expecting to teach them the following concepts:

A class, methods, static methods, data types, method return types, void return type, arrays, and namespaces just to be able to write a simple "Hello World" app [1] I think your approach is the one that's misguided.

The most common mistaken people make in teching is teaching things in the order the were discovered historically. Not always, but very often that is a distraction. The second most common is teaching from the outside in.

The best way to teach is to explain what your tyring to accomplish and start with a very simple example for people to play with. Then pick on concept and modify it so they can see the results of those changes. Then pick the next concet and modify that so they can see tangibly what that means.

In the hello world example, it would be starting with the program in [1] and focusing just on the constant string "Hello World!". Change it see what that means, understand what's going on. Then move out to the Console.WriteLine. Make a copy of that line have two lines of it then 3 to understand the method call. Then swap to Console.ReadLine to see what a different method call can do. Continue exploring out from that core concept.

The "static" identifier on a method class is not where to start teaching someone programming.

It's also why Racket removed a lot of the boiler plate from thier core teaching langauges for students. For them to not even have to see the things that are unnecessary at that point in their learning.[2]

[1] https://www.geeksforgeeks.org/java-hello-world-program/ [2] https://docs.racket-lang.org/drracket/htdp-langs.html

Re: Crafting Interpreters

#110

Post by phyrex »

sva_ wrote: post #91
chris37879 wrote: post #8

I feel like this is a book most programmers should work through at some point or another. Doing so made me really appreciate just what's going on inside a compiler / language toolkit. It's also one of the most well written technical guides I've ever followed, it really helped me internalize the concepts, and they are useful all over the place, not just in compilers.

This comment sold me. Gonna keep this as an inactive tab for the next couple months.

Why not buy an copy and put it on your to-read shelf for the next couple of months?
Post reply on HN