Date   : Mon, 21 Sep 2009 22:27:14 +0200
From   : rick@... (Rick Murray)
Subject: Beeb, this was your grandma!

afra@... wrote:

> Whereas having spaggetti code with multiple entry/exit points is a  
> good thing ?

Multiple entry points are kinda evil. A lot of my functions have 
multiple exit points. For example:

    dohickey_file
    {
       check file exists
         if not, set return code and abort

       check file is valid
         if not, set return code and abort

       load file
       set return code and return
    }

My philosophy is when you have enough information to make a decision, 
make it. You might say you could easily:

    dohickey_file
    {
       check file exists
       if exists
       {
          check file is valid
          if valid
          {
             load file
          }
       }
       set appopriate return code and return
    }

This is, however, a messy way to achieve an ill-conceived rule. When you 
program in assembler, you'll want to MOV PC,R14 or RTS as soon as you 
know you are able, not implement an evil bunch of B/BRx simply in order 
to only have one exit point.

Or in human terms. You are out of pasta, so you don't boil the water and 
you don't think if... you instead think "oh crap" and drop out of "make 
some pasta" mode and instead head over to rummage around in the 
cupboard. :-)


> Well in C you also have to define something before you use it, which  
> admittedly you can do with function prototypes now, but could you back  
> then ?

I think so, I think C has always supported stuff being scattered around 
half a hundred library headers...


>> their advocacy-ass and coded up a drool-proof C [#] compiler [!].
> Can't comment on C# as I never used it.....

That wasn't C# (isn't that Microsoft's redevelopment of C?), it was "C" 
with a reference to footnote '#'.
I guess I should have numbered them. :-)


> Indeed and it's things like that that can lead to code being insecure  
> by having buffer overflows etc.

I think only a dribbling lunatic would refuse to accept this as an 
inherent flaw in C.


> As said before Large parts of early MacOS where I believe Pascal,

Wow. I don't know if I'm impressed or shocked. It certainly helps 
explain the early-Mac reputation for being a bit... well... anal. :-)


> as was Apollo Aegis/Domain.

? I know Aegis as being the city in Masamune Shirow's "Appleseed".


> and I do program quite frequently in both.

I *loathed* Pascal, but it is interesting to see it is still active. I 
think one of the features I like about C is, given some thought and 
custom libraries, the same code CAN compile on totally different 
machines. My early 6502-system emulator works under both DOS and RISC 
OS, same code. Okay, I had to fake up most of conio and a fair few dos 
calls, but it wasn't impossible. I even rolled a NTCommandWindow version 
as well, for the hell of it mostly. :-)

All in, C is powerful for those little tweaks it does - I like the ?: 
thing, and the %blah in printf - both of which require so much extra 
work in other languages. But C is far from perfect...

In VB, another thing I miss is var+=blah, which is just nicer than 
var=var+blah.


 > there is no one language that is good at everything.

This is C's biggest failing. It is used for doing everything.

I certainly agree with this - I'd NEVER use VB to write a kernel. I 
don't think it is actually possible (where would it be without several 
dozen OCXs?! :-) )


Best wishes,

Rick.

-- 
Rick Murray, eeePC901 & ADSL WiFI'd into it, all ETLAs!
BBC B: DNFS, 2 x 5.25" floppies, EPROM prog, Acorn TTX
E01S FileStore, A3000/A5000/RiscPC/various PCs/blahblah...