7 ms·

After programming for 20 years, I've noticed that programmers are aware of the potential benefits of any abstraction that they have internalized, and blithely u

by btilly 7y ago

After programming for 20 years, I've noticed that programmers are aware of the potential benefits of any abstraction that they have internalized, and blithely unaware of the costs. Because, having climbed that learning curve, it is now free to them. The result is that programmers introduce complexity lightly, and when they walk into a new language/organization/etc are inclined to add random abstractions that they are used to from past experience. And yes, I am not immune.

darkpuma 7y ago
> "After programming for 20 years, I've noticed that programmers are aware of the potential benefits of any abstraction that they have internalized, and blithely unaware of the costs." 'Lisp programmers know the value of everything and the cost of nothing.'
- braythwayt 7y ago
  Underrated comment! Here’s the footnote: “Perlisisms: EPIGRAMS IN PROGRAMMING by Alan J. Perlis” http://www.cs.yale.edu/homes/perlis-alan/quotes.html http://www.cs.yale.edu/homes/perlis-alan/quotes.html
azeirah 7y ago
I wouldn't look at it that negatively. Programming is like speaking a language, I don't mean what programming language you "speak" (ie, c++, or java, or whatever), but how you're used to speaking in it. Like real language, you probably prefer certain idioms, you have your own style and you know certain words better than others. This is similar to how we program, we know certain algorithms, yet are oblivious to others, we have our favorite abstractions and have our etc. There are downsides to these habits for both spoken language and computer programming languages, no doubt, you can get stuck in a rabbit hole without seeing you're in one. In the end, a similar approach works for both, read and write widely if you want to be great at these, meet different groups, work on uncomfortable projects, you know the drill. Just like how you expand your language and therefore your world; socially.
tempguy9999 7y ago
Your criticism of abstractions is very much in the abstract. What abstractions? What costs of these? In human comprehension, in runtime, in reliability, in mem/cpu? Can you give examples which I can usefully learn so as to avoid? TIA
- tempguy9999 7y ago
  Replying to myself as I thought of an example from my own past which is relevant. After discovering the eye-opening expressivity of functional programming years ago with Dylan and Haskell, I had a substantial project in javascript. I found JS supported first class closures and lambdas, which allowed me to make iterators. The novelty was they were iterators not over lists but over trees (DOM trees in this case but of course any tree could be made iterable). I understood there would be a learning cost for anyone who took over from me so I left plenty of docs and pointers. It would not be a small cost either, my successors would have to learn to think differently, at a higher level and possibly rather alien (to them) way. But was it worth the cost, bloody hell yes! Not having that iterable and rather declarative abstraction over DOM trees would have greatly bloated the code and consequently brought in bugs by the bagful. I would do in a couple of lines what would have taken half a page to do, in many locations. So it had a human cost but if you could overcome that, a seriously huge human benefit.
  - dalyons 7y ago
    haha did your successors think it was worth the cost?
    - tempguy9999 7y ago
      What happened was interesting and unexpected. I was building on top of an application (call it H) which had the DOM trees to manipulate, and JS to manipulate it with. I was reporting new bugs in H continuously, 1 or 2 every day. Because of the abstractions I'd done (it wasn't only tree iterators) I could largely work around the bugs invisibly - I pushed the bug-special-case-handling code down to make it invisible when using my abstractions. That made it all too viable to continue using an crappy, flaky product far longer than would have been possible - or sensible - without those abstractions. I'd turned the abstractions' value into a liability! I finally told them it wasn't worth continuing with H, they junked it AFAIK and I walked away.
GorgeRonde 7y ago
The absence of abstraction being what exactly ? Also beware of that kind of pseudo-wise thinking. Is there a point in climbing up a learning curve anymore ? Maybe you have a constant and massive stream of fresh bodies to throw at your "simple" solutions before laying them aside once those abstractions have clogged up their heads ... And maybe if you can unskilled workers at such a scale, it's because you have massive fundings as well... More a question of financial optimization than software engineering I think
- btilly 7y ago
  Before dismissing it out of hand, take a look at the Go language. It was designed to make specific kinds of common abstractions hard exactly because, when working at scale, programmers routinely create disasters by layering abstractions in a way that nobody can understand the consequences of.
  - jkachmar 7y ago
    This is exactly the kind of pseudo-wisdom that I read the GP as referring to, though. In the case of Go, the core team saw the pain of indirection-masquerading-as-abstraction in complex Java/C++ codebases and considered the whole thing to be a boondoggle. As a result of this we’ve been saddled with a popular language in which two massive projects (gvisor and kubernetes) have had to hack their own expressivity into the language just to build complex software (i.e. codegen’d generics) I worry about the cyclic nature of progress in our industry, where wonderful advancements can be made and then walked back or under-utilized because we aren’t patient enough to learn them thoroughly.
  - pjmlp 7y ago
    Go is Java 1.0 all over again. If it's enterprise adoption ever goes beyond Kubernetes and Docker, expect GoEE and Go Design Patterns to make their appearance. Worse, since its plugin support is really cramped down, expect any enterprise grade CMS to be built on hundreds of processes. This happens all the time with simple languages, tons of library boilerplate code.
