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

111–120 of 121 posts

Re: The Wrong Abstraction

#111

Post by hex13 »

This is the old truth - premature abstraction is a root of all evil (I know original quote was "optimization", but isn't an abstraction just some "architectural optimization"? ;)

On the other hand: I often see copy pasted code which have these same characteristics author wrote about: "Another additional parameter. Another new conditional. Loop until code becomes incomprehensible."

If somebody writes too many conditionals, parameters and creates incomprehensible loops, then he will do it always, no matter whether in abstracted code or in copy pasted code...

The problem is that most of programmers are not skilled enough to write good code.

So sometimes there is a need for refactor wrong abstractions in legacy code, sometimes there is need for cleaning tons of copy-pasted code and make good abstractions... Either way - maintaining is hard.

Re: The Wrong Abstraction

#112

Post by hex13 »

Jtsummers wrote: post #39
dakotasmith wrote: post #35

Earlier quoted context omitted.

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

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…

Besides I think everybody who e.g. makes some side-projects, or is active in open source is in fact amateur in the sense of "a person who does something (such as a sport or hobby) for pleasure and not as a job" :)

Re: The Wrong Abstraction

#113

Post by Anchor »

habitue wrote: post #107
Anchor wrote: post #52

Earlier quoted context omitted.

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.

In case of a UI, the trick is not so much to write an abstraction for this, but to write the application logic such a way that it does not depend on the UI framework.

Your own UI code should be limited to displaying the data with the help of the framework. This minimal UI code should depend on the application code and that should be the only dependency between the two.

There are simple techniques to keep view logic and application logic decoupled, for example by introducing a separate data structures prepared and optimized for view components to consume. An added bonus of this is testability of both application and UI logic without opening a browser.

Re: The Wrong Abstraction

#114

Post by Anchor »

ianamartin wrote: post #91
lukaslalinsky wrote: post #74

Earlier quoted context omitted.

You can always chose to change the surrounding code whenever you are adding something to an existing mess, to make a bit less mess. I have heard excuses about not being given time to do it from the management many times before, but the fact is that you are the one who deals with the code, you need to make the decision. If you are not comfortable doing some change, you are the one who needs to be writing the tests or…

I don't think this is a realistic attitude. I've gotten my fingers burned more than once by trying to take this approach. The problem with web applications is that they are not self-contained. You don't necessarily know who or what is calling what or how for some legacy applications. I can agree with the concept of improving code as you see it, but changing the abstraction--the topic of conversation here--cannot be d…

Maybe I am being idealistic, but I think the sentiment in the discussion concerns not only the ideal coding techniques themselves, but also the bigger picture of business needs. That is, if we took the approach of keeping code in somewhat decent shape, we would end up, in the long run, producing the whole system more efficiently, and reducing the TCO of the system for the user and the business.

I certainly hope that the discussion is not only about making the lives of the programmers easier.

Re: The Wrong Abstraction

#115

Post by collyw »

Almaviva wrote: post #70
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 can tell an amateur programmer because they aren't getting paid. Flippancy aside though: While I don't think it's what you're arguing for, I'd fear some would use an argument like this to defend a workflow and culture where new features are started by copy and pasting a mass of code, and then going in and tweaking little things here and there. Then when something has to change across the system, there are endless t…

Thats what I was thinking reading the article.

Re: The Wrong Abstraction

#116

Post by collyw »

drostie wrote: post #56
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.

Decorators in Python are pretty much the same idea. I see them used quite a lot in Flask and Django.

Re: The Wrong Abstraction

#117

Post by Jtsummers »

hex13 wrote: post #112
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…

Besides I think everybody who e.g. makes some side-projects, or is active in open source is in fact amateur in the sense of "a person who does something (such as a sport or hobby) for pleasure and not as a job" :)

In general, if a professional also donated their time to something it doesn't make them an amateur. See lawyers doing pro bono work, or carpenters building a habitat house as examples.

Re: The Wrong Abstraction

#118

Post by ubercore »

habitue wrote: post #108
ubercore wrote: post #93

Earlier quoted context omitted.

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"

It may not help that case in particular, but there's a _lot_ that ES6/ES2015 add to the table: http://babeljs.io/docs/learn-es2015/

A lot of things in there would need a library for cross-browser compatibility still. That's my point, but I take yours as well. It's still a very BYOL (bring your own library) kind of a language!

Re: The Wrong Abstraction

#119

Post by daxfohl »

Meh, it's an easy situation to get out of though. Especially with a typed language and decent IDE: right-click, "inline function"; check your git status to see what changed, go to those files and remove unused branches (which a decent IDE should hightlight and provide 2-keystroke fixes for). 2 minutes, done.

Grotesquely replicated code is a much more difficult situation to resolve.

I'm guessing the OP primarily uses untyped languages. I'd offer that that is the core of the problem, not the abstractions.

Re: The Wrong Abstraction

#120

Post by hasenj »

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.

In addition to @sebatos response, I'd add that a formal system is nothing than an abstraction of some concrete problem.
Post reply on HN