If users only knew.
It's good to hear that Path Finder is stable today. If that's true. It's an app for a Unix OS but it's not a Unix app. It's a monster, and Unix apps aren't monsters. Unix uncle Doug McIlroy made sure of it if the co-creators hadn't understood (which they had).
Once asked if he could do anything differently a second time around, Ken Thompson famously quipped 'I'd put an 'e' on the end of creat()'.
creat() is the ubiquitous API for creating files. Ken Thompson is so cryptic that he truncated the final 'e'.
Ken found it unnecessary to have vowels in command names. 'copy' became 'cp', 'move' became 'mv', 'remove' became 'rm', and so forth. Part of this was due to their using telex terminals but a big part was Ken's cryptic nature.
Their mentor Doug McIlroy also laid down the general rules for programming early on. Programs were supposed to do one thing and do it well. You don't add bells and whistles to finished programs - you created a new project instead.
Programs should also work well together, said Doug. For this he insisted all programs be able to understand 7-bit ASCII both for input and output. That part can be difficult in a GUI environment, something they didn't have back in the day in Murray Hill, but it's the thought that counts. Data should be available and exportable when possible, and apps should understand data coming from other apps when compatibility exists.
Such matters are difficult to apply to an app from a company that has but one app. But there's another aspect to it as well. For if you only have one app, after all these years, why do you have shared libraries?
Shared libraries are not an invitation to romp as babes in the wood. Let's take a step back.
Take our programmer Sven. Sven builds this killer app which everyone loves. They're pleased with Sven and Sven is pleased with himself.
After a while, Sven gets an idea for another killer app. He completes it, submits it to his colleagues, and his colleagues love this one too. New victory for Sven.
But a bit later, in a relaxed moment, Sven reviews his code for both apps, and discovers he's written identical routines in several places. Which is redundant, not to say wasteful, not to say stupid. Sven realises that some of these routines are likely to be needed in future killer apps, so Sven comes up with an idea.
Sven compiles each of these redundant routines to OBJECT CODE. Then he puts these object modules in his projects, instead of the source code. This speeds up his build times a bit, but little more. Still, it's an improvement.
As Sven's accomplishments grow in number, he takes things a step further. He creates an object LIBRARY. This library holds the object code for each of his redundant routines.
Now Sven needs only have this library in his project. The project will find the needed routines at link time. So far things don't save footprint, but the operation is more streamlined.
Now Sven graduates to event-driven programming, meaning it'll be the OS calling his apps and not the other way around. Sven can now create SHARED libraries. And the MO is now significantly different.
The code in this shared library is never linked into his apps. Oh no. The program loader, at runtime, will find the routines needed and MAP THEIR CODE into the ADDRESS SPACE of his apps. The code in the shared library is never found in the apps themselves. Finally we see how things can be optimised (for size, for 'lean and mean').
Suddenly there's a point to building libraries. Suddenly there's a clear rationale and very clear guidelines.
If you have but one app - and, after twenty years still have but one app - then you have no business making shared libraries.
You only contemplate a shared library if you have at least two apps that will be using the exact same code. When use is still at a minimum, there can still be a trade-off that can be measured. The more those routines are used, the greater the advantage of having them in a shared library.
If you create a collection of apps for a client, it's understandable that the collection has a single shared library of its own. It's also understandable if your software house has a single shared library for all its helper functions. But that's about it.
Now check how many shared libraries (frameworks) are found in Path Finder - or any number of typical third-party apps for Apple's OS. There is no reason for this, no justification. The only possible explanation is that it would somehow make development easier. But how? For the code in those libraries can never be tested on its own. And, when things start getting that complex, you're asking for it.
The original Microsoft Word was the work of four developers. Twenty years later, they had some two thousand developers working on the same app.
There's another explanation of course - one that probably doesn't apply to Steve. It's when sloppy developers pick someone else's code off the shelf and toss it willy-nilly into a project with no respect for anything.
That's the Apple way. It's not the Unix way.
This is a brilliant treatise by an Australian dentist, easily the best programmer for Apple's OS we've ever encountered. And he only did things like this in his spare time whilst studying for his DDS and other degrees.
You might not believe the reaction when that piece was introduced to the Apple community. Then again you might.
At any rate. Something else to consider.
It's quite understandable that unwitting users are impressed if the app they're after takes more rather than less disk space. It's natural to assume that 'the bulkier, the better', as that can mean more code (and more sophistication). But it's regularly the opposite that applies. We discovered this in the Windows software market before the new millennium. The website that 'discovered' us, Lockergnome, wrote that it was amazing we'd packed over thirty powerful applications into such a small download.
We hadn't done anything special. People wrote and asked if we had contacts within Microsoft and obtained 'secret' APIs. But it was none of that. It wasn't we who'd done anything special. It was the others who wrote such shitty code. And the amount of shitty code out there is simply downright staggering. We spent years going after the worst offenders and trying to get developers to up their game. We made it onto the ACM's RISKS Digest in what almost became a crusade. We created the Bloatbusters site in jest - because things were simply that bad. And no better on the Apple side of the fence.
The stupidity of people can be staggering. It doesn't happen that often, but now and again...
One time, when we were enjoying the sunshine of Crete, we got a letter from a client. He was disappointed that he needed to drag-drop twice rather than once to 'install' our software package.
It's only a swipe with the mouse or trackpad, we reminded him. But he was adamant.
Why can't you just bake your shared library in each application, he asked.
Because, we replied, that library, with all the software documentation, is easily the biggest module in the system. 450 KB approximately.
But so what, he asked back. Your apps are so lean and mean anyway.
But we have over fifty apps that need that library, we told him. You're talking about increasing the size of the package by fifty times!
Ah, he replied a final time, it's still pretty lean and mean - isn't it?
To go even one step further (into the abyss). You don't create a shared library only for the fun of it. Unless you're trying to learn something. It's not something you give to a client. What you give a client must always be the best you can offer - from the client's perspective. You don't need a new shared library for a single function that simply takes a character string and transforms it from upper case to lower. Or for a function that returns an array of path components for a complete path on input. Or anything like that. Good friend Robin Keir, who wrote some of the best Windows code ever, would always search and shop around before rolling up his sleeves to write something himself - 'let the other guy do the hard work'. Adding shared libraries to a project with a single client is comp sci masturbation, nothing else.
Early compiler defaults from David Cutler's 'Tribe' optimised for 'speed'. Anyone who's battled with Al Aho's dragon books knows how foolhardy that is. Back in those days, Microsoft still used too much Afx code which in many ways was so hopeless that 'speed' seemed the only way out. But Cutler nipped that one in the bud. For optimise for size is by default always faster. The fewer instructions needed, the faster your program's going to run.
This holds for software packages on disk as well. Two apps, side by side, both do the same thing, but one is lean and the other's bulky. You have every reason to suspect there's something wrong with the bulky one.
There's an incredible amount of waste in the software industry today. If users only knew.