einpoklum 7y ago
That means you have probably not been programming C++. In C++, the cost of abstraction is a fundamental consideration, and while you can still ignore it - most resources about using C++, and gradually even the language itself, tend to nudge you towards avoiding abstraction costs in various ways (sometimes ugly, sometimes elegant). Plus, core language designers and compiler architects bend over backwards to reduce the cost of various abstractions to nothing or very little. Plus, it happens that sometimes, you can use stronger abstractions to _reduce_ cost rather than increase it.

by btilly 7y ago

darkpuma 7y ago

> "After programming for 20 years, I've noticed that programmers are aware of the potential benefits of any abstraction that they have internalized, and blithely unaware of the costs." 'Lisp programmers know the value of everything and the cost of nothing.'

braythwayt 7y ago
Underrated comment! Here’s the footnote: “Perlisisms: EPIGRAMS IN PROGRAMMING by Alan J. Perlis” http://www.cs.yale.edu/homes/perlis-alan/quotes.html http://www.cs.yale.edu/homes/perlis-alan/quotes.html

azeirah 7y ago

I wouldn't look at it that negatively. Programming is like speaking a language, I don't mean what programming language you "speak" (ie, c++, or java, or whatever), but how you're used to speaking in it. Like real language, you probably prefer certain idioms, you have your own style and you know certain words better than others. This is similar to how we program, we know certain algorithms, yet are oblivious to others, we have our favorite abstractions and have our etc. There are downsides to these habits for both spoken language and computer programming languages, no doubt, you can get stuck in a rabbit hole without seeing you're in one. In the end, a similar approach works for both, read and write widely if you want to be great at these, meet different groups, work on uncomfortable projects, you know the drill. Just like how you expand your language and therefore your world; socially.

tempguy9999 7y ago

Your criticism of abstractions is very much in the abstract. What abstractions? What costs of these? In human comprehension, in runtime, in reliability, in mem/cpu? Can you give examples which I can usefully learn so as to avoid? TIA

tempguy9999 7y ago
Replying to myself as I thought of an example from my own past which is relevant. After discovering the eye-opening expressivity of functional programming years ago with Dylan and Haskell, I had a substantial project in javascript. I found JS supported first class closures and lambdas, which allowed me to make iterators. The novelty was they were iterators not over lists but over trees (DOM trees in this case but of course any tree could be made iterable). I understood there would be a learning cost for anyone who took over from me so I left plenty of docs and pointers. It would not be a small cost either, my successors would have to learn to think differently, at a higher level and possibly rather alien (to them) way. But was it worth the cost, bloody hell yes! Not having that iterable and rather declarative abstraction over DOM trees would have greatly bloated the code and consequently brought in bugs by the bagful. I would do in a couple of lines what would have taken half a page to do, in many locations. So it had a human cost but if you could overcome that, a seriously huge human benefit.
- dalyons 7y ago
  haha did your successors think it was worth the cost?
  - tempguy9999 7y ago
    What happened was interesting and unexpected. I was building on top of an application (call it H) which had the DOM trees to manipulate, and JS to manipulate it with. I was reporting new bugs in H continuously, 1 or 2 every day. Because of the abstractions I'd done (it wasn't only tree iterators) I could largely work around the bugs invisibly - I pushed the bug-special-case-handling code down to make it invisible when using my abstractions. That made it all too viable to continue using an crappy, flaky product far longer than would have been possible - or sensible - without those abstractions. I'd turned the abstractions' value into a liability! I finally told them it wasn't worth continuing with H, they junked it AFAIK and I walked away.

GorgeRonde 7y ago

The absence of abstraction being what exactly ? Also beware of that kind of pseudo-wise thinking. Is there a point in climbing up a learning curve anymore ? Maybe you have a constant and massive stream of fresh bodies to throw at your "simple" solutions before laying them aside once those abstractions have clogged up their heads ... And maybe if you can unskilled workers at such a scale, it's because you have massive fundings as well... More a question of financial optimization than software engineering I think

btilly 7y ago
Before dismissing it out of hand, take a look at the Go language. It was designed to make specific kinds of common abstractions hard exactly because, when working at scale, programmers routinely create disasters by layering abstractions in a way that nobody can understand the consequences of.
- jkachmar 7y ago
  This is exactly the kind of pseudo-wisdom that I read the GP as referring to, though. In the case of Go, the core team saw the pain of indirection-masquerading-as-abstraction in complex Java/C++ codebases and considered the whole thing to be a boondoggle. As a result of this we’ve been saddled with a popular language in which two massive projects (gvisor and kubernetes) have had to hack their own expressivity into the language just to build complex software (i.e. codegen’d generics) I worry about the cyclic nature of progress in our industry, where wonderful advancements can be made and then walked back or under-utilized because we aren’t patient enough to learn them thoroughly.
- pjmlp 7y ago
  Go is Java 1.0 all over again. If it's enterprise adoption ever goes beyond Kubernetes and Docker, expect GoEE and Go Design Patterns to make their appearance. Worse, since its plugin support is really cramped down, expect any enterprise grade CMS to be built on hundreds of processes. This happens all the time with simple languages, tons of library boilerplate code.

einpoklum 7y ago

That means you have probably not been programming C++. In C++, the cost of abstraction is a fundamental consideration, and while you can still ignore it - most resources about using C++, and gradually even the language itself, tend to nudge you towards avoiding abstraction costs in various ways (sometimes ugly, sometimes elegant). Plus, core language designers and compiler architects bend over backwards to reduce the cost of various abstractions to nothing or very little. Plus, it happens that sometimes, you can use stronger abstractions to _reduce_ cost rather than increase it.