It's always interesting to see how different people approach the problems in their own language or relative isolation. I agree with others here, the real value of the original work lies in avoiding copy and paste.
Lox must have the highest ratio of (implementations : production usage) of any language on the planet. And I mean that as the highest praise -- it's proven a fantastic teaching language, and your book is infectious at encouraging others to jump in and follow along in various different languages.
I've also found the exercise of implementing Lox in another language as highly instructive in learning how to write idiomatic code in that language. I continue to learn more about the best way to express patterns as I work on my own implementation. I'd recommend the journey to any professional developer for this side-benefit alone.
> Lox must have the highest ratio of (implementations :
> production usage) of any language on the planet.
It's probably up there, for sure! But I'd guess that there are a million toy Lisp implementations, and more people are interested in writing a FORTH interpreter than actually using one in production. So I'd guess if we tried to get statistics it wouldn't be at the top.
Though there's probably a similar claim to be made for the Monkey-language from Torsten Bell, via his books on compilers and interpreters.
On a more serious note, have you thought about trying to aim lightning at the same spot again and write another book about implementing something most programmers take for granted?
I've definitely thought about writing a third book. I don't know if it would be about "something most programmers take for granted". I'm more interested in writing about whatever happens to excite me the most at that time.
I may be projecting, but I feel like the kind of person to get excited about crafting interpreters wod also get excited about crafting databases or OSes.
That's so many languages and implementations that this could be used as a new Programming Language Popularity Ranking, with a bias towards languages people want to use or learn :D.
Glad to see this as well. I'm about to hire some C++ developers for embedded work and have never been a fan of this type of interviewing, if only because I know I personally don't excel at this style and consider myself extremely competent. I'm hoping to find ways of assessing incoming candidates along the lines you've briefly touched on in this thread!
I had a good experience with AllPCB recently. They even reached out for clarification on an extraneous drl file I had included in the gerbers zip accidentally.
As long as the apartment wood shop isn't heavily used for sanding, it will be fine. I have a full garage woodshop and still do sanding out in the front yard, even in the winter. I built a bar top and did the sanding in the garage; was brushing sawdust off of everything in there for weeks.
I don’t really like giving out healthcare advice on the Internet. But also... I feel bad for folks being harmed. I’m an amateur woodworker and a non-amateur medical professional, so I’ve looked into this topic for my own self. Putting on the n95 while you’re sanding isn’t sufficient in that sort of environment.
But I’d really rather you didn’t take my word for it: perhaps you’d consider reaching out to a pulmonologist with experience in carpenters’ occupational lung diseases, and get their take on it?
Spoken, honestly, as one stranger wishing another no harm.
Is there a particulate size where a respirator becomes necessary in woodworking vs a dust mask? Like, above 120 grit you should really have a respirator on? I'm probably not as concerned about wood dust as I should be, so this is interesting to me.
Do you maintain a 1:1 relationship between reduced state and components? I'm curious because your word choice seems to imply you do and I'm wondering how popular that is if so.
I'll be honest - I'm having trouble parsing what having a '1:1 relationship between reduced state and components' actually means.
The most common "state" in our application is the result of a GET request (for example, you need some data from the server), and an accompanying loading/loaded/error state.
Most (presentational) components will load its needed data from a container component (through connect(), or other higher order components we developed). So for example, a given `user` object, could have its data in a chat component, or an analytics view, or a settings profile. The reducers aren't generally concerned with how the data is used, just that its available to anyone who asks.
As far as localized state goes (like a form), we took a page from reduxForm (and we use reduxForm) - if there were times we needed to use setState a lot (for example, we had a query builder and chart components), we built a higher order component (like connect), where you would pass the props you need, and that component would figure out how to query it and make it available in the redux state. Again this meant you could create a "query object" from one component, that was theoretically available to any other component (as part of the Redux tree), if they asked.
All in all, I never considered any sort of 1:1 relationship between state and components. I had state, and the components decided what state they needed and rendered themselves appropriately. This was a fairly complex SPA that had real time chat, analytics and CRM-like features, there were 100s of components.
Our codebase was far more robust from the Angular version we had rewritten it from a year ago (a component crashing didn't bring down the whole app), and the concerns for every component tended to be self-discoverable (we were able to hire interns to start hacking on it within 2-3 days, after they wrapped their head around redux). I'll admit it took me sometime to understand the benefits of Redux, and there was a lot of ugly boilerplate until we started using higher order components, however "brittle" and "messy" is the last words I'd use to describe the codebase.
From a flux/reflux perspective I'd 1-1 relationship to mean that every component had a matching store, but since Redux has a single store not sure what pattern would match.
If I remember correctly, TCL uses a very simple overlay system based on squashfs. Most (all?) of the tooling and package management stuff is also written in bash.
Or scopolamine. Who needs a wrench when you've got angel's trumpet growing on the fence outside? Especially when it comes to the right 25th word (or the right VeraCrypt volume password, etc).
There's at least one other Rust implementation of lox that I know of (https://github.com/tdp2110/crafting-interpreters-rs) (no unsafe)
It's always interesting to see how different people approach the problems in their own language or relative isolation. I agree with others here, the real value of the original work lies in avoiding copy and paste.