Path: utzoo!attcan!uunet!iscuva!jimc From: jimc@iscuva.ISCS.COM (Jim Cathey) Newsgroups: comp.sys.mac.programmer Subject: Re: Spleen venting (was: Re: 32-bit OS) Message-ID: <2605@iscuva.ISCS.COM> Date: 24 Aug 89 21:40:15 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: ISC Systems Corporation, Spokane WA Lines: 118 In article <8380@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >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? Never said it was a law, but it _is_ a characteristic of the Macintosh display space, which is where the numerical value of a control has its ultimate expression. Regardless of the bit density of a TIFF image, once displayed on the Mac screen it is 72 bpi (more or less), if you're working with a 'life-size' representation. My original point is that a control already has a much greater range of values than an operator can comfortably deal with. Scaling will easily (even trivially) handle shifting to whatever space your application needs. You have not addressed the issue. Bumping into that 16-bit limit is more a case of "Oh, nasty... wait a minute, I can't use that simple-minded approach anyway because then the program would be hard to use. Let's think about this for awhile..." >>... >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.... Which it was _never_ intended to be! >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. Having Word in ROM might be nice, but that's not a real expectation is it. The original posting was (as I interpreted it) about displaying text out of a (large) file, not about interactive editing. Anything that requires a huge file to be entirely in memory before displaying a little piece of it sucks, so far as that is concerned. Eventually TE will probably be extended to start swapping pieces on and off of disk. I don't expect it to, and I don't really even want it to (given what it will surely do to the overhead [per usage] required to run TE), and I surely don't expect the manner in which it will do it to please everybody. >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? Intuition is not always correct, and you _can_ always write your own managers, especially if the ones that already exist are designed to solve different problems than the one you have at hand. >>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. Such politeness!! I've never advocated the use of a short where a long is called for. My point has always been to use the appropriate size for the job. Certain things have no need for more range than 16 bits implies. Certain architectures penalize you for the larger sizes (the 68000 is one such). What's wrong with recognizing this situation and allowing for it? It certainly doesn't hurt you where this isn't the case. >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? Just as they treat memory, disk space, and CPU horsepower as effectively infinite? Sorry, I work only on _real_ machines. Ones that reward me with fast execution speeds for thinking first before coding. (Oh, you mean they _all_ do that? Well, how about that!) >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? Larger than 32K global space encourages such laziness as declaring huge arrays as global, rather than allocating them. I am not against large global spaces, but I am against this laziness. It is unfortunate that the environment is such that you can't have the best of both (a system that lets you have a large aggregate of globals [for the rare times when you really need such], but doesn't let you have huge working arrays without using NewPtr/NewHandle.) I like 32-bit data busses, but not when I'm trying to design a low-cost something. These things all have their place, and it'll be very sad when I can no longer design a low-cost something because all the programmers were too lazy to make programs that would run on lesser machines. My worry is that we'll end up like the damned IBM's, where programs that don't do very much require 386's in order to run acceptably fast. Out of programmers' laziness. If you want to see another sorry sight, try one of those DEC Vaxstations. 800KB-1.2MB window applications. 6MB of RAM and the thing's still sluggish, it feels worse than the 512K VM graphics workstation I'm typing this on. +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC-Bunker Ramo ! II CC ! TAF-C8; Spokane, WA 99220 ! IISSSS CC ! UUCP: uunet!iscuva!jimc (jimc@iscuva.iscs.com) ! II CCCCCC ! (509) 927-5757 +----------------+ Member: Society for the Preservation of Thought in Programming. P.S. I never did like CP/M, though the Z-80's inherent limitations aren't what bugged me about it.