>>894133
>15 or 20 years ago people were super excited about new shit, both hardware and software. New shit meant significant new improvements. Nowadays new shit means even shittier shit and/or even moar botnet that datamines you as much as it can.
The only changes today are hardware getting faster slower and software getting slower faster. Everything gets more bloated and does less at the same time. Bloat is the opposite of features. Features eliminate bloat. Standard hash tables or trees eliminate the bloat from every program needing a map data structure. On UNIX, every interpreter has its own kind of map for environments and associative arrays, but they're not compatible and can't be shared, and most of them are inefficient. It's better to have built-in implementations that work and are debugged and fast. This doesn't stop anyone from making their own version, but there would be no point unless it's better, and then you can add your better version to the OS, to improve every program.
>Where did it all go wrong?
C and UNIX. Combining different languages used to be a goal of operating systems like Multics and VMS, which have data descriptors so you can pass data between programs without losing the types, but UNIX doesn't work that way. You have to convert everything into the limited types used by C with an FFI. C is a "foreign" language that sucks, but it must be used because you have no other choice. You can't share data types like hash tables, bignums, and strings. You should be able to use libraries written in different languages without writing the whole project in that language or pretending you're using C. There's the JVM and .net, but those are not on the OS level like the descriptors and the Lisp machines were.
https://en.wikipedia.org/wiki/Data_descriptor
>Was it even avoidable?
It's avoidable with a good operating system and new hardware.
Once one strips away the cryptology, the issue is control.
UNIX is an operating system that offers the promise of
ultimate user control (ie: no OS engineer's going to take
<feature> away from ME!), which was a good thing in its
infancy, less good now, where the idiom has caused huge
redundancies between software packages. How many B*Tree
packages do we NEED? I think that I learned factoring in
high school; and that certain file idioms are agreed to in
the industry as Good Ideas. So why not support certain
common denominators in the OS?
Just because you CAN do something in user programs does not
mean it's a terribly good idea to enforce it as policy. If
society ran the same way UNIX does, everyone who owned a car
would be forced to refine their own gasoline from barrels of
crude...
Yes, and they've succeeded. Hordes of grumpy C hackers
are complaining about C++ because it's too close to the
right thing. Sometimes the world can be a frightening
place.
I've been wondering about this. I fantasize sometimes
about building better programming environments. It seems
pretty clear that to be commercially viable at this point
you'd have to start with C or C++. A painful idea, but.
What really worries me is the impression that C hackers
might actively avoid anything that would raise their
productivity.
I don't quite understand this. My best guess is that
it's sort of another manifestation of the ``simple
implementation over all other considerations'' philosophy.
Namely, u-weenies have a fixed idea about how much they
should have to know in order to program: the amount they
know about C and unix. Any additional power would come at
the cost of having to learn something new. And they aren't
willing to make that investment in order to get greater
productivity later.
This certainly seems to be a lot of the resistance to
lisp machines. ``But it's got *all* *those* *manuals*!''
Yeah, but once you know that stuff you can program ten times
as fast. (Literally, I should think. I wish people would
do studies to quantify these things.) If you think of a
programming system as a long-term investment, it's worth
spending 30% of your time for a couple years learning new
stuff if it's going to give you an n-fold speed up later.