Some thoughts about the PSD format
blogs.adobe.com
blogs.adobe.com
This could not be more wrong. Time and brainpower are limited resources. Building a parser for an ugly format takes more time and consumes more brainpower. It pisses off the developer, who then thinks less clearly. And it requires the developer to repeatedly do research, which breaks his focus. The developer needs to write more code for an ugly format, and optimizing and maintaining such code becomes difficult. If the code is organically evolving (alongside the format), then with each iteration, fewer and fewer people understand the entirety of the code and format, and fewer and fewer people are able to bring good ideas to the table. The developer is angry, confused, mired in a bunch of ugly code, and alone. He will never produce his best work.
None of this is to bash Adobe for producing PSD. Every organization of sufficient age has eldritch code. It is arcane and ancient, and if you look at it the wrong way, it will crumble to dust and blow away in a sudden wind. The problem is arguing that it doesn't matter if mere mortal developers cannot understand it, or that there are no concrete benefits to end users from producing clean internals. The detriments of ugly internals may not be directly visible to users, but users definitely see the ripples on the surface.
I also think you missed the point, PSD is not designed to be an interchangeable format nor a public one. It is designed to operate specifically with it's origin application, therefore why should Adobe care if third party developers have a hard time implementing it? That's not their problem. There is no onus on Adobe to create some magic file format that third party developers can easily implement.
What is their problem is a performant file format with backwards and forwards compatibility that must store a lot of application specific stuff. Stuff that only their application needs to deal with.
As someone who has written a PSD importer for Delphi (in Pascal!) using Adobe's docs, it's really not that terribly difficult for most use cases. It's just as clear as working with any other RIFF-esque file format. You can write a simple importer in a couple of days, and a more in-depth one within a week.
ymmv, ianal.
The only real counterpoint was backwards compatibility and to be honest I don't think that's really valid. With a computer savvy group like Photoshop users I suspect you could introduce a format that addresses all the criticism with minimal disruption.
You are not crazy. I drew the same conclusion you did. There was no discernible refutation.
> There was no discernible refutation.
You've clearly never worked with the bottom 80% of the talent pool :) Many professional designers come from a print background which, by its nature, is not very technically demanding.
It also rebuts the idea that Adobe makes people "sign[] in blood" for specs.
On both counts, whether you consider it adequate is up to you. Personally, I've been involved in enough stuff that the format makes some sense to me (reverse compatibility in a binary format means you make crazy choices by any other standard), but I'm somewhat unconvinced by the second one. If all it takes to get the specs is a fax, you might as well at least turn that into an email, or just put them up on the web... but that's just my opinion.
On the other hand, we really are making a big deal out of a random code comment. I don't know why Nack is perpetuating the story.
Many old formats are crap; heck, you might even expect any old format to be crap in a way or another! You can only write a clear, consistent format specification after the fact when you know everything the format needs to capture.
Even if the basic structure is simple, such as in XML or AVI/RIFF, developers only proceed to write hacky extensions in terms of that very basic structure. The complexity just arises on a higher level, then.