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

101–110 of 121 posts

Re: The Wrong Abstraction

#101

Post by curun1r »

wellpast wrote: post #94
curun1r wrote: post #58

Earlier quoted context omitted.

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'm willing to add increased coupling if it makes my code more stateless. I like statelessness as a top priority. However I'm not sure how statelessness ever comes into tension w/ coupling. Aren't they mostly orthogonal concerns? > I'm willing to make it more complex if it reduces coupling. Complexity = f(Coupling), in my definition. So an increase in coupling results in an increase of complexity. Sounds like you h…

There's a few ways in which state vs coupling can play out. Often they're part of the architecture of a system rather than the low-level functions and types that a developer creates. As an example, should you keep an in-memory queue (state) of jobs coming into your system or maintain a separate queue component (coupling). By extracting the state from your component and isolating it in Rabbit or some other dedicated state management piece, you've made the job of managing that state easier and more explicit.

As for complexity, there are many different types. Coupling is a form of complexity, but it's not the only one. Cyclomatic complexity is another and one. Using regular expressions often increases the complexity of code. And one need only look at the spec for any reasonably popular hash function to see a completely different sort of complexity that's not the result of either coupling unique paths through code. The composite of all the different forms of complexity is how I'd define it since they all add to a developers cognitive load.

Re: The Wrong Abstraction

#102

Post by jdmichal »

fao_ wrote: post #99
jdmichal wrote: post #92

Earlier quoted context omitted.

Additionally, what I also see that tends to separate out experienced vs inexperienced programmers is attempting to deduplicate things because they appear similar. By this, I mean that these two things just happen to do similar things or have similar fields, but the operation or structure that they are attempting to represent is fundamentally different. When they eventually diverge, because they were different operati…

> This is where you end up with functions that take 10 different option parameters, all of which activate a different code path. Or you could abstract the commonalities out into a higher-order function.

What is the higher order function for two disparate code paths, controlled by a parameter switch? `if`?

Re: The Wrong Abstraction

#103

Post by runT1ME »

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 have a third reason. Abstraction, or code de-duplication, if done right, ends up making code easier to reason about. The paper that made me rethink everything I knew is

http://www.mpi-sws.org/~dreyer/tor/papers/wadler.pdf

and explains this wonderfully.

Re: The Wrong Abstraction

#104

Post by douche »

grandalf wrote: post #96
TheOtherHobbes wrote: post #76

Earlier quoted context omitted.

It's all a bit no-true-Scotsman though. abstraction != dry bad abstraction != anti-dry Abstraction is primarily about separation of concerns, not about avoiding repetition. Drying out code that's repeated all over isn't the same as creating a formal abstraction for some element of the overall logic. Which is why >once a codebase uses several very wrong abstractions, it becomes significantly more confusing to work on,…

Precisely. Very well put. If anything, some developers use design patterns as a grab bag when solving a problem... a better approach is to model the solution and then be ready to "back in" to a design pattern upon noticing strong similarity or observing that the design pattern is a bit more abstract way of doing the same thing. Because of the tendency to pick a pattern first and design for the domain later, many inst…

A graphic I found very enlightening in the past year is here: http://blog.thecodewhisperer.com/images/age_old_battle/virtu...

from this blog post: http://blog.thecodewhisperer.com/2013/12/07/putting-an-age-o...

There's a lot of other good stuff there too, when you start digging through the archives.

Generally, I find that I've got to build a prototype first, which is quick and dirty and ugly, but works. Then iterate as the structure emerges. Some things stay in flux, and it's okay to leave them messier, but eventually the code and functionality settles out and commonality arises. Quite often, I don't necessarily know what I'm doing going in; I've got a general goal, but until I experiment a bit, the best way to get there is unclear.

One of the joys and pitfalls of a multi-paradigm language like C# is that there are so many different ways to skin a cat. You can pick and choose procedural, object-oriented, functional, or some bastard mishmash of all of the above and more.

Re: The Wrong Abstraction

#105

Post by hinkley »

TheOtherHobbes wrote: post #76
grandalf wrote: post #67

