Earlier quoted context omitted.
You've found that the abstraction isn't useful for doing your task. That's not leaking. That's like complaining that your ice cream maker can't cook rice. That's not what it's for . In fact, this is a common manner for abstractions to become leaky. You find you are in need some guarantee not present in the abstraction. You choose to add whether or not that guarantee is satisfied to the shared interface. Congratulatio…
I have to care about what's inside it (to know whether the performance is up to what I need) rather than just the interface. To me, that's leaking. For example, if I have to care whether the "collection" is implemented as a linked list or as a vector, the the "collection" abstraction has leaked.
Essays on programming I think about a lot
91–99 of 99 posts
Re: Essays on programming I think about a lot
#92I read Peter Naur's "Programming as Theory Building" and thought it quite good. http://pages.cs.wisc.edu/~remzi/Naur.pdf At the time I found it I was was working where the key challenge was not so much technical as much as ensuring that simple technology, spread across a large breadth of functionality, adhered to a consistent vision of the business domain that was being implemented. The program became an implementati…
https://www.csc.gov.sg/articles/how-to-build-good-software
It has a few great quotes scattered throughout.
"Building good software involves alternating cycles of expanding and reducing complexity."
"Software should be treated not as a static product, but as a living manifestation of the development team's collective understanding."
"Software projects rarely fail because they are too small; they fail because they get too big."
Re: Essays on programming I think about a lot
#93Love the list, but I definitely think Programming Sucks [1] should be on any list of programming essays. :) 1: https://www.stilldrinking.org/programming-sucks
Yeah, this resonates. I've got in trouble with my wife more than once for being in "code mode" when I'm working and something happens, it seems to turn off my basic empathy for some reason. Programming changes people.
Re: Essays on programming I think about a lot
#94Earlier quoted context omitted.
Indeed proof formalisms are themselves leaky abstractions.
The theories, the implementations, or both?
Re: Essays on programming I think about a lot
#95Earlier quoted context omitted.
The theories, the implementations, or both?
The theories as conceived to relate to the actual programming environment. Any proof about a Haskell program’s correctness relies on a leaky abstraction (an axiomatization) of what will actually happen when you run GHC on the source file.
Re: Essays on programming I think about a lot
#96Earlier quoted context omitted.
Right. As they say, In theory there is no difference between theory and practice; in practice, there is.
Get better theory.
For the record, I meant "Get better theory, and your theory can also talk about the difference between practice and theory."
Re: Essays on programming I think about a lot
#97Earlier quoted context omitted.
I have to care about what's inside it (to know whether the performance is up to what I need) rather than just the interface. To me, that's leaking. For example, if I have to care whether the "collection" is implemented as a linked list or as a vector, the the "collection" abstraction has leaked.
Abstractions are equivalences, not equalities. You shouldn't expect an abstraction to make a linked list the same thing as a vector - they aren't, and they never will be - but they are equivalent for certain purposes, and a good abstraction can capture that equivalence. The performance of those two different collections is not the same, but that's not a leak unless the abstraction tried to claim that it somehow would…
I would even argue that's the point of an abstraction. Hide the details that don't matter to the caller. If performance is a detail that matters, and the abstraction doesn't capture it, then you're using the wrong abstraction.
Re: Essays on programming I think about a lot
#98Earlier quoted context omitted.
The theories as conceived to relate to the actual programming environment. Any proof about a Haskell program’s correctness relies on a leaky abstraction (an axiomatization) of what will actually happen when you run GHC on the source file.
So implementation then..