18 Jun
2024
18 Jun
'24
12:39 p.m.
On 18 Jun 2024 15:55 +1000, from flexibeast(a)gmail.com (Alexis):
It used to be the case, not least before the widespread advent of
microcomputers (let's say between the late 1970s and mid-1980s), that
computing time was fairly expensive, and programmer time was fairly
cheap (both grossly relatively speaking). So it made sense to shift
the burden from the computer to the programmer where reasonable,
especially where the operation being automated would be performed many
times: the computer would need to do the work every time, whereas the
programmer only needed to do the corresponding work once.
Now computing time (as in the cost of completing a given operation;
say, adding two 64-bit integers, or storing a given number of bytes,
or even determining whether a given line of text appears in the output
of a command) is for all intents and purposes dirt cheap, while
programmer time is relatively expensive.
Hence programming-level abstractions which save programmer time, even
when those come at a performance cost.
The same argument can be made for memory cost.
It probably can also be made for system administrator time versus the
computing cost of making the sysadmin's job easier. It's also pretty
undeniably the case that there are many, many more sysadmins working
on many, many, many more systems than there are programmers working on
init systems and system state management services.
(Which is not to say that it those abstractions are only a good thing.
Hiding the complexity of what is actually going on opens up _its own_
set of pitfalls, both because it hides what's going on and because the
abstractions can only go so far; and all that performance cost does
eventually add up. If we wrote software for today's computers like we
wrote it for an early-1980s computer, it could probably be blazingly
fast; but could we reasonably write software at the level of today's
software complexity that way? The jury might not have arrived yet.)
--
Michael Kjörling 🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”
As a friend
told me, and it was an enlightening moment: you are keeping
the individual parts simple, but in doing so, you are moving the
complexity to the *interactions* between the parts, and are burdening
the user with that complexity. You are keeping the code simple, which
has undeniable maintainability benefits, but you are making the
administration more difficult, and the trade-off is not good enough for
a lot of users.
-- https://skarnet.org/lists/supervision/2586.html