Keith Bierman's Weblog

Halting problem is easy; Starting problem is hard! Every Computer Scientist learns that Halting is hard (undeciable). But any decent Computer Engineer ought to know that Halting is easy. You can cause any computing system to halt by removing external power. Removing all internal energy storage. And then smashing every computing element back to dust. It's expensive. It may be dangerous (I imagine that the Earth SImulator has a tremendous amount of stored energy ... just using a crowbar could be hazardous to the weilder (note; the cited article seems a bit confused. The ES vector orientation is a return to the tried and true, not a new direction)

What is really hard is the Starting problem. The starting problem is getting an entirely new thing off the ground (this infamous book) outlines the problem in general.

In the area of computer architecture, it's creating a new ISA and the "ecosystem" that surrounds it. Many are started, fewer get off the ground, and few really last. Mashey comments are, as one would expect, worth a read.

But if you don't want to wade through a technical tutorial on the pitfalls, just observe the Intel IA64. It has a lot of good things going for it. Billions of dollars of investment. The support of big systems vendors. A variety of really good ideas (OK, having worked at Cydrome I might be biased) and implemented by a large, well funded team with some of the worlds finest fabs behind them. How hard could it be?

Very, as various journalists claim:

1. The Register and The Register2
   
2. eweek
3. LinuxInsider
4. Many more (Google or GigaBlast are your friends)

Will IA64 thrive in the end? I think that those that count it out may be premature. But it's certainly been a much slower, more painful process than MIPS or SPARC experienced. Timing isn't everything, but it comes close.
(2004-06-24 21:37:08.0) Permalink Comments [2]

Still looking back... Most people think that there is no more Cobol  or for that matter Univacs (true, the name has been changed to "ClearPath" and Unisys) but some old architectures persist, and more interestingly (perhaps) software (which is fundamentally more malleable) often outlives the Iron.

Fortran continues for many of the same reasons (albeit in a different environment) that the article puts forward for Cobol.

Computer Scientists talk about code reuse (and design new languages and frameworks to accomplish it). Cobol and Fortran programmers aren't "that smart" they just reuse code forever :>

(2004-06-24 17:44:16.0) Permalink

Another early computer pioneer departs.... He left us a web site.

I particularly enjoyed the "Father of ASCII" writeup
(2004-06-24 15:27:59.0) Permalink