Tool chains versus Components
Откопал на слэшдоте (http://developers.slashdot.org/article.pl?sid=01/06/20/1216216).
Tool chains versus Components (Score:2) by Twylite (234238) <twylite@NOSPAM.crypt.co.za> on Monday June 25 2001, @03:01AM (#137487)
I think the author of this article is failing to make an important distinction between tool chains and software components.
Unix unquestionably derives enormous power from tool chains, as described by the article. But a tool chain, or part of a tool chain, is not a component.
You COULD sort your database using sort, but you don't. You COULD select records using grep, but you don't. You COULD use a perl one-liner to total accounts in your general ledger, but you don't. The reason is that these routines need to be integrated into a software application, to prevent the mess of utilities that plague legacy applications.
The answer is components. These are not discrete tools; they cannot exist alone. A component is only meaningful when integrated into a larger application.
The author would have done a lot better to draw attention to the wealth of shared libraries available on Unix, yet even these are a poor approximatation of a reusable component model, despite their obvious value.
There are many good reasons to use COM, not the least of which being that COM offers geniunely reusable object oriented components. COM is, unfortunately, a good vision but a poor implementation. Still, it is somewhat better than DLLs (MS's equivalent of shared libraries).
The «perfect solution» is somewhere out there, not that we'll ever find it. But a step in the right direction would be a compromise between shared libraries and COM (read: shared object libraries), with effective yet simple bindings in a multitude of languages.
Реквестирую флейм.