Orchid XP v8 <voi### [at] devnull> wrote:
> I guess it works differently with a real OS. I've only ever compiled C 
> code under MS-DOS, and there you don't get "segfaults", you get "my 
> program does something really weird which may even require me to reboot 
> the whole PC to fix".

  So let me get this straight: You are comparing C in a 10+ years old MS-DOS
system to higher-level programming languages (such as Java and Haskell) in
modern systems with modern OSes and modern compilers, and based on this you
have decided that C sucks?

  (Don't get me wrong: C does suck. It's just that your comparison is not
completely fair.)

> >> Ditto for EOF
> > 
> >   You mean reaching the end of the file is such a fatal error, that the
> > program must be terminated with an exception?

> Well, it beats producing random garbage, surely?

  Since when has the EOF value been "random garbage"? In standard C the EOF
value is -1 (integer, not char), and a file read past the end of file will
always return -1. How is that "random garbage"?

  Besides, reaching the end of file (and getting that -1) is *not* an error.
It's a completely normal situation which all programs reading files have to
handle. How do you even detect the end of a file without a normal EOF
situation? If reaching the end of the file would cause a fatal error which
terminates the program, that would mean 90% of programs out there would not
work.

  Sure, some programming languages might have libraries or other systems
which signal the program the end of file in some other ways, but it's still
not an error to reach the end of the file.

> >> array index out of bounds
> > 
> >   Unless you use a proper debugger.

> I've never seen a C debugger.

  Thus you base all your prejudices on non-knowledge.

> Nor would I know where to find one. 

  Any decent compiler will have one.

> >> (And you don't have to memorise whether 0 is true or false.
> > 
> >   I see how that's such a hard thing to memorize.

> There are two possibilities which are apparently equally valid. It's 
> very difficult to remember which one of them was arbitrarily selected by 
> the language designers.

  Luckily haskell doesn't have any arbitrarily selected features in it
which you need to memorize (such as for example some function names).

-- 
                                                          - Warp

Post a reply to this message