CPU Wars

msolnik writes: "Whether you say "0.13-micron" as most of us do, or "130-nanometer" as PR flacks prefer, the phrase is weighing heavily on both Intel's and AMD's minds. Indeed, each company's timeline in reaching that mark may determine who calls the CPU shots in 2002. Read more here at Hardware Central." Other submitters noted that AMD and Motorola have both updated their development roadmaps.

Comments

Could faster processors lead to better programs?

[entrox]

I'm looking forward to ever-increasing clockspeeds, as this could get us away from programming applications in a low-level language like C/C++. Let's face it: Most of the bugs in current programs stem from the fact that C was not designed to handle sloppy or lazy coding. Dangling pointers, buffer overflows, memory leaks etc. result from the low-levelness of C (that's OK - for it to be efficient it needs to have the ability to do all kinds of things with the hardware directly). C should only be used for developing operating system kernels and device drivers, as no other higher language would handle the task well.

Faster processors and more memory would make higher languages such as Lisp or Python viable for applications (such as Browsers, Desktop environments etc.), which in turn would result in less bugs and increased stability when applied correctly. The current state with software makes me sick. I don't blame it on C per se, but on programmers using the wrong tool for the wrong job.

Writing in such a higher language would probably even increase portability (which C can't fulfill by a far shot) as you would program at a higher abstraction level. No need for autoconf/automake or ugly defines scattered throughout the code, making maintainance more difficult.

I hope that more coders switch to some better suited language than C/C++ for application development. I've switched to Lisp myself.