DalekBaldwin
Joined 13 years ago
Joined 13 years ago
First-class procedures/functions are a form of composition. Requiring a function type behaves like requiring an interface/class type with only one method. (In languages like F#, `Func<_,_>` is literally defined internally as an abstract class with one method, `Invoke`, although there are other mechanisms to auto-inline lambdas when enough static information is available to do so.) In either case, you can place it into a field of an object or data structure, or pass it directly as an argument to a function/method.
There were rumblings that my high school, which had plenty of AP classes already, was about to introduce a combination AP/IB curriculum, which absolutely terrified us. I and my AP-taking classmates breathed a huge sigh of relief when it was announced that it would be delayed, and the students in the year below us would be the guinea pigs. They would have to run twice as fast just to stay in place.
(The film "Force of Evil" is about a plot to nevertheless rig the outcome.)
It's uncharitable to take Casey as making absolute blanket statements like that, but still, it would not be unreasonable for him to single out Uncle Bob in particular.
The Amazon rankings for Bob Martin's "Clean Code":
Best Sellers Rank: #5,338 in Books (See Top 100 in Books)
#1 in Software Design & Engineering
#2 in Software Testing
#4 in Software Development (Books)
For one thing, sketching out variations on a design typically reveals there's a wide space of possible parameters in the spec. In many cases it's obvious that only a small subset will actually be technically feasible (either for machining or for reasonable functionality of the finished artifact or both), but not obvious exactly what that subset will be.
I'm not even talking about what could be revealed by finite element analysis or other formal methods (though I'm not averse to learning those too). I mean the feel, the taste, and the intuition I can't get from just drawing and doing the math. Like Jackie Stewart said, "You don't have to be an engineer to be be a racing driver, but you do have to have Mechanical Sympathy." I have mechanical sympathy for computing systems, for rapidly narrowing down appropriate design spaces in software projects, but I don't yet have mechanical sympathy for mechanical systems.
It's tough to plan a path toward growth in these skills without sustaining inordinate expenses at each step. I can't afford to become afflicted with Gear Acquisition Syndrome. I've come close to dropping huge sums of cash on tools before discovering, at the last minute, critical reasons that they could not do what I need for the designs I have in mind. Maybe I'll visit a makerspace? Ah, but every one in my area appears to have gone defunct since Covid year zero.
So the journey up to this point has been:
- A lot of reading: not just faffing around with hobbyist blogspam -- full-on MechE textbooks, learning what really goes into engineering schematic diagrams, all that good stuff
- Getting back up to speed with the pencil-on-paper geometry and math skills I've lost after years of doing all my intellectual work in digital form (at least I can still draw a freehand circle)
- Proto-proto-prototyping: just making some physical objects roughly of the same geometry as what I've designed -- whittling them out of wood, sculpting them out of polymer clay
- Hacking together janky tools: trying to make a crappy mini lathe out of Meccano-clone parts, trying to make a crappy mini lathe out of an electric drill, just to get a basic feel for what's involved
- Apologizing to my wife for all this weird scary stuff in the corner of the apartment
I was a CS major. The only hands-on physical engineering I did in college was cooking a single-transistor chip in a freshman applied physics lab. Basically I feel like someone who has studied everything about the physics of bicycles but has never ridden one. I'm really struggling on how to proceed.