Wonderful Leopard

I too am involved in a pretty big project consisting of millions of lines of code, available for the past 30 years... I guess the difference is that we actually keep up with and take advantage of technological advancements. Over the next year, we'll be refactoring the entire code base for one of our projects... it's a big task, but when we finish that product is going to be 50%-75% more efficient. I don't know about you, but with the wide spread use of laptops and limited battery life, efficiency is king. I work in one of the most regulated industries we have (literally half the time spent working on each release is spent at the FDA), which would seem to inhibit the desire for change, and yet it's something we strive for. Due to that, our code has gotten much, much more complex, but is efficient enough that a single device could last 10 years before the battery dies and it has to be explanted. You don't get to that point by sitting back and using 10 year old code.

I'm saying that maintaining compatibility with thousands of device drivers is more important than compatibility with a few applications. You may not care about device drivers, but i certainly do. Without updated drivers, i can't use my printer, scanner, TV tunner, iPod, USB hub, firewire port, CD-R, DVD-R, wireless keyboard, wireless mouse, or any other of a million devices i might want to use my computer with. You're lamenting over the loss of a single piece of software that a manufacturer decided not to update. I'm lamenting over the loss of thousands of pieces of software that need to be updated. Which is worse, upgrading to Vista and no longer having a functional keyboard/mouse/printer/scanner etc, or upgrading to Leopard and not being able to use a $900 XML/word editor that a rather small percentage of computer users even know about?

 

Sorry to say that, but that's a meaningless statement. From a source code perspective, for a lot of components, there simply is no technological advancement. The C++ code I wrote 10 years ago is object-oriented but lean, reusable and multithreaded whenever applicable. For the vast majority of the code, there simply has been no technological evolution in that time that would improve it. Revisiting that code would be a waiste of time and resources that my company can invest in much better things.
And the FDA is one of our best customers

I'm not lamenting, I use PC's...
But my answer to your question is simple: obviously the second. That's a no-brainer. In fact, I never even bother upgrading the OS of an existing system. It's a waiste of time. XP still does the job perfectly well for me. If I need that OS (like testing on Vista), I buy a new computer with it, or I may perhaps install it on Virtual PC. Peripherals can be replaced at any time, but those who were relying on FrameMaker for document creation on a Mac are completely left in the dark. And they are very angry. If you need it, there is suprisingly little alternative.

 

It's not a meaningless statement at all... Like anything, software is constantly evolving. The basic architectures that we all know and love are changing constantly. Compression and encryption algorithms are always being developed. Third party API's are being developed and maintained that make your code much more efficient, should you choose to use them. Take Spring or JSF or whatever else you want... They provide functionality to your code that is a vast improvement in both performance and capabilities than anything you would want to develop and maintain in-house. Upgrading your image format can provide you with both increases in server-side processing time (for dynamically generated images) and bandwidth, a double win. These abilities simply weren't available as much as 10 years ago, and leaving your software to stagnate invariably puts you behind the competition.

 

I consider it a meaningless generalisation of a principle that holds for some type of code or projects, but certainly not for everything. I can certainly imagine that this is a relevant approach to your project, but it certainly isn't for all projects. The proof is the billions of lines of decades old code that are still run every day.

We are doing very fine with the competition, but thank you for caring... Perhaps the reason why we are doing so well is that we don't waiste our time rewriting existing code again and again, but rather focus on creating new, innovative features

