Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!fluke!mce From: mce@tc.fluke.COM (Brian McElhinney) Newsgroups: comp.sys.mac Subject: Re: New Mac Rumours Message-ID: <7109@fluke.COM> Date: 23 Feb 89 21:36:56 GMT References: <419cc91f.a590@mag.engin.umich.edu> Sender: news@tc.fluke.COM Organization: SRS Recursive Software, Castrovalva, WA Lines: 31 billkatt writes: >William M. Bumgarner writes: >> The Finder (and probably the System) is being rewritten in C++... The speed >> increases quoted are absolutely amazing. > > Get Real. They are written in Assembly language right now. NOBODY gets a > speed up going to a higher level language. You are quoting speeds for the > new system which reqires NEW applications written in object-oriented > languages. That is comparing Apples and Oranges. Take your own advice and compare algorithms to algorithms. A slow and stupid algorithm is always going to be slow. Period. Thus a faster alogorithm is... yep, faster. For example, the Finder uses the Resource Manager to manage icons, etc, in the desktop file. That worked OK with 400K MFS floppies. But the Resource Manager was never intended to handle the thousands of resources a 100 Meg hard drive can have. AppleShare replaces this with a B-tree (K?) and is much faster. Speed has almost *nothing* to do with the language used! Most algorithms are not the ultimate, optimal, fastest, etc. Especially if the software evolved over time (and boy has the Finder evolved!). > Besides, I've used Apple's C++ and it creates a 30K application for a two > line source program (i.e. 'cout << "hey"') It has a long way to go before it > is good enough to base an operating system on. A hand saw beats a lumber mill any day, if all you want to do is cut a 2x4. Brian McElhinney mce@tc.fluke.com