TIP: Click on subject to list as thread! ANSI
echo: aust_c_here
to: John Gardeniers
from: David Nugent
date: 1996-10-13 02:44:20
subject: Portability v efficiency

> AF> Perhaps it's because C is meant to be portable, and to be portable it
 > AF> needs quite a degree of compatibility (ie a standard to be
 > AF> maintained). Assembly stuff is generally machine-specific. The odd
 > AF> piece of 6502 stuff I've written for the BBC would
 > AF> never work on a C64. Therefore it's not an issue.

 >     I think the devotion to an arbitrary standard, which is currently under
 > review anyway, is taken much too far by some programmers. The end result is
 > invariably fatware, which runs very slowly. Windows is a very good example.

A very good example of what?  :-)  Windows is in no manner or form portable
- it is highly PC specific in all respects. It isn't even an ISO C or even
a posix environment (special "main" declarations, specific
calling conventions and all that). It is about as far from portable as you
can get. Certainly any bloat in Windows has little to do with
"devotion to an arbitrary standard".

I also object to your use of the word "arbitrary". And of course
it is under review - all standards are, as a matter of course. They simply
do not change quickly, since doing so destabilises the market. Look at C++
if you want a good example of that, where vendors have had to release new
compiler versions every six months to keep up with it (and market pressure
is certainly starting to resist what was until only recently a very fast
moving target. C++ code written as recently as 1993 will not compile at all
with compilers that respect the current ANSI-C++ draft.


 >     Another thing I find somewhat interesting is the way some programmers
 > will argue in favour of standards (whatever they may currently be) and then
 > go ahead and write programs which can only be compiled by a specific make
 > and model of compiler.

I've never noticed a correlation between the two, but I have seen what
you're talking about. Some people simply enjoy being language lawyers. I do
too, at times. But a large part of what those people say is not so much to
enforce a specific style of programming, rather to "spread the
news" that a standard exists and that all programmers using a language
should be aware of it. I'm yet to see such a "language lawyer"
say that C does not allow non-portable code or provide some means of
stopping the programming making non-portable assumptions.

The standard was not invented in a vaccum - it combines both legacy aspects
of the C language and good software engineering practices and design.
Besides which, a compliant implementation will offer you a ready number of
functions which can, and should, be used. Most budding C programmers will
tend to reinvent the wheel unless they are more conversant with the
standard library. It's the nature of the beast.

In summary, I think it is a little silly to hold the language standard in
contempt. I fully agree that there are times when you need to make
non-portable assumptions not achieve whatever you are doing, but isn't it
better that you make such a decision consciously rather than pretend that
all computers in the word are 16-bit or have a specific word order? I'd
also be one of the first to encourage discussion about the standard, how
code does break it or can be made to conform to the standard. Nor need it
"cost" anything at all in the majority of cases. A program
written for portability is often worth doing, especially now when the real
usage of MSDOS is fast declining, and you way wish to take your programs to
other operating systems and platforms.


 >  BTW, using Basic it's always been very easy to port most programs from
 > one machine to another, yet it's not hogtied by any standards. Haven't we
 > all done such porting when we first learned Basic?

"Easy"? Which operating systems and which BASICs are we talking
about here? Perhaps you can explain why isn't BASIC being widely used for
development of software?

--- MaltEd/2 1.0.b6
* Origin: Unique Computing Pty Limited (3:632/348)
SEEN-BY: 50/99 620/243 623/630 632/103 107 348 360 633/371 634/388 396
SEEN-BY: 635/301 502 503 544 639/252 711/409 410 413 430 808 809 932 934
SEEN-BY: 712/515 713/888 714/906 800/1
@PATH: 632/348 635/503 50/99 711/808 934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.