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

231–240 of 240 posts

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

#231

Post by astrobe_ »

JadeNB wrote: post #175
astrobe_ wrote: post #82

Earlier quoted context omitted.

You are confusing too many things. "10" is the representation of a data; "0xA" is another representation of the same data. Not being able to touch something doesn't make it an abstraction. Light is not an abstraction, a contract is not an abstraction. 10 is not an abstraction, it is an ordinal [1]. "Isomorphism" is an abstraction. It doesn't name a particular data or value, but a class of functions that share common…

> Light is not an abstraction, a contract is not an abstraction. 10 is not an abstraction, it is an ordinal [1]. It seems to me that all of those things very much are abstractions. They are not the utmost level of abstraction, but they are abstractions! (Actually "a contract," which at first I thought was the clearest win, I'm now not sure about. On reflection, it seems like a concretization, turning abstract ideas o…

All right, light is an abstraction, contracts are abstractions, 10 is an abstraction, time is an abstraction, and I am an abstraction too.

The notion is so fuzzy that everything can be an abstraction in a certain way. The word "abstraction" is a black hole for thoughts. Stay away from it.

For instance in this threads and in TFA, people made useful distinctions such as "generalization" or "indirection".

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

#232

Post by astrobe_ »

Sesse__ wrote: post #142
astrobe_ wrote: post #79

Earlier quoted context omitted.

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…

Have you ever looked at how useless Chuck Moore's stuff is? Like, the chip designs are of the type “384 independent Forth chips with tiny amounts of RAM and mediocre interconnects, and if you want to actually do anything with them, you'll need to use 128 of them to program your own DDR3 controller”. Or, he demonstrates how awesome Forth is by showing that you can do “the guts of a disk driver” in five lines, except t…

> Have you ever looked at how useless Chuck Moore's stuff is?

I've seen someone well known in the Forth community say something like that to Chuck. I think he said "what can I do with that?"

If GA144 is useless, it's only because it has not been put to good use, in my opinion. I think it was more-or-less his answer too, IIRC.

I work with system-on-chip or system-on-modules. You know, the ARM-based chips with tons of peripherals. I also worked with similar chips before the ARM era.

The complexity of these chips is as of today, absurd. I/O is multiplexed to make the chip usable for various things, but one has to configure all of them and watch out for conflicts. Then there's also zillions of configurable clocks in order to reduce the power consumption. Solutions to problems that spawn new problems, not in the "divide and conquer" style, unfortunately. This resulted in "device tree" configuration in Linux, a runtime configuration system, because CPU companies excrete a new variant every week.

Maybe I fool myself, but I can see a GA144 bit-banging IRDA, LCD, SPI, etc. in a much more efficient and flexible way.

> (2010) is a fairly interesting experience from someone on the outside trying to work in the same way. It… didn't work that well.

And here in 2025 there's still Forth-based companies alive, like MPE or Forth, Inc.

More specifically, this author writes,

[...] it was harder than we thought. Presumably that was partly the result of not reading "Stack Computers: the new wave", and not studying the chip designs of Forth's creator Chuck Moore, either. I have a feeling that knowledgable people would have sneered at this machine: it was trivial to compile Forth to it, but at the cost of complicating the hardware.

Implementing a stack-based processor without reading the literature on them is a bit foolish, don't you think? The rest is in the same vein; I can see why a person who was essentially a Forth newbie had a bad experience with this kind of project. If this article "debunks" Forth, it is by showing that just because something it is simple, doesn't mean it is easy. Because the world is not simple and simplifying is much harder than let Complexity loose.

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

#233

Post by astrobe_ »

Sesse__ wrote: post #215
samatman wrote: post #201

Earlier quoted context omitted.

Useless? Like the RTX2000 which landed on a comet kind of useless? Or do you mean some other kind of useless. Maybe the controlling radio telescopes kind of useless. That must be it.

> Like the RTX2000 which landed on a comet kind of useless? Yeah, in 1983 he designed a chip that was further developed by others for space usage. > Maybe the controlling radio telescopes kind of useless. Yeah, which he did in 1970. Note a pattern here? That this design paradigm holds up pretty well in a primitive computing world when things are simple and demands are low, and is thoroughly useless to keep on promoti…

> Yeah, which he did in 1970.

Yes, and Forth has been maintaining somehow its ties with aerospace for over 50 years: https://www.forth.com/resources/forth-apps

> That this design paradigm holds up pretty well in a primitive computing world when things are simple and demands are low, and is thoroughly useless to keep on promoting today?

Apparently some people are still interested in it: https://www.mpeforth.com/news-gossip-and-rumour/

Did you know that desktops, servers and smartphones together is a tiny fraction of the total number of processors running in the world?

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

#234

Post by Sesse__ »

astrobe_ wrote: post #233
Sesse__ wrote: post #215

Earlier quoted context omitted.

> Like the RTX2000 which landed on a comet kind of useless? Yeah, in 1983 he designed a chip that was further developed by others for space usage. > Maybe the controlling radio telescopes kind of useless. Yeah, which he did in 1970. Note a pattern here? That this design paradigm holds up pretty well in a primitive computing world when things are simple and demands are low, and is thoroughly useless to keep on promoti…

> Yeah, which he did in 1970. Yes, and Forth has been maintaining somehow its ties with aerospace for over 50 years: https://www.forth.com/resources/forth-apps > That this design paradigm holds up pretty well in a primitive computing world when things are simple and demands are low, and is thoroughly useless to keep on promoting today? Apparently some people are still interested in it: https://www.mpeforth.com/news-g…

> Yes, and Forth has been maintaining somehow its ties with aerospace for over 50 years: https://www.forth.com/resources/forth-apps

Somehow all of those projects are… really old? A satellite control UI on top of Windows 7 from 2015 (somehow Chuck Moore's assertion that “If they are starting from the OS they have made the first mistake” did not extend to Windows here). A STM-16 (2 Mbit/sec!) multiplexer, very modern. A power plant control system from 1995. And yes, an aerospace project indeed, also from 1995. Notably none of these are using his CAD software, much less using any of his chips.

> Apparently some people are still interested in it: https://www.mpeforth.com/news-gossip-and-rumour/

I'm sure they are? There are people interested in all sorts of things. (Well, at least some of them were in 2022, which is the last time someone bothered to add a news post.) That doesn't mean it is a useful design paradigm for the world at large. Remember, Chuck Moore's claim is that not following his ways means 10x the bugs, cost, etc. -- I don't really see anything supporting that claim.

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

#235

Post by Ma8ee »

swed420 wrote: post #160
cpeterso wrote: post #15

Earlier quoted context omitted.

“The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.” — Edsger Dijkstra But sometimes a new semantic level isn’t needed. Abstraction gets so much press when you might just need some good ol’ fashioned information hiding and separation of concerns.

It seems like almost everybody in these comments as well as OP are failing to differentiate between the narrow computer science / Dijkstra definition of abstraction versus how it's invoked colloquially, including in conversations of computer science such as here. In that sense, we can correctly say that even encapsulation etc is a form of (colloquial) abstraction, but not Dijkstra's use of the word abstraction.

Maybe that’s the problem. Everyone knows that abstractions are desirable, and encapsulates as much as they can, and ends up with redirection hell without any of the advantages of true abstractions. If people understood what the word actually means, we might not be in this mess.

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

#236

Post by Ma8ee »

marcosdumay wrote: post #182
cpeterso wrote: post #15

Earlier quoted context omitted.

“The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.” — Edsger Dijkstra But sometimes a new semantic level isn’t needed. Abstraction gets so much press when you might just need some good ol’ fashioned information hiding and separation of concerns.

Yeah... That's also an unachievable ideal. On practice, there exist platonic abstractions that hide mechanisms and can be this way, but you also need to abstract parts of your requirements. And you will never be able to achieve that while abstracting your requirements. Dijkstra was an academic after all, and academics usually don't care about complex requirements.

No, your abstractions are there to make your requirements easy to express in code. It’s where businesses language and technical implementations meet.

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

#237

Post by ciwchris »

I can't help but wonder whether the problem is subjective, to each person and what they need to accomplish at the time. What is cognitive load and indirection to one at one time is a simple abstraction to another at another time.

And so I wonder if a solution to this is for editors to be able to represent the code differently, depending on what the person's needs are at the time.

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

#238

Post by 9rx »

necovek wrote: post #190
9rx wrote: post #189

Earlier quoted context omitted.

> I’ve never seen an ORM used in the wild where you could actually avoid thinking about tables and columns and rows pretty frequently. There is a compelling argument that absent the n+1 problem, it could be a leak-free abstraction. And, in practice, SQLite doesn't suffer from the n+1 problem... But that is definitely true in a lot of cases, particularly where the n+1 problem is unavoidable. > If it’s a one-off you’re…

But SQL is "naturally composable" using string concatenation. I've seen one too many of tables = ["order", "product"] join_on = ["order.product_id = product.id"] filters = [] as the base of the query, with all of these being concatenated together. But instead of this, an ORM usually provides you with a syntax (that will pass syntax checks and have highlighting) that matches the language, which is all nice and good be…

> But SQL is "naturally composable" using string concatenation.

It is not. Not even in a simple case. Consider:

    base = "SELECT * FROM table LIMIT 10"
    cond1 = "WHERE foo = 1"
    cond2 = "WHERE bar = 2"
base + cond1 + cond2 or any similar combination will not produce a valid query. It could if SQL had some thought put into it. There are many languages that have no problem with such things. But that irrational fear of moving beyond the 1970s when it comes to SQL...

The only realistic way to assemble queries is to prepare an AST-like structure to figure out where the pieces fit, and then write that out to a final query string. In practice, that means either first parsing the partial queries into that structure (hard) or providing a somewhat SQL looking API in the host language that builds the structure (easy). Unsurprisingly, most people choose what is easy.

> I am sure neither of those "invented" the pattern.

None of these invented the pattern. But the invention point is irrelevant anyway. You must have misread something?

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

#239

Post by Voultapher »

ordu wrote: post #109
Voultapher wrote: post #92

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

It is funnily recursive... I'll try to explain, but I'm not sure my English is good enough for that task. But lets try. When the author says "great abstraction" they mean "ideal abstraction". You can see this for example in this quote: " The less often you need to break the illusion, the better the abstraction." They say even the phrase "all abstractions leak", which is the main point of yours. So, if they mean an "i…

Hey, thanks for sharing and trying to express it even if it's not your primary language - it isn't for me either - it gave me a new insight.
Post reply on HN