6 ms·

I hesitated a little bit before deciding to purchase and go through the book. Had already read many glowing reviews then, but was not sure if the choice of lang

by bow_ 4y ago

I hesitated a little bit before deciding to purchase and go through the book. Had already read many glowing reviews then, but was not sure if the choice of language (Java) for the first half of the book would be a hindrance (it's not the stack I am most familiar with). Decided to buy it anyway, primarily because the two implementations of the toy language piqued my interest (most other books only go through one implementation). Boy was I glad I did. Writing is superb, end-of-chapter challenges are instructive, code samples are meticulously and beautifully done. Here and there I also encountered references to other languages (e.g. had a brief detour to Lua internals [1], thanks to a side note), which I have enjoyed too. Went through the first half twice: first using Java as it is written and then secondly implemented the interpreter in Rust (my initial fear turned out to be unfounded). Currently going through the second half. So if you're reading this, thank you, Bob :). [1] https://www.lua.org/doc/jucs05.pdf https://www.lua.org/doc/jucs05.pdf

munificent 4y ago
You're welcome! :D
danhau 4y ago
Does the book go into more „modern“ parser architectures ala Roslyn Red Green Trees?
- llimllib 4y ago
  You can read it on the web here: https://craftinginterpreters.com/contents.html https://craftinginterpreters.com/contents.html (I don't know how to answer your question accurately)
- throwaway17_17 4y ago
  The parser’s data structure is a more traditional Abstract Syntax Node design. Roslyn’s tree design is, IMO, a good internal structure for use in a production-grade compiler meant to be coupled with a developer environment (IDE and other tools) because the complexity pays off in terms of developer experience. However, Bob set out (as far as I can tell from the book and his talks/comments on the subject) to provide a fairly beginner friendly, introduction to the topic of language implementation. Within his chosen scope the parser implementation in Crafting Interpreters is more than sufficient and clearly presents the concepts intended.
- DylanSp 4y ago
  IIRC, Roslyn's red-green tree approach is at least partly due to needing to support interactive editing without re-parsing everything. If that's what you're referring to, no, the book doesn't cover that; both interpreters run either in batch mode on a single file or in a simple REPL.
- Banana699 4y ago
  Crafting is less about modern or production-grade anything and more about understanding fundamentals. It would be equally at home in a 1980s compilers and language design course or in a 2000s version of that course. It has a single motivating principle, which is that a learner who understands the bare basics of algorithms and data structures knows, in the truest sense of the word, what a compiler and an interpreter does. It achieves that principle beautifully.
- runevault 4y ago
  If you're interested in Roslyn inspired compiler writing, Immo Landwerth who works on as a Program Manager on .NET made a Youtube series about writing a compiler, and my understanding from the part I watched is his work is heavily inspired by Roslyn. https://www.youtube.com/playlist?list=PLRAdsfhKI4OWNOSfS7EUu5GRAVmze1t2y https://www.youtube.com/playlist?list=PLRAdsfhKI4OWNOSfS7EUu...
62951413 4y ago
Using Java was a poor choice (especially without the latest improvements such as records and switch expressions): * new books should use more modern popular languages to age well and to attract younger audience * on the JVM there are languages better suited for the topic (e.g. Scala by a large margin) * There's already the "Language Implementation Patterns" book (https://www.amazon.com/Language-Implementation-Patterns-Domain-Specific-Programming/dp/193435645X https://www.amazon.com/Language-Implementation-Patterns-Doma...) which not only is great for teaching because of its pattern-based approach but also gives you real life skills (e.g. ANTLR is used in most big data query engines)
- tomcam 4y ago
  You sound pretty smart! How about writing that book for the rest of us?
- alcover 4y ago
  > Language Implementation Patterns I hear the code examples are in Java. I think that's unfortunate. (And a bit ironic about your post).
  - vips7L 4y ago
    If you actually take the time to read the book Bob explains the choice. And fwiw modern Java is decently expressive without adding the unneeded complexity of Scala or something similar. edit: replied to the wrong post. /shrug
