Definitely one of the better books I’ve read on programming. Much recommended. The chapter with Fran Allen made me realize that what we find so natural now in terms of how languages are designed (even very low level languages), really is just an accident of history, and that maybe we aren’t doing it right.
There’s this overemphasis on reusable software where you never get to open up the box and see what’s inside the box. It’s nice to have these black boxes but, almost always, if you can look inside the box you can improve it and make it work better once you know what’s inside the box. Instead people make these closed wrappers around everything and present the closure to the programmers of the world, and the programmers of the world aren’t allowed to diddle with that. —Donald Knuth
I like this quote (from the blog post). I know he’s talking about something else, but it made me think of Julia’s multiple dispatch (I don’t use that language, just saw a talk on that particular aspect), and Rust’s trait system. At least for the trait system, it feels like you can put in little places in the code where you allow the users of the code to define their own exact behavior that suit their needs. To me, despite having the strictest type system I’ve ever worked with, it feels much more open than say JavaScript or even Python because of this.
something else, but it made me think of Julia’s multiple dispatch (I don’t use that language, just saw a talk on that particular aspect), and Rust’s trait system
I don’t think they can match Literate programming which is a white box. Fun fact - the writers of this book written using literate style garnered a 2014 oscar for technical excellence.
On “The importance of unpacking abstractions”, I’ve found that I (and, likely, some others) have the opposite problem, which is “always unpacking abstractions” - because, when done recursively for any large system, makes you incredibly inefficient because you end up spending an exorbitant amount of unnecessary time learning, instead of doing. (This is mostly a function of my difficulty in tolerating black boxes - I really really want to completely understand all of the layers of a system before I begin to manipulate it.)
That is - the ideal programmer will both have the ability to pierce abstraction layers to understand what’s going on at a lower level, and the ability to manipulate systems without total recursive understanding of every single layer it’s built on - and then employ those abilities appropriately.
For me this is a matter of trust. Do I trust the black box to behave a certain way? And if not, what’s it going to take for me to become optimistic about it so I can stay zoomed out?
I’d call it: the importance of being willing to, interested in, and capable of unpacking abstractions. Or “the importance of not believing in magic”. In my experience programmers that do not believe some things just magically behave some way, and keep digging until they understand what’s going on, are better than those that do, because they tend to come up with workarounds and cures for symptoms instead of causes.
Definitely one of the better books I’ve read on programming. Much recommended. The chapter with Fran Allen made me realize that what we find so natural now in terms of how languages are designed (even very low level languages), really is just an accident of history, and that maybe we aren’t doing it right.
I like this quote (from the blog post). I know he’s talking about something else, but it made me think of Julia’s multiple dispatch (I don’t use that language, just saw a talk on that particular aspect), and Rust’s trait system. At least for the trait system, it feels like you can put in little places in the code where you allow the users of the code to define their own exact behavior that suit their needs. To me, despite having the strictest type system I’ve ever worked with, it feels much more open than say JavaScript or even Python because of this.
I don’t think they can match Literate programming which is a white box. Fun fact - the writers of this book written using literate style garnered a 2014 oscar for technical excellence.
this is the first time i’ve seen literate programming with out-of-order code blocks meaning, it’s more than just swapping the comments and the code
thanks for pointing to that book!
On “The importance of unpacking abstractions”, I’ve found that I (and, likely, some others) have the opposite problem, which is “always unpacking abstractions” - because, when done recursively for any large system, makes you incredibly inefficient because you end up spending an exorbitant amount of unnecessary time learning, instead of doing. (This is mostly a function of my difficulty in tolerating black boxes - I really really want to completely understand all of the layers of a system before I begin to manipulate it.)
That is - the ideal programmer will both have the ability to pierce abstraction layers to understand what’s going on at a lower level, and the ability to manipulate systems without total recursive understanding of every single layer it’s built on - and then employ those abilities appropriately.
For me this is a matter of trust. Do I trust the black box to behave a certain way? And if not, what’s it going to take for me to become optimistic about it so I can stay zoomed out?
I’d call it: the importance of being willing to, interested in, and capable of unpacking abstractions. Or “the importance of not believing in magic”. In my experience programmers that do not believe some things just magically behave some way, and keep digging until they understand what’s going on, are better than those that do, because they tend to come up with workarounds and cures for symptoms instead of causes.