Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!uunet!portal!cup.portal.com!wetter From: wetter@cup.portal.com (Pierce T Wetter) Newsgroups: comp.sys.mac.programmer Subject: Re: Spleen venting (was: Re: 32-bit OS) Message-ID: <21584@cup.portal.com> Date: 25 Aug 89 03:00:33 GMT References: <22321@andante.UUCP> <1989Aug19.221033.2241@geology.wisc.edu> <8352@hoptoad.uucp> <34184@apple.Apple.COM> <2601@iscuva.ISCS.COM> <8380@hoptoad.uucp> Organization: The Portal System (TM) Lines: 147 In article <2601@iscuva.ISCS.COM> jimc@iscuva.ISCS.COM (Jim Cathey) writes: >>FLAME ON **** >Save it for when you're right.... Save the snide remarks 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? Gee, I must have forgotten it's a law of nature that the value you pass to the CM must have a one to one correspondance to your data. God Forbid that the scroll bar value should be the y coordinate of your document in INCHES instead of 300dpi pixels. (Or even quarter inches!) Or even the size of your document over 65535! Wow! 65535 distinct positions in a say, 50 page document. Gee, thats every .008" inches. Of course 50 300dpi pages would need 50megabytes of storage, but who's counting. >>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. Different uses of decompose here. Decompose as in simplify, and decompose as in brain rot. Pay attention! :-) >>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.... What do you want from something that was originally designed to fit in 2k of ROM? TextEdit does fine for what it is: A system utility for editing, and displaying small bits of text so that programmers don't have do spend hours writing code every time they want input from the user. Styled TextEdit simply allows for fancier display boxes. TextEdit was never designed to be a word processor, which is why it doesn't handle: footnotes, paragraphs, full-justification etc. That was the point to his response: bitching about TextEdit has been dealt with. >>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. Why do you need all this unless you are writing a Word processor? Besides, the structures that TE uses are OPTIMUM for SMALL amounts of text. They would be rediculous for LARGE amounts. (Would you really like to search through a 1 meg array of char to change line breaks every time a char was inserted? Or would you rather search through the structure for that paragraph?) What you are really bitching about is that there is no library of text handling routines for big files or word processors. I have news for you. There never will be unless they provide them in source, simply because everyone will need just a few more fields in the records. If you want this, buy CAPS from Think. >>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.) Actually, the OS is the file manager and the like which use longs, and the toolbox is what uses shorts, but thats quibbling. Just because you disagree with his opinion, don't call him a cretin. He said that HE liked 16 bits, he didn't say that you had to. Since you don't really understand what he said, let me explain it. Programmers are lazy. If apple had put long offsets into TextEdit, MicroSoft Word would use it even if it was deadly slow above 10K. Database programmers would use the Resource Manager for their databases, even though it was totally inappropriate. And the mac would be a toy. >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? Is this point so hard for you to understand -- that 32 bits is too big for most tasks and that lamely written programs would treat it as effective infinity even when inappropriate? (Personally, I would prefer 17 bits) >>_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. Virtual memory is only bad because lazy programmers put big static arrays in their codes instead of calling malloc. Ever try to port a ray tracer to the Mac? The fact that they never simultaneously use those 15 four meg arrays never seems to enter into programmers minds. "Its just swap space." 16 bit integers are faster then 32 bit integers. > 32K of global space would be nice but is only possible on 020 machines which can have 32bit offsets from address registers. (Unless you want global data to have absolute addressing which would only be possible by relocating the code (ala CP/M-68K) or using a PMMU). Did he mention a 32bit data bus? No, you did. Of course, if you really want something to bitch about, how come the Mac II motherboard doesn't do block transfer? I mean, god forbit you would ever want to shove bytes at the video memory! >>FLAME OFF **** >I think "pilot light out" is more accurate.... I think _reasonable response_ IS accurate. Pierce