3 ms·

Exactly - for example, resizing photos. Imagine a resizer object, that could be used: - to implement resizing in various interfaces for image objects - in a

Exactly - for example, resizing photos. Imagine a resizer object, that could be used: - to implement resizing in various interfaces for image objects - in a script (think unix pipes but operating over real image objects, not streams of bytes) - wired up to various events and data sources for automation (when my aunt emails me a picture, resize it and put it in this folder) The resizer wouldn't be hidden behind some app's implementation - it would be a first class object you can inspect and interact with ("ok, looks like this resizer objects takes an image object as an inputs and outputs another image. i'll drag an image onto it right now to try it out")

marcus_holmes 6y ago
One of the big problems I've seen with multi-vendor systems that co-operate is if something didn't work. It was never clear where the problem was because the system incorporated multiple products from multiple vendors. So if your resizer object didn't work for some images after upgrading Photoshop, but it used to in the old version, how do you get that fixed? In a single-vendor program, it's clearly a bug in the program and you can hand it back to the vendor to fix it. When multiple vendors are involved, it gets way more complicated. Each has a tendency to blame the other, and not take responsibility for the problem. Each will claim that they are coding to the interface specification. And they might be, it's just that the specification isn't tight enough to make all interactions bulletproof. I don't really have a solution (apart from "write a really, really, tight interface. No, tighter than that"), but I've seen the problem enough to be skeptical that we can have this. edit: I should add that I wish we could have this.
- imhoguy 6y ago
  This. It is not just vendors, but also teams within any company. E.g. operating systems: Windows, Android, iOS/OSX - all are composed of modules which are running as isolated processes and communicating over agreed interfaces. Before system upgrade reaches the market there are countless meetings between teams to sort out bugs and design inconsistencies.

marcus_holmes 6y ago

One of the big problems I've seen with multi-vendor systems that co-operate is if something didn't work. It was never clear where the problem was because the system incorporated multiple products from multiple vendors. So if your resizer object didn't work for some images after upgrading Photoshop, but it used to in the old version, how do you get that fixed? In a single-vendor program, it's clearly a bug in the program and you can hand it back to the vendor to fix it. When multiple vendors are involved, it gets way more complicated. Each has a tendency to blame the other, and not take responsibility for the problem. Each will claim that they are coding to the interface specification. And they might be, it's just that the specification isn't tight enough to make all interactions bulletproof. I don't really have a solution (apart from "write a really, really, tight interface. No, tighter than that"), but I've seen the problem enough to be skeptical that we can have this. edit: I should add that I wish we could have this.

imhoguy 6y ago
This. It is not just vendors, but also teams within any company. E.g. operating systems: Windows, Android, iOS/OSX - all are composed of modules which are running as isolated processes and communicating over agreed interfaces. Before system upgrade reaches the market there are countless meetings between teams to sort out bugs and design inconsistencies.