But seriously, let me give you just one example. Our C++ code contains a lot of advanced statistics calculation routines. What can we improve on that? It's already multithreaded, so no problem with the latest trend in CPU's (multicore). We could rewrite it with STL and Boost (both didn't exist at that time). The code would become shorter, more elegant, easier to read, but not a bit more performant. Chances are, on the contrary. Rewriting that would simply be an unacceptable waiste of resources that should be allocated to better destinations.

BTW, if you need to touch existing code because you want to implement a new image format or a new encryption algorithm, your code is in fact bad by design. Both should be implemented as a realisation of an abstract class (or template, in some cases) that you can provide to any consumer class that relies on it (say, a class that generates content for the image). You just add code. In that way, existing code can perfectly use new functionalities without any change. That's the essence of writing reusable code using an object-oriented design.

 

And yet, thats not always possible, nor is it always practical... take into consideration changing image formats... If you're generating the image dynamically relying on several different algorithms to add portions to the overall image, it would seem to make sense that you have to pass that image around a bit... but if you change the image format and move to a different image library, odds are there's a lot of code that needs to be changed to accommodate that - passing around the image buffer for one... if it's a different format, that could cause a problem. Changing the library means that every place you used those library functions (which is probably everywhere you manipulated the image and then some) you have to change your code... In the end, it can mean rewriting a lot, but at least for us we got a 90% performance improvement. And that was just earlier this year. We have it on our plate to change all of that again next year to take advantage of newly emerging technologies.

But you did make one good point - it should be easy for you to make changes to your code if you're following best programming practices... In general, any evolution of the API's between two releases of an OS isn't going to be extremely huge, and it really *shouldn't* be that big of a deal for a company to accommodate those changes. The fact that there's one product that Adobe chose not to upgrade to work with the "latest and greatest" OSX isn't really Apple's fault. Most programs out there for Tiger work in Leopard. However, the fact that every device in existence for PC's had to have a new driver written is MS's fault. I'd rather have a new OS that maybe breaks a few programs than one that definitely breaks all the device drivers and a few programs.

 

I'm afraid that we are getting a bit carried away, but it looks like we have totally different programming strategies. I would never let calls to any (3rd party or else) library diffuse that far in my code. First thing I do, is to write an abstraction layer around it. A bitmap is an abstract matrix of color values. Color values by themselves are again an abstract class, that can be instantiated into a variety of things (index, RGB, 16 bit gray, etc...). That's all any consumer of a bitmap needs to know. You just provide it with the abstract class interface (in C++ lingo at least). That could be a content creation class, or a sharpening tool. The memory storage, compression, streaming to disk, export, import, etc..., that is all left to the responsibility of concrete realisations of the abstract image class. In that way, you can instantly plug other image types and formats into any existing code, without needing to rewrite a single byte.

The problem of course wasn't going to Leopard. The problem was migrating from MacOS to OSX. That was a 100% total redesign of the API if you want to run your code native. That's when Adobe said "No thanks" for FrameMaker.
And BTW where on Earth did you get it that Vista breaks all existing device drivers? All the ones that I encountered so far work just fine. In fact, Apple has had two times when all device drivers needed to rewritten: from MacOS to OSX, and from PowerPC to Intel.

 

You're right, just a bit However, i would contend against your (IMO) excessive use of abstraction... to do so to such an extent would have a horrible performance impact on your code, which simply isn't acceptable in many situations. When you're talking about a system that has to be near instantaneous for 100k+ users per day, you can't afford to have to be translating back and forth between the abstraction and what the library uses.

So, aside from FrameMaker, was there anything else that got left behind? IMO, the refusal of one company to upgrade one of their products doesn't mean that it was a bad move on Apple's part...

But were those transitions a problem for the end users? or did everything just work? We're sitting here almost a year after Vista came out, and i still hear about driver incompatibilities every week. In fact, i've even read that updating a device driver could cause your copy of Vista to deactivate, making your PC a rather expensive paperweight... I haven't heard the same from OSX, ever.

 

Well, I don't know about Java (who wants Java if you need speed anyway?), but in C++ the theoretical overhead caused by a virtual function call is so small that it would perhaps only become somewhat significant if you had 100K+ hits per second. And even then, modern compilers are more than intelligent enough to optimize that level of indirection away if they detect that always the same virtual function implementation is called. Heck, even the CPU is perfectly capable of optimizing this away 100% by simple branch prediction.

FrameMaker is the only major application I know of. But there are numerous small niche players that did the same thing. Now that iMacs are capable of running native Windows, the incentive to develop for OSX will be smaller than ever form small 3rd party developers.
I don't know if this is a bad move or not from Apple's part. But what I know is that one of the reasons MS became so dominant is that they always cared about 3rd party developers and legacy code. Over time, they have had one of the most stable development platform and longest supported API of the industry.

You simply can't compare the situation of MS and Apple here. Apple controls the hardware. It would be a bit silly if they didn't manage to update their own drivers in time, wouldn't it? MS doesn't control any hardware at all. Not the computers, not add-ons, not the peripherals. Peripherals are made by hundreds of companies all over the world. They have no control whatsoever on what these companies do. Some aren't even in business anymore. I am confident that you understand that this is a totally different situation than for Apple. You can argue that that's a weak point of the PC philosophy and you would be right. But, it the mean time, it is also one of it's strong points, and a key to the success of the open PC model. But it does come with a price indeed. Personally, I don't care, because I don't upgrade the OS of existing hardware.

 

Well, not code, and maybe not even twelve years ago, but it feels like it: I still use Paint Shop Pro, the first version, on my Vista. It still works. And I think it was even shareware, or something to that effect, back when I first got it.

Let me check. Hold on.


Yup. It was indeed shareware. And I downloaded it on 11/15/93, so it is indeed, 14 years old.

And like I said, it still works, even with Vista. Not bad.

 

I've been thinking about getting Leopard to update my Tiger. But I decided to wait until next year so they can try to fix the bugs and come out with an improved version. Leopard does sound nice, and the Time Machine is a great feature.

 

OSX86 ftw!