> > Code breakage in the year 2000 will probably be nothing compared to a
 > > change to 32-bits as the basic sizeof(int).

 > It will be some time before we see sizeof(int) > 4 on a
 > regular basis.

It'll happen sooner than you think.

It is, for example, quite possible, even very probable, that Intel's next
chip to succeed the P6Pro will be 64bit, and still retain backwards
compatibility with 32-bit and 16-bit modes. And, in market terms, will be
produced and sold at less relative cost than the first available 32-bit
intel chips.

Not to mention, of course, the already existing DEC and Apple boxes with
64-bit technology. Intel's competitors haven't been idle.


 > By that time it may well be less relevant
 > to the majority of computer programmers than it is today
 > as system-independant languages such as Java (and
 > languages yet to be formed) become more prevalent.

Java and suchlike still require the basic operating system, support, and of
course the interpreters themselves.


 > 64-bits.  There is plenty of life left in the 32-bit
 > world; mainstream PC users (notably those of the Wintel
 > variety) are only beginning to reap the benefits of
 > 32-bit programming.

Of course, they only "started to reap the benefits of 16 bit
programming" when the 386 was released. It is the nature of the
industry - users consist of a wide strata of systems. "Bitness",
and all the portability issues that go along with it, have direct relevence
to the life of software. Certainly the "death" of a particular
item may not be as specific as 31st December, 1999, but I don't at all
doubt that the vast majority of software we use now will be replaced or
succeeded within the next 4 years and therefore has a lifespan of even
less.

The *real* benefits of 64-bit technology isn't in the same arena as 32-bit
though. With memory becoming increasingly cheap, mass storage devices
becoming larger in sizeable increments, the ability to (quickly) handle
64-bits as an item becomes important, especially now with the PCI bus
becoming the norm on intel platforms.


 > Teachers and students of computer programming in general
 > still have a lot to learn regarding the importance of
 > portability.  I guess it's a bit like First Aid, you may
 > never use it, but it could well save your life.  :-)

Agreed. And I think it is even more important to understand the *underlying
issues* than it is to actually write portable code. Porting from one
environment to the other isn't all that difficult unless you're getting
your hands dirty with assembler - but knowing the dependancies is a
requirement before you even contemplate the port itself.


 > In the long term portability at a software level will
 > probably become a non-issue, especially once 64-bit
 > systems become well established.  I am thinking a few
 > decades from now though.

You'd better start thinking in terms of a couple of years. :-)

In intel terms, 32-bit technology is only just over 7 years old. It was
held down a lot by 16-bit real mode operating systems and dependancies,
else it would have advanced a lot faster. That, and MS/IBM's sticking to
what was in retrospect an unwise promise in producing a protected mode
semi-dos compatible operating system for the dead-end 80286 platform (OS/2
1.x).

16-bits lasted 5 years before its successor arrived, and is still used
commonly. 32-bits will be in use quite a while yet too, but anything *new*
will be implemented first on the best hardware alternative.


 > Much of the portability issues
 > may well be solved at the hardware level than in
 > software.  It seems like the logical place to me.  With
 > any luck it should allow programmers to get on with more
 > productive tasks, and not have them worry about the
 > inevitable change in hardware.

I'm not sure what particular problems you see that hardware should solve
for you. Do you mean having your machine run in a crippled environment that
has the "native" size of int looking 32-bit only? Sort of like
running 16-bit MSDOS on a perfectly good 32-bit 386? :-)

No, that doesn't solve any problems. It just prolongs the time when they
have to be solved.

And it is writing *portable code* in the first place that frees a
programmer from having to worry about hardware issues. There should not
need to be any hardware crouch to solve those portability issues - that's
what an abstract programming language like C is for. If you have a care for
it, then you can solve your future problems now.

I also disagree in the main with the assertion that (use of language)
portable == slow. That is true only when (a) you're writing assembler, and
especially (b) you're relying on brute force rather than making use of the
plethora of programming algorithms that can be implemented in almost any
language, on any platform.

--- MaltEd/2 1.0.b6