
Shards of Lost Technology, and the Need for High-Level Architectures - gchpaco
http://www.loper-os.org/?p=46
======
stephenjudkins
_The foundations of the computing systems we use are built of ossified crud,
and this is a genuine crime against the human mind._

This guy has no good words for anything that anyone actually uses. Check out
his other posts. He attacks Clojure (it makes him "sick") and only praises is
Lisp in its purest incarnations and his own embryonic Loper OS.

I think it's clear that one of the fundamental principles driving successful
open-source software is a healthy respect for the real and the possible, as
well as a drive to solve real problems within a realistic timeframe.

If everything about using computers these days "sucks" and you insist on
attacking those, like Rich Hickey of Clojure fame, who put in hard work to
make it better, what's the point of being a hacker? It's a bit sad.

~~~
asciilifeform
> This guy has no good words for anything that anyone actually uses.

The Symbolics Lisp Machines had thousands of known installations. There are
still active users. Myself, for instance. Other enthusiasts. Certain U.S. Army
facilities, as well.

> a healthy respect for the real and the possible

You don't get to declare that a non-braindead OS and machine architecture are
unreal and impossible just because politicians defunded Symbolics (the
company's weakness was mainly choosing to live entirely off the Cold War pig
trough.)

What was built once could be built again.

> Rich Hickey of Clojure fame, who put in hard work to make it better

I have nothing against Hickey as a person. How he chooses to spend his time is
no business of mine. Yet I have no reason to thank him. He has created nothing
of value to me.

I am not attached to Lisp per se; rather, I am drawn to systems capable of
total reflection and introspection. Clojure offers neither. It disgusts me
because it has sold so many on the illusion that it has somehow rescued the
most worthwhile innovations of the Lisp world; on the contrary, it is
consigning them to oblivion ever more thoroughly, by feeding the widespread
misconception that anything which does not fit snugly into today's broken
environments is simply no great loss and ought not to be missed:

 _"We owe it to the losers in these little skirmishes to make sure that, if
nothing else, the good ideas are not lost along with the framework. And we do
not accomplish that by defining that there was nothing lost. That's both
callous to those who worked hard on these other things and short-sighted to
the future, which might one day care about the things that got lost."_

[http://groups.google.com/group/comp.lang.lisp/msg/b2c0190dc3...](http://groups.google.com/group/comp.lang.lisp/msg/b2c0190dc30c3e5f?hl=en)

~~~
MaysonL
Have you checked out Newspeak?

------
gvb
The "high-level architecture" is a specialized architecture. The problem with
a specialized architecture is that it is pitched as doing one thing really
well (e.g. execute lisp) but, by the time it is implemented, it is late to
market and slower than the "ossified crud" architectures. High level
architecture CPUs have been tried several times and have failed every time.
The article pines for one instance of a lisp engine and refers to several
more. A non-lisp example is the Intel iAPX 432
<http://en.wikipedia.org/wiki/Intel_iAPX_432>. Lots of people have created
Forth engines, but none is used widely
<http://www.ultratechnology.com/chips.htm>.

General purpose CPU architectures beat specialized architectures because they
are more flexible and are simpler. Flexibility means a broader market.
Simplicity means faster execution and fewer bugs ("errata") in the CPU itself,
where it is very difficult and expensive to fix.

Interestingly, the current CPU architectures seem to be the sweet spot: going
lower level with VLIW
<http://en.wikipedia.org/wiki/Very_long_instruction_word> has also been tried
repeatedly and failed repeatedly.

Specialization is for insects. - Robert A. Heinlein
[http://elise.com/quotes/a/heinlein_-
_specialization_is_for_i...](http://elise.com/quotes/a/heinlein_-
_specialization_is_for_insects.php)

~~~
asciilifeform
> Simplicity

Have you _seen_ the Intel/AMD CPU manuals?

> Specialization

The Symbolics Lisp Machines ran ZetaLisp, Common Lisp, Fortran, C, Pascal,
ADA... and you could write and interactively debug (on the source level) a
program written in any combination of these.

It is our current machines which suffer from insectoid specialization - _for
C._ Dynamic languages will always be second-class citizens (from speed &
complexity penalties) on the braindead C Architectures.

~~~
gvb
> Have you seen the Intel/AMD CPU manuals?

Yes. I've programmed the x86 architecture in assembly extensively, including
an embedded system BootROM, as well as various high level languages.

By simplicity, I'm referring to the simplicity of the instruction operations,
not the complexity of the architecture with its dearth of general purpose
registers and heavy use of special purpose registers. (Once you get into
expanded 32 bit and 64 bit modes, the register mess is somewhat better.) The
complexity of the x86 architecture was due to inheritance and expansion from
the 8080 architecture which drove the use of special purpose registers. It had
nothing to do with high level languages and definitely not C. The world has
wasted an incredible number of engineer-hours working around the limitations
of the x86 architecture.

The "designed for C" label on architectures is simply marketing-speak for "you
know how bad the x86 is, we are much better" without actually naming their
competition.

~~~
gchpaco
How is it you can possibly say "simplicity of the instruction operations" and
"programmed the x86 architecture in assembly extensively" with a straight
face? This is the architecture where the division operator dumps its dross in
one specific nominally general purpose register (my brain says CX but I could
believe one of the others).

------
j_baker
I think this is just a part of life in the technology world. There are lots of
things that should be better and could easily be made better if they wouldn't
totally break backwards compatibility and decades of professional expertise.

It's easy to say that the modern state of computing sucks, but it's a whole
lot harder to actually do something about it.

~~~
asciilifeform
> It's easy to say that the modern state of computing sucks, but it's a whole
> lot harder to actually do something about it

Many have told me that spewing hot air is pointless. However, it seems that
almost everyone in programming-culture is afflicted with a kind of Stockholm
Syndrome and refuses to believe that there has been any kind of systemic
decline. If I can cure even one such sufferer, the hot air will not be for
naught.

The best (or even sane!) technology does not automatically win, people.
Valuable things have been lost. Mankind is effectively stupider for the lack
of the intelligence-amplifiers which could have been - _could still be._

~~~
plinkplonk
"If I can cure even one such sufferer, the hot air will not be for naught."

You won't cure anyone by "hot air". At least you won't "cure" anyone half way
intelligent. Talk is cheap.

"[programmers] refuse to believe that there has been any kind of systemic
decline. Mankind is effectively stupider for the lack of the intelligence-
amplifiers which could have been - could still be."

So, code up these "intelligence amplifiers" and _show_ us. Talk is cheap. Code
is more convincing. It also gets over the problem of all these deluded
programmers (on HN and elsewhere) who "refuse to believe" something just
because you said so. ;-)

~~~
asciilifeform
> Talk is cheap.

Talk _is_ cheap. I do not specialize in talk, however. Compare my hot air
output to that of the professional blowhards and hucksters who are revered
here. I don't hold a candle to them, volume-wise.

And if the fact that I don't release to the peanut gallery every byte of
incremental progress I achieve means that I will be dismissed as a blowhard,
then so be it.

