Flutterby™! : more GUI people don't get it 2000-11-04 18:13:48+00

more GUI people don't get it

2000-11-04 18:13:48+00 by Dan Lyke 19 comments

Dave Winer recounts a discussion with Jon Udell asking "why the Unix world doesn't have an integration architecture like Microsoft's COM." It has. Since the late 60s. It's called a "pipe", and it provides interoperability between applications in a way that Windows users only dream of. Example, recently: My parents live next to the manager of an Atlanta Hilton. He had a conference, and had been given a list of attendees by the conference organizers, but not given their arrival and departure dates. When he asked, they gave a list of travel itineraries and said "here, you can reconcile from this", and he had some poor person going through the list. Of course that's one chained command line with sort and diff that'd probably take a few seconds to run. COM helps people write ransom notes in more different styles, pipes help people move data. Of course that means that COM is going to win, in the long-run.

Maybe there are two different things both called "COM", but what you're describing has nothing to do with the COM I work with. COM is a way to abuse C++ to get cheap object introspection with a collection of macros, classes, and conventions. It allows you to easily mix together applications from a collection of DLLs that have no prior knowledge of each others' existence. It assists in the development of large software projects by supplying a limited contracting scheme. It's a code structuring tool that eliminates the headaches that come with deep inheritance. It makes programs more upgradeable, more maintainable, easier to debug. (Oh, and in addition to all that, there are a couple of interesting side effects having to do with IAC, but that's not really the point.) Maybe, from a user's point of view, the things you can do that are side effects of programs which use COM might have some similarities to things you can do as side effects of programs built around pipes. But they aren't even remotely similar as technologies. It'd be like comparing an ethernet card driver and a web browser - they're approaching different problems at different levels of abstraction. For what it's worth, I'm a Mac & Unix kind of guy, and was all set to loathe COM when I first encountered it simply because of its provenance. Now I find myself doing things COMishly even in casual free-time hacks, simply because it's so much nicer a way to write code. It has its weaknesses, mind you, but they're much easier to live with than the weaknesses suggested by a straightforward use of C++. -Mars

Actually, Dave used COM, what I meant was OLE, I think what Dave meant was something in-between those two.

umm well OLE sits on top of COM objects. while I would agree pipe is great for blasting the bits back and forth you are missing two fairly usefull things Iunknown(interface) and GUID(unique id).

IUnknown: C'mon, how often do you actually use interface discovery in the real world? GUID: inode?

Pipes are great, they're kind of like HTTP, they get you from point A to point B in a reliable way. The subject of Unix pipes even came up in the discussion I had with Udell. The next layer-up would be something like Windows Scripting Host, or Apple's Open Scripting Architecture, which would allow a common set of interfaces for embedding any scripting language/environment in a host app, like a Web server, or a paint program.

