Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Wrong Abstraction

sandimetz.com

Post reply on HN
Print view View original

51–60 of 121 posts

Re: The Wrong Abstraction

#51

Post by lmm »

amelius wrote: post #28
tejohnso wrote: post #14

"Programmer B feels honor-bound to retain the existing abstraction" I think it's more often likely that the next person comes along and lazily forces the most brittle, minimal change possible to make their new requirement work without thinking about the larger context. Even if that means putting a complicated conditional into the existing function, while leaving the existing function name intact. This isn't about hon…

> This isn't about honor. It's simply bad programmer behavior. It might be due to lack of skill or experience, or maybe laziness, or lack of discipline, or some other negative attribute. Time pressure may also be an issue. Or, what if the system is only for prototyping, and later turns out to be needed for production (a management decision)?

Then management should be made aware that they're incurring technical debt by taking that decision. It can be worth compromising code quality for short-term goals on occasion, but you should do it with your eyes open.

Re: The Wrong Abstraction

#52

Post by Anchor »

tel wrote: post #27
wellpast wrote: post #17

I can tell an amateur programmer from a professional by looking at their order of priorities when they grow a code base. Amateur programmers tend to put code de-duplication at the top of their priority list and will burn the whole house down to that often-trivial end. This writer is pointing out that there are other concerns that far, far trump duplicated code -- and she's right. However she's not elaborating enough…

I understand and sympathize with the idea you suggest here, but I also wonder about the fine tuning. We accept that both duplication and dependency are bad (and certainly that the minimal, maximally stable dependency set is best) but when making that tradeoff what parameters make a duplications better or worse than a dependency? Are there languages or toolchains which cause this tradeoff to fall in the opposite direc…

I think the right approach is not to avoid dependencies, but to manage them.

Let's say you are unsure of the correct UI framework just. React, Knockout or Angular? React native? Maybe you don't yet know which database best suits your usage and scaling needs. Should you avoid committing to those dependencies? For how long? Doesn't this slow you down?

A good way to approach this is to isolate the dependencies so that you don't have to commit to the actual implementations (React, Mongo, PostgreSQL, Angular, ZeroMQ, whatever it is you need) early. Of course you start the work with some set of frameworks and libraries, but so that no other part (the parts that does all the important stuff that it unique to your application) of the system knows of the implementations. This way, if the need arises, changing the implementation details will not be expensive.

Isolating the implementation behind an abstraction sometimes introduces boilerplate and duplication, but as the article mentions, the dependency is usually more costly.

Re: The Wrong Abstraction

#53

Post by SideburnsOfDoom »

wellpast wrote: post #17

I can tell an amateur programmer from a professional by looking at their order of priorities when they grow a code base. Amateur programmers tend to put code de-duplication at the top of their priority list and will burn the whole house down to that often-trivial end. This writer is pointing out that there are other concerns that far, far trump duplicated code -- and she's right. However she's not elaborating enough…

There's even a slogan for that: Beware the Share

http://programmer.97things.oreilly.com/wiki/index.php/Beware...

Re: The Wrong Abstraction

#55

Post by MrRage »

dakotasmith wrote: post #35
MrRage wrote: post #29

Earlier quoted context omitted.

> I can tell an amateur programmer from a professional by looking at their order of priorities when they grow a code base. > Amateur programmers tend to put code de-duplication at the top of their priority list and will burn the whole house down to that often-trivial end. To be fair, lots of how to program books spend a lot of time on teaching you how to abstract, and sing abstractions praises to the heavens, as it w…

To be fair, working only from book knowledge and no experience is precisely what makes someone an amateur.

Of course. You can't learn that sort of judgement (when to use vs when not to use) from a book.

But our profession's training material, at least in my experience reading, drills it in your head to use all these abstracting devices.

It's certainly true that you can get some "book knowledge" that tells you that you can over abstract. I mean, this blog post is one example. But I only hear this sort of stuff from things like blog post from experienced devs, it seems to me. (Or maybe I just read the wrong kind of books?)

Re: The Wrong Abstraction

#56

Post by drostie »

protomyth wrote: post #54

Isn't a bit of this governed by which programming paradigm your language uses? I get the feeling the answer and approach are much different when comparing Forth to Java.

