[futurebasic] Re: PG

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : July 1998 : Group Archive : Group : All Groups

From: <BMichael@...>
Date: Fri, 17 Jul 1998 01:17:42 EDT
I said:
>>... I personally don't care for the "draw it" approach to
>>programming (which is probably why I don't use even PG...)...

Tedd said, liberally snipped:
>What's neat about PG, as I find, is that it is a stand-alone skeleton
>program that you add stuff to. All the mundane stuff, like keeping track of
>the window position, channeling all dialog stuff to one specific place and
>millions of other things, are taken care of automatically. You really only
>need to add your specific stuff in the forms of includes and filters. If
>you look at any large programs you write, you really do that anyway.

And I should clarify... I don't use the "Program Generator 4.0" 
application to create my windows/buttons/etc - the "draw it" part. I 
certainly _do_ use the skeleton code that Staz provides; all the filters 
and so forth! My "event loop" is not precisely PG's, but it is similar, 
and major chunks of the apps I've done are straight out of the 
"default-include-every-filter" shell PG generates if you tell it to.

The primary reason I don't use the _whole_ PG approach to objects et al 
is the "write to the application resource fork" issue - I could live with 
drawing my interface, even if I'm not fond of it. When I first got PG, 
the app I was developing was headed for an educational CD - not to be 
copied to the hard drive. Thus PG was out. (Yes, I've followed the recent 
"how to write elsewhere" discussions...) And there is the speed issue, 
which is _relatively_ minor, but which exists nonetheless. Very specific 
code will always be a few nanoseconds quicker than "generic" code that 
requires a lot of branches. And much of what I do is very time-sensitive.

I'm definitely not knocking PG; just saying that for my specific uses, I 
find "raw" FB to be superior. (Actually, to be scrupulously honest, "raw" 
C would probably be even better, shaving a few more milliseconds - but I 
don't want every project to take twice as long to write and be three 
times harder to debug... The PPC issue hasn't forced me to move - yet. 
Every Mac project I've had was required to work on 68K Macs, and there's 
really been no point to having it a bit faster on PPC than 68K; it's just 
had to be "fast enough"...)

Bill