71–80 of 114 posts
I'll call out 7. Don't have multiple people editing the same piece of code. You never understand other people's code as well as your own. No matter how thoroughly you've read it, you've only read it, not written it. So if a piece of code is written by multiple authors, none of them understand it as well as a single author would. On some level it's true but it is also true that most of the world's code is in some sort…
But there’s no time in the schedule for that? Either that’s not true (the long way round is usually the shortest way home); or it’s time to find another project. And if you’re the sort of person who has the skills Graham describes, that shouldn’t be hard.
Earlier quoted context omitted.
Those are called functions.
Sometimes. Sometimes it is one or more programs writing to a queue or topic, and other programs reading from that topic. Or programs writing to and others reading from a Unix pipe. Or programs talking to each other using HTTP. Or Erlang processes communicating concurrently on one machine or across a network. Or different programs sharing one database. Or many objects communicating by passing messages in a small talk…
Earlier quoted context omitted.
I think that many, perhaps even most, engineers incorrectly believe that the main purpose of abstraction in code is simply DRY, as if the goal is to save keystrokes or something. In my view, the purpose of abstraction is to compress the concepts of your application into digestible and manueverable chunks, and DRY is just a heuristic for beginners to follow to help point to where appropriate abstraction boundaries may…
I think DRY should be supplemented by "Don't make me read it multiple times". Repeat yourself, by all means, if that makes it so that I don't get all twisted up jumping between so many files that I can't keep the main thread straight while I read your code.
Unless, you know, it's automatically tested to hell and back.
Not only is that often false, but there are times when you can understand another author's code better than that author does. Like to see through it and why it cannot possibly work, while they are laboring toward that.
Earlier quoted context omitted.
Robert Morris, Peter Norvig and Stephen Wolfram didn't write code? (I don't recognize some of the others.)
Is that what they're famous for or even what they've dedicated most of their time to? From looking at their histories I would not describe them as "coders." Let alone presume that they have anything to offer anyone doing the same in a modern context. "Keep the whole program in your head?" Cool advice for small greenfield projects that you can sell to unsophisticated companies and then move on. Interesting that it com…
A good way to keep a program in your head: Break it up into a few or several smaller programs that interact through clean interfaces. Then you can keep one smaller, simpler program in your head at a time, then integrate them at the end once all the smaller programs are working.
Those are called functions.
Just to elaborate on "start with a simpler subcase": you can even start with a single example and do what your code will be supposed to be doing automatically by hand. After your draft architecture stands, you can even hardwire what each component does for that one example to see if things fit together before implementing the general method for each component, which provides an opportunity for early integration testing that is priceless.
The current essay recommends building bottom-up primitives that serve as primitives or languages (DSLs) for the next levels. This is true, but you can do this upside down. For example, you can write code that looks like pseudo-code because implementations of functions you call do not (or not yet) exist. The code directly reflects how you think, and you worry about the implementation later. A special instance of that is API design, where you design interfaces without implementing them yet; you can then write client code and judge if the hypothetical API would be flexible enough, be easy enough to use, and be feature complete and orthogonal. When designing an architecture in a team with multiple people, you can use paper cards with an example piece of data that you pass from person to person, with each person "performing" a component. They can then check that they have what they need to carry our their task (otherwise there may be bad surprises when integrating components later).
I found that some people are more leaning "top down" and others more "bottom up"; I like to mix both styles, with system architectures designed top down and the core algortihms inside their components often being designed bottom-up, sometimes also top-down.
Ironically, looking only at the headline, one could say that abstraction enables one to solve problems without getting the whole problem in one's head, or problems bigger than what anyone can hold in their head, at least not at the same time, which kind of is the whole point made by SICP.
> You never understand other people's code as well as your own. No matter how thoroughly you've read it, you've only read it, not written it. There is certainly some truth to this. On the other hand, it's possible to become blinded to defects in code you've written yourself. You see what you intended for the code to do rather than what it actually does. Reading someone else's code, it can be easier to see what's real…