Part of the point of SICP is to be generic about its programming principles. The core principles and concepts are independent of any particular programming language (so long as it has first class functions, and probably a few other common features). Since Scheme has virtually no syntax it was an ideal language for Ableson & Sussman’s course. It’s notable that SICP spends hardly any time teaching the language.
I’ve never understood, therefore, the motivation behind trying to “translate” SICP into a language like JS (or Python, etc.) It over emphasizes the importance of the preferred language in a way that very obviously undermines the book.
The point being: if you’re gonna do SICP do it in Scheme. You’ll get more out of it.
Anything you might want to do with a radio or IR device but don’t have specialized hardware for. It’s kind of a swiss knife/leatherman tool for short range communications standards.
I think of it as the browser dev tools of radio. Most people will have no use for it but it brings visibility and interactability in to an otherwise invisible world.
Logical NAND of a laptop featureset. Has things like IR, a subghz HDR, NFC+RFID, USB device support, iButton, and the like.
Some people get a lot of use out of it, but if you just saw that list of hardware and couldn't think of one area you'd apply it in, it's probably not going to be a useful device for you.
Totally true. It’s hard for me to stop a project, I keep piling feature after feature for no reason. I literally stop only when Claude Max Pro hits the hourly limit.
For me it was similar, but I think it was more about a lack of a natural friction. Normally when coding there was the "hit" of seeing something work, but the actually planning/coding/debugging would eventually wear me out, so I'd stop for the day. Now it can all just be endless "hit" of success and nothing that makes me feel tired or annoyed.
The reason I believe this is because I recently went through a really annoying battle with Claude trying to get it to stop being so strict with its sandbox. I wanted it to simply load some sanitized text from a source online, and it just would not do it. The sessions when I was sorting that out were so much easier to stop and moderate than the ones where everything just kept flowing effortlessly.
> When you watch someone who knows what they are doing, you'll see them looping over the following steps:
> Build a mental model of the requirements
> Write code that (hopefully?!) does that
> Build a mental model of what the code actually does
> Identify the differences, and update the code (or the requirements).
This is pretty right on but I think it leaves out an aspect of writing code that I think is often pretty under appreciated. Code does two things at once: it provides a set of instructions to a machine and it communicates the authors' understanding of the program behavior those instructions are intended to express. I think this is a large part of what makes programming so fascinating and frustrating. It's what's behind the cliche that "naming things" is one of the hardest parts of programming. In growing software systems it's often not enough that a feature's implementation works. Ideally, that implementation should impose a minimum barrier to understanding for contributors to do something with it afterward. I'm not convinced this is an aspect of software development that LLMs will be able to meaningfully achieve.
I actually laughed out loud when I read that conclusion. Not only does it sound infeasible and unsustainable, it also sounds not a little arrogant and likely annoying for everyone else working with them.
Can you imagine saying to your product owner or whatever "oh yeah we're not gonna do anything new. We'll spend the next year or so rebuilding this service because the code looks ugly."
I think it’s easy to overestimate how thinly skinned most people really are because an exceptional complaint (that’s not easily dismissible) commands attention. (This isn’t necessarily a bad thing, insofar as it’s indicative of sympathy and sensitivity.)
I’ve never understood, therefore, the motivation behind trying to “translate” SICP into a language like JS (or Python, etc.) It over emphasizes the importance of the preferred language in a way that very obviously undermines the book.
The point being: if you’re gonna do SICP do it in Scheme. You’ll get more out of it.