Shards of Lost Technology, and the Need for High-Level Architectures | Hacker News Reader

Shards of Lost Technology, and the Need for High-Level Architectures

loper-os.org

34 pointsgchpaco12 comments

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.

> 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...

Have you checked out Newspeak?

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...

> 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.

> 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.

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).

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.

> 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.

"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. ;-)

> 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.

Not to mention the amount of momentum in these systems.

The x86 architecture is hideous. But Intel and AMD have pumped billions of dollars of research into it that is difficult to overcome.

Look at Apple's transition from the PPC to x86. The reason given was performance/watt. Do you think Jobs spent more than a minute worrying about how annoying x86s are to work with?

Reply on news.ycombinator.com