🚀 go-pugleaf

In article <9602051241.AA26686@dxmint.cern.ch>, Dan Pop
<danpop@mail.cern.ch> wrote:

> For many applications, programming is a contract between the programmer
> and the programming language used.  The for(;;); example doesn't break this
> contract, it's a perfectly portable program.

Portable is not necessarily the same as well-behaved.

The following program is also portable across Unix systems:

while (1) {
   malloc(1000);
   fork();
};

yet, I wouldn't call it well-behaved.  Unless your process limits are set
ridiculously low, the above will have a noticeable effect on your system.

> It runs very well in
> multitasking systems (Unix, VMS, VM/CMS, etc), it monopolizes the cpu
> resources of non-multitasking systems (MSDOS, MacOS).

Yup, so what?  I'm waiting to find the piece of rocket science that you
someone don't believe that I understand.

> You're too stupid to understand that portable programs shouldn't care
> about the underlying operating system.

They have to, or they don't run well.  How bad is system-dependent.  I
still have to worry about word size, endianness, number of semaphores
available, maximum number of TCP connections available, maximum number of
characters allowed in a filename, maximum number of characters allowed in
a full path, etc.  You cannot escape worrying about the limitations
imposed by your system.

My above code fragment can run very well in a system with garbage
collection (at least with respect to swap space).  Why doesn't Unix have
garbage collection, if you really believe that the programmer shouldn't
have a care in the world about his environment

> Once you start stuffing your code
> with OS-specific calls, it is NOT portable any longer.

So what?  I'd rather have a useful program than a portable one.  Heck,
allegedly Unix is portable across platforms, yet all of the source code is
littered with #ifdefs around all the  system specific stuff.  There is
very little non-trivial portable code that doesn't have #ifdefs.

I don't like paying the price for portability.  Heck, gcc is one of the
most portable (across Unix systems) compilers out there.  It is also one
of the slowest.  Since I use compilers orders of magnitudes more often
than I port them, I'd rather have a fast one than a portable one.

> How often are the famous Byte benchmarks giving up time for other processes
> to run?

I don't know; I haven't looked at them.  Could you do better if you let
them all run to completion, context switching only when waiting on a
resource like I/O?
-- 
        Nevin ":-)" Liber       nevin@CS.Arizona.EDU    (520) 293-2799