- Zababa 4y ago
  > new books should use more modern popular languages to age well and to attract younger audience That doesn't make sense. Java is one of the most popular programming language, more popular than a lot of other "modern popular languages". The only languages more popular are either as old as Java (JavaScript, Python) or older (C, C++). C# might be one option, but it's close to Java, and I don't know if the support for Linux/MacOS was here at the time this book was started. Same thing for JavaScript and Python's popularity, which are relatively recent trends. On the other hand, Java has stayed and endured. It's still here and will still probably be here in 20 years. > on the JVM there are languages better suited for the topic (e.g. Scala by a large margin) Scala is less popular than Java, and harder to master. Once you consider Scala, you get into endless arguments about whether to use Scala, SML, OCaml, Haskell, etc. > There's already the "Language Implementation Patterns" book There is also "Writing an interpreter in Go" and "Writing a compiler in Go" that seem to cover the same ground. But I'm certain than more people know about interpreters and compilers thanks to these three books than thanks to any one of them. > but also gives you real life skills (e.g. ANTLR is used in most big data query engines) The majority of programming languages don't use a generated parser but a handmade recursive descent parser, because it's the best at error reporting. There's a good post about different parsing approaches by Laurence Tratt: https://tratt.net/laurie/essays/entries/which_parsing_approach.html https://tratt.net/laurie/essays/entries/which_parsing_approa.... Generated parsers are great for DSLs but that won't teach you how the programming languages that you use work.
RyanHamilton 4y ago
I fully agree. Superb, "meticulously and beautifully done". I read it online and followed along writing code then bought the book just to support the author. Thanks Bob.
rightbyte 4y ago
> was not sure if the choice of language (Java) for the first half of the book would be a hindrance I think it is refreshing he uses a "boring" language.
- bigDinosaur 4y ago
  The way you phrase that makes it sound like you're implying there isn't an overwhelming dominance in terms of 'boring languages' and tutorials/content/books/training material. HN presumably doesn't upvote Java book #10^6 unless it is quite unique otherwise.
- bow_ 4y ago
  I didn't worry because of Java's perceived lack of 'excitement'. Just that I am more familiar with other languages and I worried I'd get lost trying to understand Java and not digest the material properly. I tend to fall down rabbit holes sometimes ... If anything, this has been another way for me to be more acquainted with Java, which I am happy for :).
- throwaway9032 4y ago
  Java is the opposite of boring. It lacks basic fundamentals such as algebraic data types and pattern matching. You will be kicking and screaming the whole ride. A boring language would be a language where you aren't triggered/bothered by its basic ergonomics and hygiene. In Java, you must translate discrete variants into dogmatic OO paradigm instead of using language primitives. Thanks to Java's poor design, it's fundamentally a hazard and a land mine thanks to null not being first class in type system. The use of null as a value inhabiting any type should result in a slap in the face upon opening a pull request (until Java adopts type-safe optionals like Kotlin) P.S. Switch expressions and sealed interfaces aren't there yet, Kotlin and Scala are still the only options if you are imprisoned to JVM.
  - dunefox 4y ago
    I have the same opinion about Java and I hesitated as well before starting to read the book, so I'll use either Kotlin or common lisp.
