Hacker News Reader

Comment by auggierose | Hacker News Reader

I don't mind technical details. But the best way to tackle technical details is to build the right abstractions. And the best way to build the right abstractions is to be aware of the technical details.

View on HN

There are no "right abstractions". There are tradeoffs with advantages and disadvantages. Your preferred abstractions are by no means the "right" ones, especially since you don't even define what they are.

Of course there are right abstractions. And of course what the right abstraction is depends on the context, and takes into account the trade offs you are making. Any programming language is an abstraction, for example, and no programming language I am aware of is the right one out of the box except for very narrow and well-defined domains. That's why it is important that the language lets you build your own context-dependent abstractions.

And part of that context is your personal preference. Zig purposely chooses to prevent hidden control flow [1]. If operator overloading is a preference of yours, the language will get in your way. And that's fine. But it doesn't mean you can't build the "right abstraction" with it. These tradeoffs force you, for instance, to add an allocator to every type that needs dynamic allocation. For me that's great because it's evident which components need memory and I can make a conscious decision on what strategy to use with each one (or to avoid them entirely). For someone else, that might be a PITA. There is no "right" abstraction here.

1. https://ziglang.org/learn/overview/#small-simple-language

No, your personal preference is not part of the context. Unfortunately, too many programmers think that way.

If you don't like using abstractions, but if you like instead to make everything explicit, that is of course your prerogative. But denying that there is a right abstraction will just keep you from finding it. It doesn't change the fact that there often is one.

Going after the right abstraction takes time, and it might be just too expensive in your context, or your context may actually make abstraction infeasible. So in my opinion, it is all about trying to get into a position where experimenting with abstractions becomes cheap and economical. In principle, we should be in a much better position today in that respect than, say, 30 years ago.

But what makes an abstraction 'right'? I would say it's if it makes the program easier to make correct, or easier to write, or easier to understand, or easier to maintain, or ideally some combination of all of those. But easier for whom? Some programmers may have an easier time with more abstractions to provide guardrails and reduce redundancy; others may find it more effective to have everything laid out explicitly. And of course it's not just a question of more versus less abstraction; individual programmers often have specific abstractions and design patterns that they like to reuse in many contexts.

That's not quite the same thing as 'personal preference', where the right answer is by definition whatever I think is right. It's possible for me to think that XYZ abstraction or lack-of-abstraction works well for me, when in fact there's some other approach would that work better if I took the time to learn how it worked. Maybe I just haven't heard of that approach, or maybe I'm lazy or inexperienced or don't have the time to learn. People always think they're more unique than they really are; compare to the concept of "learning styles" which keeps being debunked.

But surely there is some legitimate variation.

Note then that there's an inherent conflict in programming language design space between introducing too many abstraction building tools and low-level details. It is very hard to make things truly orthogonal. E.g. memory and resource management tends to spill all over the code, with the other example being error handling.

And once a language designer adds ways (and a programmer culture) to hide things - it becomes very hard to follow the code.

Zig attacks this design space from a low abstraction and explicit flow point of view.

> Note then that there's an inherent conflict in programming language design space between introducing too many abstraction building tools and low-level details.

Best C++ code that deals with low level details is as least abstracted as possible.

One of the reasons C is used for writing operating systems kernels is that it doesn't hide details. Imagine Linux kernel written in OOP way with design patterns and SOLID principles. :)

> Imagine Linux kernel written in OOP way with design patterns and SOLID principles.

Doesn't sound that terrible to me.

Just out of interest, do you think `*(int*)(0x12345678) = 0;` is the best way to do memory-mapped IO? That's least abstracted.

Have you ever written low level code? There's constant hardcoded addresses you have to deal with which are in the spec. You can't really do BIOS, UEFI, Bootloder, Systems programming, ... without it. You wouldn't do a "magic number" and would make it a macro. But *SCREENBUFFER = 0;

Yes, my point being that the macro in this case is an "abstraction", and we were discussing GP's claim "all abstractions bad" (i.e., to quote them, low level code should be "as least abstracted as possible"). Was it really not clear what I meant?

I've actually encountered seasoned embedded devs advocating using the magic number in this very case. Never really understood why. It was some combination of "abstractions bad" and "I want to be able to check all adresses against my printed dead-tree documents while debugging "...

Of course noone really believes "all abstractions bad", but I wonder why some people still claim that.

C is used because of UNIX, it hides plenty of details.

Yes, I agree that there is this tension that no single "programming language" can resolve. That is why we don't need programming languages, but systems for building abstractions. But as long as we don't have those systems, I prefer programming languages that let me build proper abstractions.

Programming languages are systems for building abstractions. At least the proper ones.

> But the best way to tackle technical details is to build the right abstractions.

Wrong way (according to you): Compute factorial using AVX intrinsics

Best way (according to you): Make a factory class AbstractMathFormulaCalculatorBuilderFactory to instantiate a builder class AbstractMathFormulaCalculatorBuilder which can build an AbstractMathFormulaCalculator, from which you derive a FactorialCalculator in which you use an AbstractMathFormulaExecutor, built with an AbstractMathFormulaExecutorBuilder, generated by AbstractMathFormulaExecutorBuilderFactory.

Right way, according to him: Compute factorial using a function ComputeFactorial that uses AVX intrinsics.

Zig has functions/methods/procedures.

Then if your desired end state is a factorial, zig is the perfect language

Sorry, but the above is all according to you, not to me.

I don't demand abstractions everywhere.

From what I gather so far I don't think you know what an abstraction is, so it is prudent of you not to demand them everywhere.

Reply on news.ycombinator.com