SICP: The only computer science book worth reading twice? (2010)

My favourite part of SICP and something that has stuck with me for years is the idea of "wishful programming". That is where you build something top-down by simply wishing you had the lower-level routines. Then, of course, you actually go and build those lower-level routines until you reach the bottom. I find this way of thinking works really well with test-driven development. Write a test against functionality you wish you had, then go and fulfill that wish. Most developers seem to build stuff bottom-up and then end up with something that isn't really what anyone wished for.

The Smalltalk world has great support for this, through coding in the debugger. You should try Pharo.

Interestingly, Dr. Donald Knuth used pretty much that approach when writing TeX --- he started by writing out the sort of formatting/tagging which seemed appropriate, then theorizing about the sort of programming which would be appropriate for markup (hence macros), then worked on the implementation.

I've been trying a similar thing for my own effort to create a library for modeling G-code in OpenSCAD --- hopefully with the recent re-write in "pure" OpenPythonSCAD it will become something usable.

They do that because their wish is performance and naturalness.

You may accidentally wish something you don’t yet know the true nature of, and this will create a fragile mess at the bottom. It usually does, cause algorithmic nature of things is rarely intuitive. Starting from the bottom is like starting from quarks that you have rather than from “I want magic to exist”. Well it does not. You reach the bottom and there’s quarks instead of magicules and you’ve lost all context clues on the way which could help to convert between two physics.

Both approaches have their use, because sometimes you have to be bold with your wishes to solve a deep problem. But personally I prefer magic to be packed into the before-topmost layer. I.e. build from the bottom up, and then, just before the business logic, create a convenience magic layer that translates to/from business speak. It becomes adjustable and doesn’t induce a tangled mess all the way down.

So I think one of the things best avoided in life in general is extremity, in all its various guises. No single technique should be followed like scripture, but rather incorporated into ones toolkit and used where appropriate. Building top-down will get you where you want, but risks fragile underpinnings due to a lack of cross-cutting architectural guidance. But, on the other hand, bottom-up might get you the best foundations at each layer but ultimately deliver nothing of value to the users. In practice it's necessary to take a balanced approach and, of course, mistakes will be made and experience will become the guide. Like you I definitely employ the "meet in the middle" approach in practice, but what SICP taught me is how to think about starting at the top, that is, to build upon wishes.