Live data from Hacker News

Crafting Interpreters

craftinginterpreters.com

181–190 of 193 posts

Re: Crafting Interpreters

#181

Earlier quoted context omitted.

Hi, loved your previous work on languages (Magpie, etc.). Any update on the statically typed language you were working on? Is it still in progress? The syntax for dealing with Sum types was pretty ingenious. Thanks for both the books, cheers.

Still noodling on it! I spent a lot of time trying to figure out how I wanted to handle generics and heterogeneous data in a way that felt simple enough for me to design and implement it. I think I have something more or less figured out. It's about a 50/50 blend of Go interfaces and Rust traits. I have a prototype implementation in progress but haven't had much time to work on it. I broke my ankle a couple of months…

Oh, get well soon! And best of luck on the project.

Re: Crafting Interpreters

#182

Earlier quoted context omitted.

I see you claim that, but unless I misunderstanding that completely contradicts our claim here: > 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. What I'm saying is exactly that. Handwave past all of the boilerplate like the static declaration and only focus on the most important…

> Could you explain how your statement of initially teching the boilerplate is the same as my statement of ignoring it? I specifically said that including the boilerplate is a common pitfall, and requires teaching around a bunch of impertinent concepts. I also chose the example for a reason very close to your example with Racket: later versions of Java have similarly aimed to reduce the necessary boilerplate. And if…

> I specifically said that including the boilerplate is a common pitfall, and requires teaching around a bunch of impertinent concepts.

And again, I'm saying I disagree with this. You are saying don't include the boilerplate at all when teaching. I a saying, do include the boilerplate and don't teach it until students are ready to understand it.

As a separate topic, if the language doesn't need boilerplate to make the program work (like Racket) that's spectacular. But if it does, then I'm explicitly saying "show the boilerplate and explain 'you don't need to focus on it now. You will learn it later'".

It is best give people a fully working program at all times, even if they don't understand all of it. So they can play around with it, rather than just read along while the author writes about what would have happened if it were fully functioning code they could play with.

And to make it very clear, the example I linked to explicitly includes all of the boilerplate, and I explained exactly the best method to teach a student with that specific concrete source code.

> https://www.geeksforgeeks.org/java-hello-world-program/

Now all of that said - this isn't really important enough to continue arguing on the internet over. I think we both had good intentions but just weren't communicating clearly. I hope you have a great day.

Re: Crafting Interpreters

#183

Earlier quoted context omitted.

> Could you explain how your statement of initially teching the boilerplate is the same as my statement of ignoring it? I specifically said that including the boilerplate is a common pitfall, and requires teaching around a bunch of impertinent concepts. I also chose the example for a reason very close to your example with Racket: later versions of Java have similarly aimed to reduce the necessary boilerplate. And if…

> I specifically said that including the boilerplate is a common pitfall, and requires teaching around a bunch of impertinent concepts. And again, I'm saying I disagree with this. You are saying don't include the boilerplate at all when teaching. I a saying, do include the boilerplate and don't teach it until students are ready to understand it. As a separate topic, if the language doesn't need boilerplate to make th…

I understand you better now. I was confused by your Racket example, as it represents exactly the same direction the Java example has gone.

As you say, definitely not worth arguing further. But I appreciate your clarification!

Re: Crafting Interpreters

#185
post #9

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.

How might Dart be different if you were an original designer?

Re: Crafting Interpreters

#186

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.

Your book, as well as 'Writing An Interpreter In Go', are two books I definitely want to read when I get more free time! I'd like to have a go at making a basic typesetting language, I have a bunch of ideas for it.

Re: Crafting Interpreters

#188

Earlier quoted context omitted.

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.

How might Dart be different if you were an original designer?

It's hard to separate out what I know now that neither I nor the initial designers knew back then from what I thought we should have done even then.

For example, optional types ended up not working out, but I don't think I knew that then either.

But even before we released, I did tell the language team that I thought it would be good to do:

* Non-nullable types. We got there eventually with a ton of engineering effort and migration cost, but this could have been a really strong selling point at launch.

* Types on the right. Think `var x: int` instead of `int x`. It's a little more verbose in some cases, but it makes the language easier to parse and makes it easier to have complex syntax for type annotations like function types, union types, etc.

* Extension members. We added them years later, which is good, but was too late to affect the design of the core libraries. I suggested that it we had them in 1.0, then the core libraries and collection types could be designed around them.

* `val` instead of `final` for single-assignment variables. It's a small thing, but it means that the syntax for single-assignment variables isn't longer then mutable ones, which is good because it doesn't punish users for doing the "right" thing.

* No semicolons. Again, another small thing, but it does help the language feel cleaner and more modern. It's really hard to do this later when the syntax wasn't designed for it.

* Coroutines instead of futures and async/await. Coroutines are definitely hard to compile to JS, so there is a good argument that I'm just wrong. But I really hate what async does to API design (https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...).

Re: Crafting Interpreters

#189
post #124

Earlier quoted context omitted.

Thank you for writing the book! I'm currently almost done with the first part (doing it in Haskell because why not) and every chapter I encounter situations where my "clever hack" turns out not to be so clever in the light of later requirements. It's been great fun so far. Have you considered writing up a follow-up book doing (say) a compiler or a JIT or something for Lox? PS: the lexical analygator is the best and h…

Yes, people have definitely asked for a follow-up on compilers and/or static types. There's a little context here: https://news.ycombinator.com/item?id=40956138 I'm not sure if I'm the best person to write a compiler book, or, at least, not yet. I've written a lot of language front ends and interpreters, but I don't have much experience targeting native code. It's something I've wanted to do for a long time, but have…

You could do a compromise - write a book on crafting interpreters that use Truffle to be partially evaluated into compilers.

Re: Crafting Interpreters

#190

Earlier quoted context omitted.

How might Dart be different if you were an original designer?

It's hard to separate out what I know now that neither I nor the initial designers knew back then from what I thought we should have done even then. For example, optional types ended up not working out, but I don't think I knew that then either. But even before we released, I did tell the language team that I thought it would be good to do: * Non-nullable types. We got there eventually with a ton of engineering effor…

That’s very close to my list. It’s only a few characters but “final” takes up too much space. And I agree types on the right are easier to read.

Other than that I’m mainly looking for the reasons code generation is required today to go away.

Post reply on HN