Now a common set of APIs makes a lot of sense, and even though I have railed against XML-RPC in the past I think it or SOAP is as good an idea as any. What bothers me about COM is that, like much of object oriented programming, in many cases it's unnecessary added complexity which doesn't actually make things any easier to maintain or to extend (most of what people use COM for can be better understood as dlopen, dlsym and the rest of that API (or the almost identical Windows LoadModule functions), and in the worst case is an excuse for not fixing things in the operating systems or the languages involved (good IPC, better APIs for dealing with asynchronous event programming, etc). I'm not exactly going to advocate a return to BASIC, but remember when programming was simple and we accomplished things? Heck, I passed high school algebra on the basis of applications that I don't think I could write in a couple of evenings because now I have to worry about so much of how my application interacts with the operating system. One of the things that doing some performance tuning after reconfiguring Apache to use mod_perl taught me was that good environments make coding that easy again, and make it so that that simple coding style is what gives the best performance. When I joined the RenderMan group from coding interactive products on microcomputers I brought in my "everything has an instance handle" mentality, and wondered why the rest of the code wasn't written in that way. The optimum was definitely a compromise between the attitudes of the old-time Bell Labs folks and the newcomers, but my epiphany was that the environment should exist to support the optimum working style, and that the way we think is functionally. Unix supports that functional style very well, which is why the new ideas appear on that platform first.

I'm all in favor of simplicity. And I don't think HTTP is a good solution in this case, a C-level pipes-based interface would be fine. What Jon is saying and I'm echoing, is that a small investment across environments would pay off big. It doesn't even have to be limited to Unix, a way of integrating scripts across OSes would have a lot of value. I of course tend to look at it as a scripting problem, there are others as well, but Unix doesn't have a great GUI word processor or spreadsheet, so start with scripting and you cover a huge number of potential applications.

Actually I think the fact that Unix doesn't have a great WYSIWYG word processor or spreadsheet is precisely the break between the two types of thinking. I think of pipes as a great way to get data between one application and another because I think of information as semantic content, not visual content. It's one of the reasons my web pages are so plain. I think that the largest market lacks the visualization skills necessary to think semantically, and so they do need to be able to see what the final page is like because the people they're communicating with have the same perceptual limitations. And I think from a business perspective you're right in targeting that market. But when I compare what someone can do to large amounts of data with the tools available to them under Windows versus what I can do with an editor like Emacs (or heck, even what a good legal secretary could do with WordPerfect 5.1 for DOS), scripting a visual interface rather than starting from a strongly scripted base and adding an interface to that seems like making a Ferrari street legal. Yes, it's done, and yes, a lot of people waste a lot of money on it, but unless you're an asshole it's not going to get you through the morning commute any faster. Of course the fact that we do see the occasional Ferrari passing in the breakdown lane means that economically you have the tenable position.

Scripting scripting scripting. Forget the next-level-up. No GUI stuff. Just a common interface for adding all flavors of scripting to your favorite app. Think Apache. That's mostly what we're thinking about. Actually for me it was a lost cause a few years ago. It's refreshing to see Udell take up the cause.

On that, at least, we agree. I think we just differ over where the abstraction layer should go and how it should be resolved.

Dan: IUnknown: C'mon, how often do you actually use interface discovery in the real world? All the time, actually . Runtime interface inspection does for object types what virtual methods do for functions. It's liberating. I can't imagine writing an object system of any size without it. As far as GUIDs and inodes - huh? How exactly do you use a filesystem entry to accomplish the function of a globally unique identifier? -Mars

Do you really

use interface discovery? At some point a programmer's gotta look at a piece of documentation and say "Hey, that call takes these parameters". Sure, there are the GUIs like InstallShield and the interface to the Flash scripting, but a good portion of users talking about how they can get things done in both of these environments involves ways to trick the GUI into actually letting them enter the parameters they need to for the given command (especially in the former). And in both cases, any user who gets past the earliest rudiment is soon screaming at the GUI interface to get out of the way and give them a text file they can just edit. As I understand the need for interface discovery, it's either that or a "this function does[n't] exist", which is quite handily accomplished with a NULL back from dlsym. Educate me. Where else is interface discovery useful? (and pretty soon I'm gonna have to add a "break up this discussion into pages" function...)

Pipes are great for apps that can be used in a "fire-and-forget" mode, but they won't help you talk to long-running processes (and face it, some things do need to be implemented as long-running processes). Unix starts using local sockets in that situation (e.g. Netscape), but there's no common layer on top of that.

Nooooo... Those MSIE programmers should be punished for their double-posting software! Punished, I tell you!

One good use of the interface discovery provided by COM is well-utilized by Microsoft's development tools. Visual Basic, Visual C++, Visual InterDev (blech) and (now-defunct) Visual J++ all use it to great advantage as you code. Type in an object name and a dot and up pops a list of available methods and properties of that object. Type a few letters and hit tab. Tab completion inline in the editor is very cool. Then the list of parameters is displayed right below so you know what param and type you need in what order. You never have to look at the (possibly non-existent) docs to be sure you've got the prototype right. You don't even need the source code! Now, it doesn't tell you what the method actually does. Hopefully the programmer gave it a reasonable name... :)

I'm gonna sound like a crusty old geezer here, but I've used VMS LSE, and I've used Visual C++'s annoyingly minimal reimplentation of template expansion 15 years later (I found that the little windows always popped up in the worst possible place, obscuring source code I needed to reference to finish writing a conditional), and even when it's available I tend to turn it off. For instance I'm sure that there's one that does template expansion the way LSE did for XEmacs, but I haven't taken the hour or so it'd take to go find it and install it because once I start working under a given API there are generally only a few calls I need to make and that bit of the code gets implemented pretty quickly.

Dave W. > Scripting scripting scripting. Forget the next-level-up. > No GUI stuff. Just a common interface for adding all > flavors of scripting to your favorite app. Think Apache. > That's mostly what we're thinking about. Actually for > me it was a lost cause a few years ago. It's refreshing > to see Udell take up the cause. Well *I've* never given it up :-) When I called Dave, I was polling for perspectives on .NET. Mine is that MS had already, with the badly-named ActiveX scripting technology, made scripting language-agnostic. Not just because of COM. But because, given an agreed-upon COM-like standard -- take your pick, COM, XPCOM, ORBit/Bonobo -- you can then get to the next level: an interface which, if implemented by an app (the "ActiveX scripting" interface), guarantees scriptability by any language that holds up the other end of the interface. This is a done deal in Windows, not so in Unix/Linux. I often use the example of XMetal, SoftQuad's XML editor. By the time it came out, last year, it was just routine for a major Winapp to think in terms of exporting an object model, through the scripting interface. So out of the box I could extend XMetal in Perl, or Python, rather than the nominally-supported VBScript or JavaScript. This is just *taken for granted* in Windows, whereas w/respect to open source apps I am always hearing "so-and-so has a Perl module that works pretty well, I think Python bindings are coming, etc." And, bindings to what? There's no standard for scripting languages to aim at. That was then. Now (in an MS-friendly view) or maybe soon (in an MS-skeptical view) the language agnosticism goes to a new level, in the .NET common runtime. As interesting as that all is, I find myself reflecting on how it builds upon existing cross-language-integration stuff which is, itself, something much more than pipes.

Hmmm... Maybe I am letting some of my prejudices get in the way. Okay, Jon, you've convinced me that I've gotta spend some time installing XMetal and learning how to Perl script it to see if I'm open to the overhead of Gnome or something similar on my machine.