>>888920
>I wouldn't pay even a dollar more for the extra silicon needed to implement that bloat. Especially when you consider the inevitable increase in power consumption.
You would end up saving money, silicon, power, and memory. We're already paying more for x86 bloat and wasted silicon than any extra silicon that would come from a Lisp machine.
https://people.eecs.berkeley.edu/~kubitron/cs252/handouts/papers/symbolics.pdf
>Hardware can process the tag in parallel with other hardware that processes the rest of a word. This makes it possible to optimize safety and speed simultaneously.
>Automatic storage management is simple, efficient, and reliable. It can be assisted by hardware, since the data structures it deals with are simple and independent of context.
>Data use less storage due to compact representations. Programs use less storage due to generic instructions and because tag checking is done in hardware, not software.
>>more efficient and more productive
>Cool buzzwords. Are you some sort of corporate manager?
No, but it is more efficient and more productive. UNIX "academic" handouts use those buzzwords too.
http://cosm.sfasu.edu/gharber/353/notes/Unix_philosophy.pdf
>Thompson and Richie's innovation was that speed can be traded off against utility and portability. Their reasoning was that it didn't matter if the machine performed somewhat slowly, if it could offer portability and productivity tools to offset the loss of efficiency.
>UNIX exploded the notion that machine efficiency was more important than human productivity.
While it's true that UNIX is slow, it's also not productive because of C.
>>W and X look like Y, and Y is associated with Z, therefore hating W and X means hating Z
W and X suck because of Y and Z.
> There's nothing wrong with C as it was originally
> designed,
> ...
bullshite.
Since when is it acceptable for a language to incorporate
two entirely diverse concepts such as setf and cadr into the
same operator (=), the sole semantic distinction being that
if you mean cadr and not setf, you have to bracket your
variable with the characters that are used to represent
swearing in cartoons? Or do you have to do that if you mean
setf, not cadr? Sigh.
Wouldn't hurt to have an error handling hook, real memory
allocation (and garbage collection) routines, real data
types with machine independent sizes (and string data types
that don't barf if you have a NUL in them), reasonable
equality testing for all types of variables without having
to call some heinous library routine like strncmp,
and... and... and... Sheesh.
I've always loved the "elevator controller" paradigm,
because C is well suited to programming embedded controllers
and not much else. Not that I'd knowingly risk my life in
an elevator that was controlled by a program written in C,
mind you...