mh@wlbr.EATON.COM (Mike Hoegeman) (04/04/89)
>>Machine independent code does not imply teletype compatibility. There have >>been a range of machine-independent screen- and graphic- oriented >>environments (in order of increasing sophistication): >> Termcap. >> Curses. >> X-Windows. >> NeWS. > >Ya. How many of those run on a Mac Well, THEY ALL run on an Mac II . AND Suns AND silicon graphics AND vaxstations AND 386's. NeWS also runs on a regular Mac. The toolbox is for Mac's. Period. This does'nt bother me all that much , I'd use it if I thought it was best (I don't). It bothers alot of others though. that must put out a product on a bunch of different machines. >and compete with the built-in >Mac routines for speed? The NeWS version for the Mac is plenty fast. Now nobody is under the delusion that some mac program written with the toolbox functions directly would'nt be faster. You can say the same thing about hand coding everything in assembler (once you get good enough at assembler) as opposed to doing it in those 'slow' languages like C and pascal. Staying with the lowest common denominator to gain a little speed has been proven over and over again to be a bad decision. >How much of your system's resources do >they consume? It's true that NeWS chomps more memory than just using the toolbox, etc.. but there's really no comparison as far as sophistication goes. NeWS simply blows the mac programming interface clean out of the water. I've used both and it's torture using the mac stuff once you get your hands on something like NeWS. people are willing to jam more memory into their machine in order to run the latest version of awesome-calc or spiffo-write. The toolbox is still back in the realm of 256k machines in it's outlook. Things like having to keep handles around is really disgusting. Yes, it was necesssary at one point, but that point should be long gone by now. In fact with the more sophisticated programs like hypercard that are emerging i think the savings produced by using the toolbox are becoming smaller and smaller. >>> In all honesty, if the >>> application is that valuable then the odds are good that I >>> would be willing to hold out for backward-compatible hardware. >>And so people build backwards-compatible hardware that cripples the NEXT >>generation of applications. Great thinking. I don't think backward compatible hardware is such a bad idea. Does the 386 cripple the next generation of applications. Not that I can see. It's a lot of hard work to do right though. Is it worth it? >Ooooh, thanks. I was hoping I would eventually get a snippy little reply. >I was afraid this would go on for some time being a peaceful, intelligent >discussion. Backwards compatibility does not imply crippling future >applications. That your 80286 can run 8086 software does not seem >to have crippled it from running system III Unix. Yet, you are willing Yow! system III unix! I'm drooling I'm drooling! :-) >to cripple current applications in the name of portability. > >You're right, 'vi' is an excellent example. I tried to teach a >Mac programmer (with an MS from MIT) how to use it, and he >thought it laughably brutal compared to even the most simple >Mac editor. Do you really prefer h,j,k, and l to using a mouse? I love mice , but for simple text editing functions and cursor movement the keyboard is better. If this was false why do all the mac programs come chocked full of "clover-keys", macros etc..? because things that are done over and over and over are faster from the keyboard. A good combination of both is the best. Things like no mouse based cut and paste is laughably brutal though. Unfortunately this is getting into religion-war territory here so maybe I'll shut up at this point. >Ed Driscoll >The University of Michigan >ejd@caen.engin.umich.edu -mike
ejd@caen.engin.umich.edu (Edward J Driscoll) (04/06/89)
In article <28837@wlbr.EATON.COM> mh@wlbr.eaton.com.UUCP (Mike Hoegeman) writes: > > >Well, THEY ALL run on an Mac II . AND Suns AND silicon graphics AND >vaxstations AND 386's. NeWS also runs on a regular Mac. The toolbox is >for Mac's. Period. This does'nt bother me all that much , I'd use it if >I thought it was best (I don't). It bothers alot of others though. >that must put out a product on a bunch of different machines. It would be nice to write applications only for people with Mac II's, Suns, and 386's. If you're in a position to do that, more power to ya. If you're not, and you're worried about portability, you're going to have to stick with the ones even supported by the little regular Mac. I didn't ask about PC's, but I'd be interested to know which apply to them. >Staying with the lowest common denominator to gain a little speed >has been proven over and over again to be a bad decision. Proven? Beyond all shadow of a doubt? Don't tell me, man, tell all those ignorant consumers who are going to buy application B because it does everything application A does, only three times faster, with less memory, and the little pull-down menus and point-and-shoot graphic interfaces mean they don't have to read the manuals. Boy am I glad I don't have to worry about THAT any more! :-) > >I love mice , but for simple text editing functions and cursor movement >the keyboard is better. If this was false why do all the mac programs >come chocked full of "clover-keys", macros etc..? because things that are >done over and over and over are faster from the keyboard. A good >combination of both is the best. Things like no mouse based cut and >paste is laughably brutal though. Unfortunately this is getting into >religion-war territory here so maybe I'll shut up at this point. > > >-mike Yes, I've got a lot of mail from people saying that they prefer cursor-keys for text editing. That wasn't the intent of my comment. Of course you can get used to vi, of course it can do the job, etc., etc. But like vi or not, the interface IS primitive. Hackers like you and I might get used to that, but would you try to sell vi to secretaries and business people? Good luck, I've seen consultants get fired for as much. -- Ed Driscoll The University of Michigan ejd@caen.engin.umich.edu