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

111–120 of 240 posts

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

#111

Post by bruce511 »

javcasas wrote: post #76
bruce511 wrote: post #14

Earlier quoted context omitted.

>> but the core benefit is that the same code should work on multiple different hardware devices. I came here to say this. Attractions act as a bridge between things which allow those things to change independently. Using an ORM allows my program to easily work against multiple sql databases. Using a compiler allows me to target different hardware. Using standard protocols allows me to communicate with different prog…

> allows my program to easily work against multiple sql databases How many times have you required that your program runs against different sql databases without modification? I mean, how many times have you required your plane to be able to fly in the different atmospheres of different planets of the Solar System? Unless you are NASA, I suggest you cut the complexity and just make a plane that can fly well on Earth'…

>> How many times have you required that your program runs against different sql databases without modification?

Our main commercial product currently supports 2 database engines, and we'll be offering a 3rd next year. For enterprise offerings it's pretty common for the client to prefer, or outright specify, the engine.

Commodotizing your complementary technology is a good way to not become dependent on any specific database, and hence can pivot quickly when required.

Fortunately I don't have a plane, so I don't have code to fly in any atmosphere.

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

#112

Post by noduerme »

ramblerman wrote: post #107
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…

> Don't marry your display code to your business logic. > It's the reason I never went for JSX or other frameworks that put logical code into templates or things like that That's not mixing business logic with display code, your confusing (or conflating) 2 entirely different things here.

I don't think I'm conflating things. Any time you insert sugar into your HTML that makes your end user see output that's been inserted by how your framework interprets that sugar, you may be binding your business logic to your display code. Possibly in subtle ways you don't realize until later. A common case is rounding decimals to a user that aren't rounded in the system.

Letting any control flow into your HTMX/JSX templates is begging for trouble. It boggles the mind that people abandoned PHP - where at least the output was static and checkable - for something exactly like mixed HTML/code where some processing was done on the front end and everything was supposed to be dehydrated. Only to pivot again to hydration on the back-end.

JSX and React came on the scene 10 years after I first realized using the client for anything logical was an anti-pattern. Back then, I remember people would write things like:

CustomerFormForClientX extends CustomerFormForClientZ [...]

and put a bunch of validation on the client side, too. Clients are dumb terminals. That's it. I'm not confusing the use of logic-in-JSX with business-logic-in-display. One only has to look at every basic JSX example on the web that's taught to newbies to see a million ways it can go wrong.

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

#114

Post by mrcsd »

scotty79 wrote: post #108
mrcsd wrote: post #102

Earlier quoted context omitted.

Funnily enough, logical deductions or formal theorem proofs can be seen as a set of transformative steps from the initial premises to the conclusion, where no new information is added in the process. Which makes the conclusion (at a stretch) a bit like "just" rephrasing the initial premises.

Not really. Usually during the deduction you have some steps that pull surprising knowledge from the rest of math to support the reasoning or create and prove interesting lemmas. If you can prove a theorem without any of that, that's a little boring theorem to prove.

I agree with the spirit of your comment, but not the literal fact of it. Sure, interesting proofs require pulling out some interesting knowledge in the reasoning, but notions like "surprising" or "interesting" are about human subjectivity and don't really exist as a property of a deduction. Surprising or interesting knowledge is not somehow new knowledge that wasn't there before, it's just that we didn't see it previously.

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

#115

Post by noduerme »

scotty79 wrote: post #99
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 bran…

Yeah. I did this too. Mine's driven off a database with a structure of

1. pages, each of which may or may not have a parent pageID; the entire tree is read and parsed to generate the menu system and links/sub-links

2. modules which reference HTML templates to load through a parser that replaces areas with {{handlebar}} variables written by the clients through their own API

3. something like page_modules which locate the modules on the page,

4. a renderer which uses the above stuff to make the menu system, figure out what URL people are trying to get to, load the page, load the modules in the page, and fill in the crap the client wrote inside the {{handlebars}}

This has worked so well for so long that I can basically spin up a website in 15 minutes for a new client, let them fill in anything I want them to by themselves, throw some art on it and call it a day.

It worked so well that I ended up writing a newer version that uses a bunch of Javascript to accomplish basically the same thing with smoother transitions in a single-page app that doesn't look or act like an SPA, but it was basically pointless.

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

#116

Post by mrkeen »

noodletheworld wrote: post #48

Pretty easy to give generic advice without examples. “Write more tests, but not too many” “Use good abstractions where appropriate?” “The next time you reach for an abstraction, ask yourself: Is this truly simplifying the system? Or is it just another layer of indirection?” It’s easy to create a strawman here (the FactoryAdaptorMapper or whatever) but in reality this kind of generic advice doesn’t help anyone. Of cou…

It might not give enough examples to show you how to do something right, but I think it's enough to warn against doing something wrong, namely introducing an indirection that doesn't provide any of the benefits of abstraction.

My colleagues invariably refer to indirections as abstractions, and it's a frustrating sort of name-squatting, because you can't usefully discuss the tradeoffs of abstractions if they're actually talking about indirections.

That said, the article does drop the ball by seeming to use the terms interchangeably.

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

#118

Post by mrkeen »

mightyham wrote: post #6

I forget which programming talk I watched which pointed this out, but one extremely common example of this in Java is recreating subsets of the Collections API. I've done this before, heck even the Java standard library is guilty of this problem. When a class has a full set of get/put/has/remove methods, it is often not actually hiding the complexity of its component data structures.

Good example of a bad abstraction. If you're speaking the language (or "abstraction") of sets, you should see certain terminology: union, intersection, disjunction. These words are not part of the Java Set interface.

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

#119

Post by xtracto »

mattmanser wrote: post #104
zelphirkalt wrote: post #98

Earlier quoted context omitted.

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…

No. Just no. This is the exact thought process that leads to unnecessary abstraction. This is the attitude that the article is criticizing. A good rule of thumb is never abstract unless you genuinely have done the same thing twice already. i.e. only write an abstraction after you've written the boring, simple, concrete, implementation twice and are about to write it a third time.

I am wondering where the "generalize code after doing it for the 3rd time" rule of thumb comes from? I also subscribe to it, and read it somewhere 15/20 years ago.

Was it the Mythical Man Month book Maybe?

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

#120

Post by xtracto »

themadsens wrote: post #91
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.

Smells like Ruby to me haha. I know is not the language, but for some reason the ruby code I've stumbled into are all like that.
Post reply on HN