Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Unix as a component architecture

By seebs in MLP
Wed Jun 20, 2001 at 12:04:14 AM EST
Tags: Software (all tags)
Software

IBM DeveloperWorks recently published a series I wrote about why Unix is a component architecture, and why it's a more successful one than most of the things which are advertised as component architectures. The article can be found at: http://www-106.ibm.com/developerworks/components/library/co-unix4.html


ADVERTISEMENT
Sponsor: rusty
This space intentionally left blank
...because it's waiting for your ad. So why are you still reading this? Come on, get going. Read the story, and then get an ad. Alright stop it. I'm not going to say anything else. Now you're just being silly. STOP LOOKING AT ME! I'm done!
comments (24)
active | buy ad
ADVERTISEMENT

Unix has done a better job of supporting code reuse and rapid development than the expensive, complicated, and often proprietary "object models" and "component architectures" often advertised as solving all the tough problems. This article, published by IBM DeveloperWorks, talks about the lessons we can learn from Unix's successes.

http://www-106.ibm.com/developerworks/components/library/co-unix4.html

I admit that I wrote the article, so maybe I'm a little biased, but I thought it was a good series; this is the fourth article in the series, but it's running as a feature so it's a good time to look at the series. Comments, feedback, et cetera all welcome.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Is Unix a good component architecture?
o Please, I'm not any kind of component architecture at all. 34%
o Yes. 18%
o No. 15%
o It's the best we have, anyway. 31%

Votes: 32
Results | Other Polls

Related Links
o http://www-106.ibm.com/developerworks/components/library/co-unix4.html
o Also by seebs


