6 ms·

If you're a Photoshop user, would a brand new PSD alternative offer tangible benefits--faster read/write performance, smaller files? That's unlikely. Being easi

If you're a Photoshop user, would a brand new PSD alternative offer tangible benefits--faster read/write performance, smaller files? That's unlikely. Being easier to code has nothing to do with offering better performance. 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.

tptacek 17y ago
Somewhere in the Joel on Software Excel article, Spolsky makes the point that most Office features, most buttons and checkboxes, have to be represented in the file format somehow. That graf hit me like a punch in the gut. Sure, there are tangible benefits to an improved file format. But Nack's point is really, is it worth it for Adobe to undertake that kind of surgery to provide it?
jawngee 17y ago
I'm going out on a limb and guessing you've never written an application of any complexity that required it's own binary file format. I don't mean that as a slag, but your comments leads me to believe that is the case and, therefore, your understanding of the issue is purely speculative. 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.

tptacek 17y ago

Somewhere in the Joel on Software Excel article, Spolsky makes the point that most Office features, most buttons and checkboxes, have to be represented in the file format somehow. That graf hit me like a punch in the gut. Sure, there are tangible benefits to an improved file format. But Nack's point is really, is it worth it for Adobe to undertake that kind of surgery to provide it?

jawngee 17y ago

I'm going out on a limb and guessing you've never written an application of any complexity that required it's own binary file format. I don't mean that as a slag, but your comments leads me to believe that is the case and, therefore, your understanding of the issue is purely speculative. 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.