python was: transputers again was: The dissolution of Commodore 2924

Well, RISC was about increasing speed by making it easier to optimize the CPU. You pay the price of more instructions, but hopefully gain by processing them far faster.

Not quite the same issue.

What I find interesting is that Intel and AMD CPUs have long since ceased to be CISC CPUs. They are all RISC cores, emulating x86 instructions and operations.

I would think that MIPS would be a good choice too.

Both MIPS and 68K are elegant enough that they can be a lot of fun, and teach you a lot about what goes on underneath modern development platforms like Perl, Java, Python, etc.

If you start out using an interpreter, or a high level compiler, you have skipped many levels of abstraction and it only makes it harder to learn later.

I've actually bought myself a book on MIPS buttembly, and plan to learn it just because it has been so long since I needed to know buttembly.

I might not use it, but I expect it to help me keep the right stuff in my head.

In fact, I'm trying to go back to foundations all around as I find time.

Even "old" ones... Java, for example, has tons of problems:

- library bugs - violations of the principle of least surprise - tons of gotaches and but-ifs

To me, it is almost as hard to program in Java as it is to be discplined enough to write clean and portable C.

Ruby looks interesting, but like most scripted OO, you pay a heavy price for it.

As long as it is within their environment, they might be fine. Java, Perl, Ruby, Python... they all have at least minimal debuggers, and some very good add-on debugging systems.

But it is hard to get people to use them.

Some environments are a little too forgiving, hiding problems until they really blow up.

Just look at the warnings and strictness options in most languages, and how infrequently they get used.

-- shannon "AT" widomaker.com -- "Castles are sacked in war, Chieftains are scattered far, Truth is a fixed star, Eileen aroon!" -- Gerald Griffin