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

That's not an abstraction, that's a layer of indirection

fhur.me

Post reply on HN
Print view View original

91–100 of 240 posts

Re: That's not an abstraction, that's a layer of indirection

#91

Post by themadsens »

voidhorse wrote: post #43

The best way to achieve a good abstraction is to recall what the word meant before computer science: namely, something closer to generalization . In computing, we emphasize the communicational (i.e. interface) aspects of our code, and, in this respect, tend to focus on an "abstraction"'s role in hiding information. But a good abstraction does more than simply hide detail, it generalizes particulars into a new kind of…

Well said! I have met a few of these codesmells where the actual functioning is hidden behind a bewildering maze of facades, shims, proxies and whatnot.

I guess some has had an irresistible itch to use as many patterns from the GoF book as possible.

Re: That's not an abstraction, that's a layer of indirection

#92

Post by Voultapher »

> That’s the sign of a great abstraction. It allows us to operate as if the underlying complexity simply doesn't exist.

While I generally agree with the sentiment that current day software development is too indirection heavy, I'm not sure I agree with that point. All abstractions are leaky and sure good abstractions allow you to treat it like a black box, but at some point you'd benefit from knowing how the sauce is made, and in others you'll be stuck with some intractable problem if you lack knowledge of the underlying layers.

Re: That's not an abstraction, that's a layer of indirection

#94

Post by globular-toast »

psychoslave wrote: post #90

The article seems to go with the premise that abstractions are most often carelessly introduced when there is an obvious alternative that is simpler and more performant. Yes, abstractions have a cost that will accumulate as they are layered. But simple elegant solutions are not free. They are hard to come with, so they often need large amount of dedication ahead of any coding. And as long as we don't deliver anything…

But don't forget that the territory will change underneath your feet. This is especially true if you write business software. A tectonic shift in the business can make the assumptions you made a year ago completely invalid.

This is complicated further by the fact that good software will drive the business. So you will always be creating new problems because you're driving the business into new areas and capabilities that simply weren't possible before.

So this makes it doubly important to make sure your software can change in small ways over time. It's not just trying to navigate the moors at night with a torch, it's like trying to navigate the desert at night with a torch. The sand will move under your feet.

Re: That's not an abstraction, that's a layer of indirection

#95

Post by antfarm »

voidhorse wrote: post #43

The best way to achieve a good abstraction is to recall what the word meant before computer science: namely, something closer to generalization . In computing, we emphasize the communicational (i.e. interface) aspects of our code, and, in this respect, tend to focus on an "abstraction"'s role in hiding information. But a good abstraction does more than simply hide detail, it generalizes particulars into a new kind of…

The best abstractions I've seen have always come into being only after a significant amount of particularized code had already been written. It is only then that you can identify the actual common properties and patterns of use.

Early Ruby On Rails comes to mind as a great generalization of web applications in the era of Web 2.0.

Re: That's not an abstraction, that's a layer of indirection

#98

Post by zelphirkalt »

astrobe_ wrote: post #79
voidhorse wrote: post #43

The best way to achieve a good abstraction is to recall what the word meant before computer science: namely, something closer to generalization . In computing, we emphasize the communicational (i.e. interface) aspects of our code, and, in this respect, tend to focus on an "abstraction"'s role in hiding information. But a good abstraction does more than simply hide detail, it generalizes particulars into a new kind of…

Yes, abstraction and generalization are properties you'd rather look for the second time around . Someone was already warning about this 25 years ago [1]: You have a boring problem and hiding behind it is a much more interesting problem. So you code the more interesting problem and the one you've got is a subset of it and it falls out trivial. But of course you wrote ten times as much code as you needed to solve the…

Although of course solving the abstract problem does not have to be 10 times as much code. The best solutions are often those, that recognize the more general problem, solve it with little and elegant code, then turn to the specific problem, expressing it in terms of the abstract problem and thereby solving it in just a few lines of code. Such an approach should usually be accompanied by some documentation.

To give a trivial example: Binary search or any other bog standard algorithm. You would want to have an implementation for the algorithm and named as such and then only apply it in the specific case you have. Sorting algorithms. You don't want to rewrite it all the time. Actually rewriting it all the time would be the thing that creates "10 times" the code.

Re: That's not an abstraction, that's a layer of indirection

#99

Post by scotty79 »

noduerme wrote: post #25

I got a piece of advice writing UI code a long time ago: Don't marry your display code to your business logic. I'd like to say this has served me well. It's the reason I never went for JSX or other frameworks that put logical code into templates or things like that. That is one abstraction I found unhelpful. However, I've come around to not taking that advice as literally as I used to. Looking back over 25 years of c…

I started with a templating system that had a very limited logic and I'm still quite fond of this approach.

Basically arguments for a template had a form of a tree prepared by the controller function. The template could only display values from the tree (possibly processed by some library function, for example date formatter), hide or show fragments of html dependaning on the presence or absence of some value or branch in the tree, descend into a branch of a tree and iterate over an array from the tree, while descending into one iteration at a time. Also could include subtemplate feeding it a branch of the tree. This was enough to build any UI out of components and kept their html simple, separate and 100% html. Even the template logic had a form of html comments. One could open such template in any html editor including visual ones. It was all before advent of client side frameworks.

You could mimic this in React by preparing all data in render method as a jsonlike tree before outputting any JSX tag and limit yourself inside JSX part to just if and map(it =>{}) and single value {}

Post reply on HN