[bow_]

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

[munificent]

You're welcome! :D

[Sakos]

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.

[Waterluvian]

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]

How was the performance?

[Waterluvian]

Pythonic.

(I didn’t measure nor care about performance. That wasn’t the goal of the exercise)

[heavyset_go]

Good one. If it works that's all that matters.

[e12e]

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

And:

"Designing Active Server Pages" 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).

[RyanHamilton]

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.

[danhau]

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

[Banana699]

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.

[throwaway17_17]

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]

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.

[llimllib]

You can read it on the web here: https://craftinginterpreters.com/contents.html

(I don't know how to answer your question accurately)

[runevault]

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

[runevault]

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]

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]

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]

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]

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_]

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.

[rightbyte]

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

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_]

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]

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.

[stolsvik]

https://openjdk.org/jeps/360

https://openjdk.org/jeps/394

https://openjdk.org/jeps/406

[dunefox]

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.

[62951413]

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

[Zababa]

> 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_approa.... Generated parsers are great for DSLs but that won't teach you how the programming languages that you use work.

[heavyset_go]

Didn't think I'd see 'attract younger audience' and 'Scala' in the same sentence.

A lot of young people know Java because it's what they learned in school and because a lot of employers use it so it's the first thing they learn on the job.

In my opinion, the language is designed in a way that makes it easy to pick up for beginners. The lack of obfuscated operators and foot guns is a plus, and the language forces you to avoid doing 'clever' code golf things, too.

[tomcam]

You sound pretty smart! How about writing that book for the rest of us?

[ch4s3]

ANTLR may be used in big data query engines but I can’t think of a single language I’ve ever used that had a parser written with it. I know you can grab off the shelf parsers with antlr for a bunch of languages, but who cares?

And frankly, Scala’s build tool is way too slow and would be a slog to use for this book.

[vips7L]

SBT and Scala are the biggest productivity killers for me at work purely based on the slow build time and lack of proper documentation. That and every release the ecosystem makes some breaking change.

[ch4s3]

Yeah, SBT is pretty awful. I feel like Scala suffers from design by committee, and by being the choice language of certain types of Enterprise Software Engineers TM.

[vips7L]

It is not a language for getting things done imo. Even IntelliJ can’t figure out what’s going on sometimes.

[alcover]

  > Language Implementation Patterns

I hear the code examples are in Java. I think that's unfortunate. (And a bit ironic about your post).

[vips7L]

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