It's funny how often I've made this argument with even fairly experienced programmers and they seem to have a visceral reaction to the code being "less dry" than it could possibly be. Similarly, once a codebase uses several very wrong abstractions, it becomes significantly more confusing to work on, exponentially increasing cost. The temptation to use a mature library as a dependency is very strong since time is init…

It's all a bit no-true-Scotsman though. abstraction != dry bad abstraction != anti-dry Abstraction is primarily about separation of concerns, not about avoiding repetition. Drying out code that's repeated all over isn't the same as creating a formal abstraction for some element of the overall logic. Which is why >once a codebase uses several very wrong abstractions, it becomes significantly more confusing to work on,…

I would argue that 'Refactoring' gives you a bunch of tools for discovering your good abstractions. Whereas GoF puts a bunch of ideas in your head without giving you any preparation for using them responsibly.

Re: The Wrong Abstraction

#106

Post by hinkley »

cpeterso wrote: post #69

I'm reminded off ESR's "curse of the gifted" email, schooling Linus Torvalds on the lack of modularization and code-sharing in Linux's driver code. :) http://lwn.net/2000/0824/a/esr-sharing.php3

Oh my. I recall reading this years ago. I had totally forgotten that Eric basically tells Linus to grow up and learn to use version control. Now we're all using Linus' version control.

Re: The Wrong Abstraction

#107

Post by habitue »

Anchor wrote: post #52
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…

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 y…

I think writing an abstraction that allows you to decouple your app in a way that you could use either Angular or React is going to take far longer than just rewriting your app if you ever get to the point of needing to switch.

Re: The Wrong Abstraction

#108

Post by habitue »

ubercore wrote: post #93
Anchor wrote: post #48

Earlier quoted context omitted.

> The real offense when we factor duplicated code is the new dependency that is added to the system. A slight tangent on that note, but I think many of the problems with current web development result from the same root cause: adding yet another dependency to solve an almost trivial problem. Sometimes going to the extreme of for the sake of saving few keystrokes. Need one function to find an item in a collection? Ref…

I think javascript is intrinsically going to be one of the worst examples of that. Stemming back to the days when javascript programmers learned that using a library like (then jQuery) lodash is the _only_ way to correctly get your code to work in all cases. That culture then became ingrained, and in my opinion helped lead to the state most JS packages are in these days. In my experience, this is one of the greatest…

Babel doesn't solve the problem of having a minimal standard library. Unlike say Python or Ruby, where batteries are included, JS is roll it yourself, add a dependency, or go without in almost every case. Even for seemingly trivial things like "Array#contains"

Re: The Wrong Abstraction

#109

Post by solipsism »

nickbauman wrote: post #78
Jtsummers wrote: post #39

Earlier quoted context omitted.

Novice, not amateur. Amateurs aren't paid, professionals are. Novices are inexperienced, journeyman and masters are more skilled and experienced. A novice can have a ton of knowledge (from books), but be too inexperienced to apply it. A novice can be a professional, this is what internships and entry-level jobs are supposed to be for. Paired with mentorship and structured work assignments (structured in the sense of…

Professional means you teach (notice the word root in "profess" as in "professor"). It really means you know enough that you can teach others how to do it right, not about get paid for it per se.

You have the etymology of "professor" and "professional" completely wrong. You can't just notice the same root in two words and then completely reinvent the meaning of one to make it have something to do with the meaning of the other. The evolution of language is complex. Here: http://lmgtfy.com/?q=etymology+profession

Re: The Wrong Abstraction

#110

Post by kbouck »

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…

Amusing arguments for statelessness from the ØMQ Guide by Pieter Hintjens [1]:

> "If there's one lesson we've learned from 30+ years of concurrent programming, it is: just don't share state. It's like two drunkards trying to share a beer. It doesn't matter if they're good buddies. Sooner or later, they're going to get into a fight. And the more drunkards you add to the table, the more they fight each other over the beer."

...

> "Code that wants to scale without limit does it like the Internet does, by sending messages and sharing nothing except a common contempt for broken programming metaphors."

[1] http://zguide.zeromq.org/page:all#toc45

Post reply on HN