Yes. In theory there is a programming paradigm which fixes this, called "aspect oriented programming." I haven't seen a really accessible aspect-oriented system however.

Re: The Wrong Abstraction

#57

Post by dustingetz »

wellpast wrote: post #26
dustingetz wrote: post #19

Earlier quoted context omitted.

The distaste is for complexity. Adding new functions to reduce duplication can add complexity. It can also reduce complexity. It can also decrease complexity for a while and then in the long run increase complexity. Recall the famous quote, "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." Sometimes dependencies are really cheap - when they are the right abstr…

Here's a very objective and powerful way to measure complexity: dependencies and volatility. Otherwise we're all saying "complex" but not being clear and likely meaning different things. For example, a lot of people believe that "not easy" = "complex" but as Rich Hickey articulates that's a counterproductive way to think of complexity. (See http://www.infoq.com/presentations/Simple-Made-Easy )

"dependencies and volatility" But what does this even mean? I'm okay with using Rich Hickey's definitions. But I don't recall that in Rich's talk.

Re: The Wrong Abstraction

#58

Post by curun1r »

wellpast wrote: post #17

I can tell an amateur programmer from a professional by looking at their order of priorities when they grow a code base. Amateur programmers tend to put code de-duplication at the top of their priority list and will burn the whole house down to that often-trivial end. This writer is pointing out that there are other concerns that far, far trump duplicated code -- and she's right. However she's not elaborating enough…

Dependencies (coupling) is an important concern to address, but it's only 1 of 4 criteria that I consider and it's not the most important one. I try to optimize my code around reducing state, coupling, complexity and code, in that order. I'm willing to add increased coupling if it makes my code more stateless. I'm willing to make it more complex if it reduces coupling. And I'm willing to duplicate code if it makes the code less complex. Only if it doesn't increase state, coupling or complexity do I dedup code.

The reason I put stateless code as the highest priority is it's the easiest to reason about. Stateless logic functions the same whether run normally, in parallel or distributed. It's the easiest to test, since it requires very little setup code. And it's the easiest to scale up, since you just run another copy of it. Once you introduce state, your life gets significantly harder.

I think the reason that novice programmers optimize around code reduction is that it's the easiest of the 4 to spot. The other 3 are much more subtle and subjective and so will require greater experience to spot. But learning those priorities, in that order, has made me a significantly better developer.

Re: The Wrong Abstraction

#59

Post by tel »

wellpast wrote: post #37
tel wrote: post #27

Earlier quoted context omitted.

I understand and sympathize with the idea you suggest here, but I also wonder about the fine tuning. We accept that both duplication and dependency are bad (and certainly that the minimal, maximally stable dependency set is best) but when making that tradeoff what parameters make a duplications better or worse than a dependency? Are there languages or toolchains which cause this tradeoff to fall in the opposite direc…

> In some sense this is academic, ... Whether all of this is academic or not, I don't know. But what I do know is that these ideas and their practical implications have an ENORMOUS impact on the practitioner's and business's productivity. > in a very real sense disdain for dependency is something I worry can prevent a project from going through an important high-energy transitory period where semi-formed dependencies…

I think the idea of exploratory work is very similar to what I mention going on in small scopes, but I think this evolution occurs at large scales, too. All the development branch isolation in the world can't and shouldn't stop this sort of broad scale evolution.

Re: The Wrong Abstraction

#60

Post by such_a_casual »

spion wrote: post #36
chowells wrote: post #23

If you found yourself agreeing with article, yet have ever mocked mathematically-derived abstraction patterns like monads, it's time to reconsider. Math is, at its core, the study of abstraction. Things that have been found to be good abstractions in math probably are good abstractions in programming. Learn from history. Mathematically-derived abstractions probably are used because they are the right abstractions.

Agreed, but I think the reason for the mocking is that they're notoriously hard to understand being several layers removed from the programming context. I understand monads in the context of programming, but I wouldn't pretend to understand how they could be applied in other fields. Haven't got the slightest idea. Perhaps importing abstractions straight from mathematics isn't the only answer. We might do better if we…

Programming languages are some of the shittiest languages ever created. Mathematics is probably the best language ever created. The more programming can be like math, the better.
Post reply on HN