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

81–90 of 121 posts

Re: The Wrong Abstraction

#81

Post by Chris2048 »

sbov wrote: post #63
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…

Off the top of my head, there are two reasons people seem to de-duplicate code. One is because two or more things happen to share similar code. Another reason is because two or more things must share similar code. It seems like you are speaking of the first reason. There is no dependency, and the programmer is creating one. IMHO you should have at least 3 instances before creating an abstraction to reduce your code.…

I think that principle I've heard before called "1, 2, 3, abstract"; as in, wait until you see it at least three times before considering extraction.

I'd also add - wait until the code is 'stable', i.e no longer under active architectural development, connected only to other stable parts (or with stable/authoritative interfaces) and having then existed in such a state for a continued period of varied usage. then refactor.

Re: The Wrong Abstraction

#82

Post by ThrustVectoring »

elcapitan wrote: post #49
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…

If this is mostly something amateurs do, then who are those people that bring us all these wonderful abstractions like AbstractClickableLittleButtonWithTinyImageOnTheLeftSideFactoryControllerStrategyImplementation?

Expert amateurs.

Re: The Wrong Abstraction

#83

Post by Anchor »

curun1r wrote: post #58
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 th…

I think those four criteria beautifully capture many goals of software design. And for example, we could say that we reduce system state with a functional approach, make component coupling looser by indirection with object orientation, and decrease code complexity by structured programming.

Re: The Wrong Abstraction

#84

Post by Chris2048 »

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.

Sounds like the books actually teach poor practise, divorced from context. The harms of abstraction is nothing that can't be printed - this isn't qualia

Re: The Wrong Abstraction

#85

Post by Anchor »

Chris2048 wrote: post #81
sbov wrote: post #63

Earlier quoted context omitted.

Off the top of my head, there are two reasons people seem to de-duplicate code. One is because two or more things happen to share similar code. Another reason is because two or more things must share similar code. It seems like you are speaking of the first reason. There is no dependency, and the programmer is creating one. IMHO you should have at least 3 instances before creating an abstraction to reduce your code.…

I think that principle I've heard before called "1, 2, 3, abstract"; as in, wait until you see it at least three times before considering extraction. I'd also add - wait until the code is 'stable', i.e no longer under active architectural development, connected only to other stable parts (or with stable/authoritative interfaces) and having then existed in such a state for a continued period of varied usage. then refa…

I'd say this is sound advice for core components of the system, but we may want also to consider the types of the dependencies. For example, I would not wait for three times if the dependency is some kind of external system (DB, UI, Network, MQ, OS, Library, Framework, or the like) which is volatile in one of the worst ways - not directly under your control, unlike your own source code.

Re: The Wrong Abstraction

#86

Post by Chris2048 »

agentultra wrote: post #50

I hate needless abstractions for the sake of removing duplication, DRY, etc. It's mad. Most of these languages don't have proper macros and so you end up going through these logical contortions to achieve a particular pattern of behavior... and it's just noise. Anyone who comes along can look at that code for hours and never know whether it performs any work (or even what that work is). A little duplication is fine u…

I think lack of things like macros is the bigger problem. There are a limited ways to abstract, or represent duplications, in a lot of languages. Sometime a comment in an issue tracker might help.

Re: The Wrong Abstraction

#87

Post by dozzie »

bograt wrote: post #44
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 broadly agree with this, but draw a slightly different conclusion: that the imperative when growing a large code base is proper tooling/planning for dependency management. If good dependency management is cheap , programmers will use it, and even if some dependencies are volatile, side-effects can be bounded by the dependency graph.

We have ~good (and certainly cheap) dependency management in Ruby (gems) and JavaScript (npm), and it leads projects straight to dependency fractal. No, it can't be bounded by making it easier.

Re: The Wrong Abstraction

#88

Post by dozzie »

exelius wrote: post #30
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 are also different kinds of dependencies. Some dependencies are so common, they might as well be a feature of the language itself (Google's OAuth Java client libraries or Apache HTTPClient, for example). It would be a waste of time to write a custom OAuth or HTTP library - much better to just add the dependency and go on your way. IMO the danger is greater with other languages that don't have the library suppor…

Of course there are different kinds of dependencies. I believe it was not the point of wellpast that dependencies are evil and bad, I think it was that dependencies have cost, and most the time programmers consider them as (almost) free.

Indeed, dependencies have nearly zero immediate cost, but in the long run they are expensive and need to be weighed against the gain from their use.

Re: The Wrong Abstraction

#89

Post by sebastos »

lackbeard wrote: post #75
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.

I don't think math is the study of abstraction. It seems to me it's proving truths about formal systems. Abstraction has the same purpose in math as it does in programming, a tool to more effectively communicate ideas.

Not sure I agree. Usually, mathematics is developed backwards - you have a concrete question that you want to answer, and you reason that it can be answered so long as such and such as true. The formal system is developed post-hoc to give yourself a language to reason in, but you're really trying to take the result you already "knew" to be true, and find the least restrictive system description to which it still applies. Then you look for parallels and generalizations. The abstractions are in a large sense the most important and difficult thing to create, because you're creating a schematic and saying "if you can rephrase your problem into these terms, then I already proved this intuitively correct thing for you, so you don't have to worry about edge cases". Algebra, geometry, calculus, etc. all follow this model. A lot of the conclusions in, e.g. analysis are obvious once you impose continuity.

The object of mathematics is to produce abstractions that make proofs possible or trivial. Sets, fields, groups, categories, functions, integers, reals, complex numbers, quaternions - these aren't notational conveniences that are introduced to make it easier to talk about. They're important because if you have something with the properties of a group, you know some powerful truths about it for free. If you change anything about the definition of group, the set of truths you know changes. People have been grinding on what the definition of a set should be for a century, trying to build the best possible abstraction, and they have all of the same problems coders have. You assume to much, it's not very general. Don't assume enough, there's nothing interesting to say that's unilaterally true.

So I would argue that characterizing math as the study of abstraction is largely fair. You "see" a result is probably true some of the time, and then you try to find out just how general you can make that statement.

Re: The Wrong Abstraction

#90

Post by rco8786 »

JDDunn9 wrote: post #16

A 3rd option would be to simply apply good programming standards like a function doing one thing and only one thing.

At some point, you're gonna have to introduce some logic into your program, and that logic is gonna have to be in a function.
Post reply on HN