141–150 of 193 posts
I really wish this book used something other than Java. Nothing against Java - just that I don't know it and don't feel excited about learning it.
Does anyone know of a good resoucce for creating a statically typed language with stuff like parametric polymorphism and basic type inference?
People have asked me to write something like this many times and one of the main reasons I haven't is because it's so open-ended. With Crafting Interpreters, I felt like there was a reasonably small self-contained language I could come up with that covered almost all of the concepts I wanted to teach: variable scope, functions, closures, classes and dynamic dispatch, control flow, etc. With type systems, there are a…
I will not fault you if you don't get to any such project (I remember discovering Crafting Interpreters around the time you were like... halfway through part one? and seeing how long it took you to get through the rest of the book. The care you take to both give useful technical information and make your writing clear takes a great deal of work), but I would certainly read it as I've read much of CI if it ever exists (I need to finish going through part 2, I'm up to Closures).
Author here. Seeing all of the positive comments about my book is really warming my heart. I appreciate everyone and I'm glad so many people have enjoyed the book. I put a ton of time and love into it and it's gratifying to see it had the effect I'd hoped for.
Thanks for both the books, cheers.
The author is one of the lead developers for Dart, which has evolved over time into a pretty nice language.
I should clarify that I've been an engineer on the Dart team for a long time, but I wasn't one of the original designers of the language. (If I had been, the language would be pretty different.) I am on the language team now, but I'm just one of the team members and not a lead. The Dart team is really fantastic. Every day I'm grateful I get to work with such a good group of people.
I'm looking forward to macros and more fully featured record types.
The author is one of the lead developers for Dart, which has evolved over time into a pretty nice language.
I think Dart is underappreciated. Almost the entire compiler is written in Dart. It has a VM, AOT compiler, FFI/Native, and first class Javascript interop with ability to compile to javascript. It has first class WASM support. Null sound safety. They have experimental support for macros. Pretty impressive.
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…
I don't think I would have ever attempted to write an interpreter without first reading something like CI... I never would have gotten to your step three.
I really wish this book used something other than Java. Nothing against Java - just that I don't know it and don't feel excited about learning it.
Then just write it in whatever language you want. When I went through the first half of the book back in 2017, I wrote it in Scala. (I did know Java, too, though, so certainly I had an easier time understanding the code examples in the book.)
Earlier quoted context omitted.
When Java gets pattern matching, it will become a more reasonable choice to write an interpreter in.
It’s had pattern matching since 16, it’s been expanded since with some syntactic sugar and more recently the introduction of sum types and exhaustiveness to go along with pattern matching.
Earlier quoted context omitted.
I commiserate, it can be unforgiving, and the use of C is admittedly out of vogue.
Oh, I love C. [1] But yes, unforgiving. And a lot of magic, with special variables, macros, and functions that you must know. And unclear scoping. [1]: https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-i...
I remember reading that post of yours a year or so ago! It was so bizarre to me, but also really fun. I feel like you are among what is probably a very small group of people who could write something security-sensitive in C, and I would feel comfortable using it. (I am still less than thrilled that I have to rely on OpenSSL, regardless of the process improvements its developer team has made in more recent years.)
I still (unfortunately, IMO) write a lot of C. Back in 2004 I thought it was great fun. But now that I've worked in safer, batteries-included languages, I find C to be a huge drag. I'm so much more productive in Rust or even Java. I could never ever ever ever approach the level of rigor you bring to your C code; I just don't find doing all that stuff to be fun or interesting... to the contrary, it feels like a huge drag: if I were "required" to do all that, I just wouldn't write any code at all in C in the first place, knowing that having to do all the testing and fuzzing and static analysis stuff would burn me out.
Anyhow, I hope I don't sound like I'm being critical... quite the opposite. I just think we live in a magnificent world where people's brains can work so so so differently when it comes to the same topic.
I really wish this book used something other than Java. Nothing against Java - just that I don't know it and don't feel excited about learning it.
What other languages do you know? If you know something with similar enough syntax (C++, C#, Javascript, etc.), even if the semantics aren't the same, you should be ok getting the basic idea of the Java code in the book, especially considering how he explains things as you go. Then just write it in whatever language you want. When I went through the first half of the book back in 2017, I wrote it in Scala. (I did kno…
I know JavaScript and a bit of C and I'm not having much trouble understanding the Java code.