Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!ll-xn!mit-eddie!uw-beaver!fluke!mce
From: mce@tc.fluke.COM (Brian McElhinney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Flex fast lexical analyzer for MPW announcement.
Keywords: %Globaldata is a Good Thing.
Message-ID: <3879@fluke.COM>
Date: 26 May 88 21:32:11 GMT
References: <8534@dartvax.Dartmouth.EDU> <10896@apple.Apple.Com>
Sender: news@tc.fluke.COM
Organization: John Fluke Mfg. Co., Inc., Everett, WA
Lines: 43

In article <10896@apple.Apple.Com> dan@apple.UUCP (Dan Allen) writes:
> I agree that a 32K global data limit is stupid.  But the workaround in
> most cases is so trivial (especially in C) that why waste time worrying
> about it?  USE THE HEAP!

You misunderstand.  Flex doesn't create buffers, but static, initialized data
structures.  It uses C as a sort of high level assembler.  And, no, it is not
trivial to use resources either.  Developing one software tool based on
another is obviously extremely desirable, and the 32K limit should be taken
out and shot.

> It is very rare for an application to REALLY NEED more than 32K of global
> data.  I submit that if an app is using more than 32K, then it is written
> wrong, that is, the allocation of the space should be at a more local scope
> or whatever.

I submit that you cannot call any program right or wrong based on some
arbitrary metric!  Software history is full of people making this same
mistake.  Software grows and grows and grows.  There are also conflicts
between "well written" and "maintainable", when you start applying rules
that define "good" programs.

> If you have a specific problem, I would be interested in hearing about it to
> see if my conjecture (that no well written app NEEDS more than 32K of global
> data) is actually true or not.

How about GNU Emacs: 778240 bytes of code, 212992 bytes of global data = 27%.

Emacs has been called a pig, but not non-trivial or badly written.  I have
never, ever, seen a more useful program (including MPW Shell).  I only wish it
"did graphics".

> The MPW percentage is actually a bit high because it is written in C which
> does a lot of global data initialization which is included in the code size,
> whereas HyperCard is written in MPW Pascal and the initialization code is not
> automatic, although HyperCard does initialize portions of its global data.

I have always suspected that the REAL reason resources were used in the
Macintosh was not because it is such a good idea, but rather because Pascal
does not allow initialized data structures.  :-)


Brian McElhinney
mce@tc.fluke.com