e12e 4y ago
> was not sure if the choice of language (Java) Two books I enjoyed despite, rather than because of the language: "Program Generators with XML and Java" (aka "program generators for fun and profit") https://www.amazon.com/Program-Generators-Java-Craig-Cleaveland/dp/0130258784 https://www.amazon.com/Program-Generators-Java-Craig-Cleavel... And: "Designing Active Server Pages" https://www.amazon.com/Designing-Active-Server-Pages-Mitchell/dp/0596000448/ref=mp_s_a_1_1?crid=18Y4ECSH970B&keywords=Designing+Active+Server+Pages&qid=1655931137&sprefix=designing+active+server+pages+%2Caps%2C325&sr=8-1 https://www.amazon.com/Designing-Active-Server-Pages-Mitchel... The latter mostly for techniques to keep programs structured even when writing mostly in template soup (like php, asp, coldfusion etc).
runevault 4y ago
See to me Java was an advantage because it ensured I would do part 1 in Not Java (in my case c#). Mind you c# is great because it is similar enough you can follow along while also being different enough that you still are forced to engage and think. At some point I want to redo part 1 in F# to REALLY push myself (and also force me to better engage with F#).
- efvincent 4y ago
  I did the first part in F#, and rather than translating Java to F#, I looked at what the author was trying to accomplish in each step, and did something functionally equivalent in idiomatic F#. That was fun & challenging. haven't tackled the second part, I'm currently down the rabbit hole with Samuel Mimram's Program = Proof, which I'm just loving and the first book I've seen that focuses on the Curry Howard Isomorphism, covering essential logic, lambda calculus, type theory, and Agda... so good.
heavyset_go 4y ago
Any trouble with the Rust implementation? I wanted to give the book a go using Rust, but have been sitting on it because I don't want to get halfway through it only to find that Rust's intentional design and limitations might make it difficult to build an interpreter via the assumptions in the book.
- jeffdn 4y ago
  You can do it pretty much verbatim, with dynamic dispatch using enums and lots of pattern matching. It gets a bit trickier when you are nesting environments for closures and the like, but certainly nothing insurmountable without a few things from the standard library.
- dento 4y ago
  I've been loosely following the book with Rust, and no issues so far. Both the compiler and interpreter are implementable without much issues. You'll have to adapt a bit, but in general you can use the same methods.
- bow_ 4y ago
  Not really (for the first part at least, am not yet finished with the second part). I did deviate a little bit with my Rust implementation. This was my goal anyway: implement Lox differently. Off the top of my head: * I used ADTs to encapsulate error types and states as much as possible, this lead to heavy use of enums and pattern matching. * I implemented the `Environment` as an immutable, explicitly passed value. This was a little challenging at first, but overall quite satisfying to do.
Waterluvian 4y ago
I wrote the first one in Python without issue. I guess any sufficiently expressive language should be fairly easy to “adjust the recipe to” while still following the book.
- heavyset_go 4y ago
  How was the performance?
  - Waterluvian 4y ago
    Pythonic. (I didn’t measure nor care about performance. That wasn’t the goal of the exercise)
    - heavyset_go 4y ago
      Good one. If it works that's all that matters.
Sakos 4y ago
I wish people would be less opinionated about things like this. I've completed exercises for books or courses in C, C++, Lisp, Scheme, Go, Python, Javascript, Ruby, Rust, Java, Scala, Clojure, Prolog, Assembly, etc. It's not a big deal. Nobody is telling anybody they have to then program in that language for the rest of their lives. Be open to new experiences. Java really isn't difficult or alien or bad enough to complain that it's the wrong language and expecting book x to be in your preferred language z when there are dozens one could choose is so...closed-minded.

by bow_ 4y ago

munificent 4y ago

You're welcome! :D

danhau 4y ago

Does the book go into more „modern“ parser architectures ala Roslyn Red Green Trees?

llimllib 4y ago
You can read it on the web here: https://craftinginterpreters.com/contents.html https://craftinginterpreters.com/contents.html (I don't know how to answer your question accurately)
throwaway17_17 4y ago
The parser’s data structure is a more traditional Abstract Syntax Node design. Roslyn’s tree design is, IMO, a good internal structure for use in a production-grade compiler meant to be coupled with a developer environment (IDE and other tools) because the complexity pays off in terms of developer experience. However, Bob set out (as far as I can tell from the book and his talks/comments on the subject) to provide a fairly beginner friendly, introduction to the topic of language implementation. Within his chosen scope the parser implementation in Crafting Interpreters is more than sufficient and clearly presents the concepts intended.
DylanSp 4y ago
IIRC, Roslyn's red-green tree approach is at least partly due to needing to support interactive editing without re-parsing everything. If that's what you're referring to, no, the book doesn't cover that; both interpreters run either in batch mode on a single file or in a simple REPL.
Banana699 4y ago
Crafting is less about modern or production-grade anything and more about understanding fundamentals. It would be equally at home in a 1980s compilers and language design course or in a 2000s version of that course. It has a single motivating principle, which is that a learner who understands the bare basics of algorithms and data structures knows, in the truest sense of the word, what a compiler and an interpreter does. It achieves that principle beautifully.
runevault 4y ago
If you're interested in Roslyn inspired compiler writing, Immo Landwerth who works on as a Program Manager on .NET made a Youtube series about writing a compiler, and my understanding from the part I watched is his work is heavily inspired by Roslyn. https://www.youtube.com/playlist?list=PLRAdsfhKI4OWNOSfS7EUu5GRAVmze1t2y https://www.youtube.com/playlist?list=PLRAdsfhKI4OWNOSfS7EUu...

62951413 4y ago

Using Java was a poor choice (especially without the latest improvements such as records and switch expressions): * new books should use more modern popular languages to age well and to attract younger audience * on the JVM there are languages better suited for the topic (e.g. Scala by a large margin) * There's already the "Language Implementation Patterns" book (https://www.amazon.com/Language-Implementation-Patterns-Domain-Specific-Programming/dp/193435645X https://www.amazon.com/Language-Implementation-Patterns-Doma...) which not only is great for teaching because of its pattern-based approach but also gives you real life skills (e.g. ANTLR is used in most big data query engines)

tomcam 4y ago
You sound pretty smart! How about writing that book for the rest of us?
alcover 4y ago
> Language Implementation Patterns I hear the code examples are in Java. I think that's unfortunate. (And a bit ironic about your post).
- vips7L 4y ago
  If you actually take the time to read the book Bob explains the choice. And fwiw modern Java is decently expressive without adding the unneeded complexity of Scala or something similar. edit: replied to the wrong post. /shrug
Zababa 4y ago
> new books should use more modern popular languages to age well and to attract younger audience That doesn't make sense. Java is one of the most popular programming language, more popular than a lot of other "modern popular languages". The only languages more popular are either as old as Java (JavaScript, Python) or older (C, C++). C# might be one option, but it's close to Java, and I don't know if the support for Linux/MacOS was here at the time this book was started. Same thing for JavaScript and Python's popularity, which are relatively recent trends. On the other hand, Java has stayed and endured. It's still here and will still probably be here in 20 years. > on the JVM there are languages better suited for the topic (e.g. Scala by a large margin) Scala is less popular than Java, and harder to master. Once you consider Scala, you get into endless arguments about whether to use Scala, SML, OCaml, Haskell, etc. > There's already the "Language Implementation Patterns" book There is also "Writing an interpreter in Go" and "Writing a compiler in Go" that seem to cover the same ground. But I'm certain than more people know about interpreters and compilers thanks to these three books than thanks to any one of them. > but also gives you real life skills (e.g. ANTLR is used in most big data query engines) The majority of programming languages don't use a generated parser but a handmade recursive descent parser, because it's the best at error reporting. There's a good post about different parsing approaches by Laurence Tratt: https://tratt.net/laurie/essays/entries/which_parsing_approach.html https://tratt.net/laurie/essays/entries/which_parsing_approa.... Generated parsers are great for DSLs but that won't teach you how the programming languages that you use work.

RyanHamilton 4y ago

I fully agree. Superb, "meticulously and beautifully done". I read it online and followed along writing code then bought the book just to support the author. Thanks Bob.

rightbyte 4y ago

> was not sure if the choice of language (Java) for the first half of the book would be a hindrance I think it is refreshing he uses a "boring" language.

bigDinosaur 4y ago
The way you phrase that makes it sound like you're implying there isn't an overwhelming dominance in terms of 'boring languages' and tutorials/content/books/training material. HN presumably doesn't upvote Java book #10^6 unless it is quite unique otherwise.
bow_ 4y ago
I didn't worry because of Java's perceived lack of 'excitement'. Just that I am more familiar with other languages and I worried I'd get lost trying to understand Java and not digest the material properly. I tend to fall down rabbit holes sometimes ... If anything, this has been another way for me to be more acquainted with Java, which I am happy for :).
throwaway9032 4y ago
Java is the opposite of boring. It lacks basic fundamentals such as algebraic data types and pattern matching. You will be kicking and screaming the whole ride. A boring language would be a language where you aren't triggered/bothered by its basic ergonomics and hygiene. In Java, you must translate discrete variants into dogmatic OO paradigm instead of using language primitives. Thanks to Java's poor design, it's fundamentally a hazard and a land mine thanks to null not being first class in type system. The use of null as a value inhabiting any type should result in a slap in the face upon opening a pull request (until Java adopts type-safe optionals like Kotlin) P.S. Switch expressions and sealed interfaces aren't there yet, Kotlin and Scala are still the only options if you are imprisoned to JVM.
- dunefox 4y ago
  I have the same opinion about Java and I hesitated as well before starting to read the book, so I'll use either Kotlin or common lisp.

e12e 4y ago

> was not sure if the choice of language (Java) Two books I enjoyed despite, rather than because of the language: "Program Generators with XML and Java" (aka "program generators for fun and profit") https://www.amazon.com/Program-Generators-Java-Craig-Cleaveland/dp/0130258784 https://www.amazon.com/Program-Generators-Java-Craig-Cleavel... And: "Designing Active Server Pages" https://www.amazon.com/Designing-Active-Server-Pages-Mitchell/dp/0596000448/ref=mp_s_a_1_1?crid=18Y4ECSH970B&keywords=Designing+Active+Server+Pages&qid=1655931137&sprefix=designing+active+server+pages+%2Caps%2C325&sr=8-1 https://www.amazon.com/Designing-Active-Server-Pages-Mitchel... The latter mostly for techniques to keep programs structured even when writing mostly in template soup (like php, asp, coldfusion etc).

runevault 4y ago

See to me Java was an advantage because it ensured I would do part 1 in Not Java (in my case c#). Mind you c# is great because it is similar enough you can follow along while also being different enough that you still are forced to engage and think. At some point I want to redo part 1 in F# to REALLY push myself (and also force me to better engage with F#).

efvincent 4y ago
I did the first part in F#, and rather than translating Java to F#, I looked at what the author was trying to accomplish in each step, and did something functionally equivalent in idiomatic F#. That was fun & challenging. haven't tackled the second part, I'm currently down the rabbit hole with Samuel Mimram's Program = Proof, which I'm just loving and the first book I've seen that focuses on the Curry Howard Isomorphism, covering essential logic, lambda calculus, type theory, and Agda... so good.

heavyset_go 4y ago

Any trouble with the Rust implementation? I wanted to give the book a go using Rust, but have been sitting on it because I don't want to get halfway through it only to find that Rust's intentional design and limitations might make it difficult to build an interpreter via the assumptions in the book.

jeffdn 4y ago
You can do it pretty much verbatim, with dynamic dispatch using enums and lots of pattern matching. It gets a bit trickier when you are nesting environments for closures and the like, but certainly nothing insurmountable without a few things from the standard library.
dento 4y ago
I've been loosely following the book with Rust, and no issues so far. Both the compiler and interpreter are implementable without much issues. You'll have to adapt a bit, but in general you can use the same methods.
bow_ 4y ago
Not really (for the first part at least, am not yet finished with the second part). I did deviate a little bit with my Rust implementation. This was my goal anyway: implement Lox differently. Off the top of my head: * I used ADTs to encapsulate error types and states as much as possible, this lead to heavy use of enums and pattern matching. * I implemented the `Environment` as an immutable, explicitly passed value. This was a little challenging at first, but overall quite satisfying to do.

Waterluvian 4y ago

I wrote the first one in Python without issue. I guess any sufficiently expressive language should be fairly easy to “adjust the recipe to” while still following the book.

heavyset_go 4y ago
How was the performance?
- Waterluvian 4y ago
  Pythonic. (I didn’t measure nor care about performance. That wasn’t the goal of the exercise)
  - heavyset_go 4y ago
    Good one. If it works that's all that matters.

Sakos 4y ago

I wish people would be less opinionated about things like this. I've completed exercises for books or courses in C, C++, Lisp, Scheme, Go, Python, Javascript, Ruby, Rust, Java, Scala, Clojure, Prolog, Assembly, etc. It's not a big deal. Nobody is telling anybody they have to then program in that language for the rest of their lives. Be open to new experiences. Java really isn't difficult or alien or bad enough to complain that it's the wrong language and expecting book x to be in your preferred language z when there are dozens one could choose is so...closed-minded.