Display: Sort:
Unix as a component architecture | 19 comments (12 topical, 7 editorial, 0 hidden)
"Component Architecture" (4.00 / 5) (#4)
by ucblockhead on Tue Jun 19, 2001 at 06:41:24 PM EST

While I completely agree with the descriptions of Unix's strengths, and how good design practices, like building small, modular components creates them, but the title is wildly misleading in that "Component Architecture" generally means something much more specific then they pretend.
-----------------------
This is k5. We're all tools - duxup
What is a component architecture? (4.33 / 3) (#7)
by _Quinn on Tue Jun 19, 2001 at 07:56:28 PM EST

   I thought the article did a good idea of pointing out that UNIX does many of things components are supposed to; that shell script is (one of) the most widely used and successful component glue languages, and that the component architecture people may have something to learn from UNIX. To treat the example above, when was the last time you saw someone bang out a three-component program in COM without breaking stride? (wget -o- http://kuro5hin.org | grep _Quinn | less)

   Now, you can probably /do/ more with COM, but it's a programmatic thing, not part of the interface.

-_Quinn
Reality Maintenance Group, Silver City Construction Co., Ltd.
[ Parent ]
Yes... (4.60 / 5) (#8)
by ucblockhead on Tue Jun 19, 2001 at 09:25:00 PM EST

Yes, Unix does many of thing things components are supposed to do, but it, in and of itself, doesn't do all of what is normally called a "component architecture". In that sense, the title is misleading.

I'd be much happier if the article talked about how Unix piping and such could be seen as an alternative to component architectures like COM and Corba.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Nonsense (3.71 / 7) (#5)
by MSBob on Tue Jun 19, 2001 at 07:05:14 PM EST

Unix provides pipes which is the basic IPC not a component model. Just because you have a means of passing data from one process to another doesn't a component model make. The biggest flaw in your logic is in the fact that you fail to grasp the biggest advantage of component models such as COM. The fact that COM is interface bound rather than implementation bound. I can query IMediaPlayer from COM without caring if it initialises a Windows Media Player or QuickTime. This is like software plug'n'play. I as an application developer don't care what player I'm getting. The IMediaPlayer interface is the only contract between me and the service provider. With unix you're actually piping stuff from ls to grep and there is no way for you to write a script (or an app) with pipes so that you could later substitute ls for a more powerful tool and still have your script work with the new tool. There is something to be said about type safety of IDL defined interfaces. Your pipes can spew out all sorts of stuff whereas interfaces are well defined and I can rely on them at run time to always provide me with the functionality they describe. Unix is not a component model. It doesn't fulfill any requirements of a CM other than interprocess communication.
I don't mind paying taxes, they buy me civilization.

Can't substitute a more powerful tool, hrm? (3.50 / 2) (#12)
by QuoteMstr on Tue Jun 19, 2001 at 11:07:37 PM EST

I guess you've never heard of ispell and aspell. The latter is a much, much better spellchecker that can implement the same pipe interface as the former, so programs can use it transparently. What's wrong with this?

[ Parent ]
It's not the same thing (3.00 / 3) (#13)
by Quequeg on Tue Jun 19, 2001 at 11:30:02 PM EST

In order to use the more advanced aspell, you'd have to rewrite and recompile the calling application to pipe it's stream through aspell instead of ispell.

[ Parent ]
Relax. UNIX is your friend. (5.00 / 1) (#19)
by vectro on Wed Jun 20, 2001 at 11:01:22 PM EST

... Or you could just create a symlink from ispell to aspell.

“The problem with that definition is just that it's bullshit.” -- localroger
[ Parent ]
No transparency (3.33 / 3) (#17)
by MSBob on Wed Jun 20, 2001 at 12:31:44 AM EST

the change you suggest wouldn't be transparent. your script would have to be rewritten/recompiled. You could get away with clever tricks like symlinks but only up to a point. If your spiffy new util spews much more data than my old client app can parse things will break. This is the beauty of COM interfaces which are guaranteed to never change. The only way your system could possibly work is by standardising on something like xml-rpc for the pipe input and output. And you still would have to homebrew an IDL like language on the top of your xml. And you would pay a severe speed penalty compared to binary precompiled IDL. It's just not worth it. XML based marshalling is a good idea only when marshalling speed is not critical but in case of desktop components it is, so there.
I don't mind paying taxes, they buy me civilization.

[ Parent ]
A thought on the article and GUIs (3.66 / 3) (#6)
by Xeriar on Tue Jun 19, 2001 at 07:10:55 PM EST

While I think it's good to put small bits of code into their own individual functions, that in and of itself is called good programming. Taking this into the application level is only good for command-line interfaces, as users can't exactly make (rapid, reliable, easily taught) 'ad hoc programs' out of the GUI implementations.

Now, if the command-line interface could be embedded as part of the GUI itself, and dropdown-hidable whatever like the menubar in Windows is...

----
When I'm feeling blue, I start breathing again.

code reuse and UNIX (3.66 / 3) (#10)
by khallow on Tue Jun 19, 2001 at 10:27:03 PM EST

Unix has done a better job of supporting code reuse and rapid development than the expensive, complicated, and often proprietary "object models" and "component architectures" often advertised as solving all the tough problems.

I'm not so sure that UNIX has any particular claim to mastering the art of reusing code. Only the libraries really get reused on any scale above a single project. Honestly, Microsoft's libraries cover a lot more than the corresponding UNIX ones, so shouldn't Microsoft get some credit here?

Of the open source projects that I've seen, the best example of code reuse is the Apache collection of programs. It's rather impressive.

Unix code reuse... (5.00 / 2) (#14)
by seebs on Tue Jun 19, 2001 at 11:38:08 PM EST

"ls | more" is code reuse. Sysadmins write scripts, and scripts consist of reusable components tied together.


[ Parent ]
So what? (3.50 / 2) (#18)
by zakalwe on Wed Jun 20, 2001 at 06:08:35 AM EST

OK if you cross your eyes and squint, unix looks a bit like some kind of weakly typed component architecture. So what?

Too often people seem to be saying $GOOD_THING is cool, because it can has/implements/is $BUZZWORD, when the only thing that should be being considered is that it is good because it is useful.

I'll agree, the design of unix allowing me to perform powerful operations by combining simple tools is great. Personally I think this kind of high level communication is much more important and useful than what component architectures provide, but in the same way that a text editor is more useful than a hex editor. Just because one is more generally useful, it does not mean the other isn't also a good thing, and trying to pretend that they are both the same thing is idiotic.

Unix as a component architecture | 19 comments (12 topical, 7 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!