undefined | Better HN

0 pointsSatvikBeri6mo ago0 comments

It's not too hard to adapt the first half of the book into whatever language you want. People have posted versions in dozens of languages: https://github.com/munificent/craftinginterpreters/wiki/Lox-...

(There are fewer options for the second half, since you need more control over memory management.)

0 comments

Conscat6mo ago

It's hard to say what "that hard" should be considered, but the book's first half involves Java reflection, which isn't obvious code to port to different languages in my opinion.

pansa26mo ago

> the book's first half involves Java reflection

Does it? I know it uses metaprogramming (a Java program that outputs another Java program), but that’s probably easier in other languages than in Java. In my Python implementation I was able to significantly simplify that part of the code by using `eval`.

scuff3d6mo ago

Yeah I don't recall reflection either.

I do remember him using the visitor pattern to implement part of the parser I think. I thought that was kind of an odd choice, especially since it seemed like he was really just trying to avoid Java boilerplate.

Regardless, the book is incredible, and the choice of Java to start with makes sense. Its probably going to be the most universally approachable for everyone, even if they aren't super familiar. C can be pretty overwhelming if you aren't familiar it.

pansa26mo ago

> I do remember him using the visitor pattern to implement part of the parser I think. I thought that was kind of an odd choice, especially since it seemed like he was really just trying to avoid Java boilerplate.

It's used to allow writing a "resolver" and an "interpreter" that both know how to handle every type of node in the AST. It's almost a functional approach, and I actually think it might increase boilerplate because Java is more designed around the object-oriented approach of adding `resolve` and `interpret` methods directly to each node type.

The two approaches result in very different code organisation, though - maybe the visitor approach was easier to explain in prose.

1 more reply

SatvikBeriOP6mo ago

It's been a few years now, but there's no real reason to port the Java code directly – you can just read what it's trying to do, and implement that using your language's idioms. I don't remember anything as complex as trying to port reflection.

j / k navigate · click thread line to collapse

0 comments

Conscat6mo ago

It's hard to say what "that hard" should be considered, but the book's first half involves Java reflection, which isn't obvious code to port to different languages in my opinion.

pansa26mo ago

> the book's first half involves Java reflection

scuff3d6mo ago

Yeah I don't recall reflection either.

pansa26mo ago

The two approaches result in very different code organisation, though - maybe the visitor approach was easier to explain in prose.

1 more reply

SatvikBeriOP6mo ago

j / k navigate · click thread line to collapse