[Color Computer] [coco] Learning MW C

[Tad Burnett]

All I know is that some of the programs that I wrote in GWBasic on my 
DOS 2.1 machine
run incredibly fast on my XP machine...
Tad

James Diffendaffer wrote:

>>Yes, but in *my* personal case:
>>
>>* The script you need is basically 1-off (most of what I do is 1-off)
>>
>>* It takes 2 hours to code the program in Basic, but takes 2 weeks in C.
>>    
>>
>
>Ya know... I keep hearing stuff like that but it hasn't really proven
>to be the case in my experience.
>
>Developing BASIC probably takes less time for short programs but as
>the project grows in size and scope I've found the opposite to be true.
>
>C is definately not as easy to learn as BASIC and to get the most out
>of it requires understanding of things a BASIC programmer doesn't
>even know goes on.
>
>The biggest problem I have with most BASICs is a lack of complex data
>structures and pointers.  There are a few variants than have some data
>structures but it's kinda like records in Pascal.  I loved Pascal when
>I first learned it.  Then I learned C... now I hate Pascal.
>
>BASIC09 kinda fills the same role under OS-9 as Pascal did on the
>Apple II.  It was also a bytecode (PCode) interpreter and could do
>some neat stuff that would take a lot of time to duplicate in C.  In
>the case of the Apple II and 6502 it was the only way to easily create
>relocatable code and it could swap subroutines in and out at runtime
>allowing programs to be larger than memory.  A feature that several
>games on the Apple depended on.  (Sundog and Wizardry for example)
>
>For some applications where speed isn't critical there's nothing wrong
>with BASIC.  But for driving a bunch of stepper motors as fast as
>possible C will be better. 
>
>C also has the advantage of generating assembly out of the compiler. 
>You can write and debug something in C and then take the assembly and
>hand optimize the critical portions.  I did this several times when I
>was developing for the Amiga.  
>
>  
>
>>Saving 15 minutes on overall runtime is a "hollow victory." ;-)
>>    
>>
>The entire project was kind of a thorn in my side so in more ways than
>one.
>
>  
>
>>I'm not disputing a single thing you said [[ and who knows - you
>>    
>>
>might be 
>  
>
>>able to code C quicker than Basic anyway! ]], but sometimes the time 
>>savings doesn't come in execution speed or CPU cycles.
>>
>>Laterz,
>>Roger "Merch" Merchberger
>>    
>>
>
>
>To be fair I've rewritten... er... "refactored" C++ code to
>achive similar savings.  At MCI I took over part of a project
>processing phone records.  Some changes to the C++ classes and
>creative typecasting saved over 11MB (yes, Mega Bytes) of RAM and sped
>up the code on the production system by about 100 times. 
>It would have saved even more if they hadn't designed the system to
>run at least 2 copies.  I also eliminated several thousand lines of
>redundant code that wouldn't need to be maintained anymore.
>I'm not saying the MCI stuff was bad... just far from optimal.
>
>But the point is... there's C and then there's good C.  A bad C
>program might not be faster than a good BASIC one.
>
>
>
>
>
>
>
>Brought to you by the 6809, the 6803 and their cousins! 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>
>  
>