About code reuse - here is some disagreement about whether it is a good thing in the first place: 'I also must confess to a strong bias against the fashion for reusable code. To me, "re-editable code" is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.' This is from Donald Knuth: http://www.informit.com/articles/article.aspx?p=1193856
I have to wonder if he was thinking about, for example, a reusable implementation of a hash table. And if we was, why in the world wouldn't he want that. Running with the hash table example: I use them many, many times a day, and if I had to reimplement them every time, I'd be sunk. Just a few moments ago, I wrote a script to check for duplicate entries that looked something like this:
seen = {}
elements.each do |element|
if seen[element]
raise "Duplicate element: #{element.inspect}"
end
seen[element] = true
end
It's quick and dirty and isn't a shining example of architecture. But it found my duplicates and let me move on with my day. But what if I didn't have a reusable hash implementation to lean on? Would I even have attempted to write that script? Or would I have done my duplicate checking manually, wasting about an hour?
Andrew: A story states that you once entered a programming
contest at Stanford (I believe) and you submitted the winning
entry, which worked correctly after a single compilation. Is
this story true? In that vein, today’s developers frequently
build programs writing small code increments followed by
immediate compilation and the creation and running of unit
tests. What are your thoughts on this approach to software
development?
Knuth: As to your real question, the idea of immediate
compilation and "unit tests" appeals to me only rarely, when
I’m feeling my way in a totally unknown environment and need
feedback about what works and what doesn’t. Otherwise, lots of
time is wasted on activities that I simply never need to
perform or even think about. Nothing needs to be "mocked up."
Amusing given the link prompting this whole thread.
In the context where Knuth was writing, he was substantially correct. In languages where you can sufficiently encapsulate sufficiently abstract patterns, it ceases to be. When your abstractions don't leak, you don't need to touch the innards. As Rusky says, size also plays a role.
The very notion of a "non-leaky abstraction" is a tool that is only just beginning to be employed by programmers. At its most advanced level you're talking about bisimulation proofs over abstract data types.
We may get there one day, but for right now just spec'ing interfaces as combinations of consistent laws is a stretch.
I'm not sure that's true. It would certainly be an interesting anthropological undertaking to pin down the details, but (at substantial risk of being wrong) I feel like this was an assumption in early attempts at abstraction and we only feel the need to specify "non-leaky" because we have discovered important things that previous attempts have - in practice - tended to leak.
I think I'm in agreement with you here—we're slowly, as a community, discovering how to make non-leaky abstractions. They've been around for a while in places where "in practice" had a lot of legroom (pure mathematics). CS has a lot of legroom too, but it's taken a long time for us to think about it in such a way to know where we can place our weight.
I think he's probably right about bigger, higher-level, or more domain-specific things. But there is a boundary- tools, languages, simple libraries, etc. can be, should be, and are reused to great effect.
Comments
About code reuse - here is some disagreement about whether it is a good thing in the first place: 'I also must confess to a strong bias against the fashion for reusable code. To me, "re-editable code" is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.' This is from Donald Knuth: http://www.informit.com/articles/article.aspx?p=1193856
I have to wonder if he was thinking about, for example, a reusable implementation of a hash table. And if we was, why in the world wouldn't he want that. Running with the hash table example: I use them many, many times a day, and if I had to reimplement them every time, I'd be sunk. Just a few moments ago, I wrote a script to check for duplicate entries that looked something like this:
It's quick and dirty and isn't a shining example of architecture. But it found my duplicates and let me move on with my day. But what if I didn't have a reusable hash implementation to lean on? Would I even have attempted to write that script? Or would I have done my duplicate checking manually, wasting about an hour?Looks like Ruby. Why use a Hash instead of the built-in Set class?
From your linked article:
Amusing given the link prompting this whole thread.In the context where Knuth was writing, he was substantially correct. In languages where you can sufficiently encapsulate sufficiently abstract patterns, it ceases to be. When your abstractions don't leak, you don't need to touch the innards. As Rusky says, size also plays a role.
The very notion of a "non-leaky abstraction" is a tool that is only just beginning to be employed by programmers. At its most advanced level you're talking about bisimulation proofs over abstract data types.
We may get there one day, but for right now just spec'ing interfaces as combinations of consistent laws is a stretch.
I'm not sure that's true. It would certainly be an interesting anthropological undertaking to pin down the details, but (at substantial risk of being wrong) I feel like this was an assumption in early attempts at abstraction and we only feel the need to specify "non-leaky" because we have discovered important things that previous attempts have - in practice - tended to leak.
I think I'm in agreement with you here—we're slowly, as a community, discovering how to make non-leaky abstractions. They've been around for a while in places where "in practice" had a lot of legroom (pure mathematics). CS has a lot of legroom too, but it's taken a long time for us to think about it in such a way to know where we can place our weight.
I think he's probably right about bigger, higher-level, or more domain-specific things. But there is a boundary- tools, languages, simple libraries, etc. can be, should be, and are reused to great effect.