Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim From: tim@hoptoad.uucp (Tim Maroney) Newsgroups: comp.sys.mac.programmer Subject: Re: Spleen venting (was: Re: 32-bit OS) Message-ID: <8380@hoptoad.uucp> Date: 24 Aug 89 05:29:50 GMT References: <22321@andante.UUCP> <1989Aug19.221033.2241@geology.wisc.edu> <8352@hoptoad.uucp> <34184@apple.Apple.COM> <2601@iscuva.ISCS.COM> Reply-To: tim@hoptoad.UUCP (Tim Maroney) Organization: Eclectic Software, San Francisco Lines: 114 In article <2601@iscuva.ISCS.COM> jimc@iscuva.ISCS.COM (Jim Cathey) writes: >FLAME ON **** Save it for when you're right.... >It's not just the CM that can't imagine anyone needing (not wanting) a >long, I can't either. Why not just scale the control? Do you really >_need_ more than 32767 discrete settings for a control? Why? Usually >when scrolling through bitmaps a chunk size of 8 bits is more >reasonable than 1 bit anyway, so using each increment of 1 of the >scrollbar to move 8 pixels yields a document size of about 300 feet! Gosh, I must have forgotten it's a law of nature that there are 72 pixels to an inch. I guess the TIFF development team did as well. You hit this limit in about eight pages there. I know, it really stretches the imagination that anyone might want to fax a whole eight pages, doesn't it? >Controls live in the human interface space, not the program convenience >space. If you find you're wanting more range than is available it's >because you haven't decomposed the problem correctly. Yeah, we should just let it decompose to the point that no one wants to use multi-page high-density bitmaps. That's a sure winner. >The complaint about TE has been dealt with already. By the time you >get that many lines TE has bogged down to the point that you don't want >to use it anyway. Another stunning rejoinder. TextEdit has so many limitations already that one more doesn't make a difference. It's this kind of crystal clarity of thought that has led to TextEdit being the support layer of choice for word processing applications.... >Hell, if all I wanted to do was scroll through a huge number of lines of text >I'd probably not even blink about doing it myself -- especially since I'd >probably 'chunk' the document in from disk piecemeal so's not to waste memory >having my mongo document in memory all at once. Those putative 40,000 >80-column lines take up 3.2MB all by themselves. C'mon guys, MoveTo and >DrawText are _easy_! Yeah! Yeah! And selection is a breeze! And double and triple clicking are easy! And shift-double-clicking is practically trivial! And style changes are a snap! And word wrapping algorithms -- no problem! And size changes are very easy to handle! And compatibility with Script Manager, right-to-left font families, context-sensitive letters, and two-character symbols isn't all that hard! And so on, and so on. Tens of easy problems generally add up to a hard problem. But let's back off and see what you're saying here. TextEdit is fine because it's so limited you don't use it anyway. The 16-bit limitations of QuickDraw and the Control Manager are fine because you can hack your way around them by using counter-intuitive approaches. Anyway, you can always write your own managers. Are you making any sense at all, or did you just get up on the wrong side of the bed this morning? >Lord help us when the Mac has VM -- hardly anyone one will ever even >try to appease the effeciency gods. The Vax weenies [Paging Will Fix >It (tm)] will dance upon our graves yet (chanting "More megabytes, more >megabytes..."). Well, I'm glad you got that off your chest. It has nothing to do with this message, but then, flames are supposed to be incoherent and shrill, right? Right. >I _like_ the 16-bit integers and all that entails. They serve as a constant >reminder to _think_ about what ranges I need, and why. The long is there for >when they won't serve. Not in the operating system it isn't, you blithering cretin. There is no capability to use longs when you run into the OS limitations on shorts. (There's a joke in that last clause, but it's not worth the trouble.) Is this point so hard for you to understand -- that 16 bits is a low limit which very many real programs will hit in the real world, while 32 bits is a high limit which most real programs can treat as an effective infinity? >I suppose spending a few minutes thinking about things _is_ too much >for some, but let's let them continue to bang their shins on real-life >systems and piss-n-moan about it. It's considered strange to talk about yourself this way. >_We_ know better don't we? Sooner >or later they'll learn, and we'll all be better off. We won't appease >the uninformed by breaking our tools so they're less efficient. (You know, >32-bit ints, >32K globals for huge static arrays, VM, things like... oh-oh!) Oh come on! Not only 16-bit control values and bit planes, but virtual memory, 32-bit integers, more than 32K of global space, and for all I know, a 32-bit data bus drive you up the wall now? Why don't you go back to CP/M and have fun with your little 64K address space and trying to fit real programs into it? The rest of us have work to do. I can just see it now. "4-MEGABYTE SIMMS -- JUST SAY NO." "A deranged individual identifying himself as a computer programmer was arrested outside Apple Computer in Cupertino today after threatening to, quote, wake those idiots up to the threat to our precious bodily fluids. His demands to reduce the Macintosh to 64K of RAM and, quote, no more bits in QuickDraw than will fit on a screen, were dismissed by industry observers as the ravings of a madman." >FLAME OFF **** I think "pilot light out" is more accurate.... -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Every year, thousands of new Randoids join the ranks. Most tend to be either too-rich self-made tycoons or picked-on computer nerds (the romantic, heroic individualism of Rand's novels flatters the former and fuels the latter's revenge fantasies)." -- Bob Mack, SPY, July 1989