Neologisms Not Homonyms
Neologisms Not HomonymsRefactored from ComponentDefinition:
Words are often reused in a technical context in a more specialized form than the original. e.g. 'component', 'object' in computer science, or 'set', 'group', 'ring' in maths. The intent is usually to carry over some connotation from the original in order to give the reader a leg up in understanding the concept. This is not always a Good Thing, especially if the new meaning is vague enough to invite argument, or the old meaning had several other homonyms which could be taken as the connotation (e.g. object as in thing, or object as in 'subject verb object'?)
The alternative is neologism (introducing a new word). For some reason this seems to be more common in physics (eg proton, electron).
Homonyms are not always bad, particularly as parts of phrases, e.g.:
Moral of the story is: if you've got a new technical concept, which you're a bit vague on, don't give it a vague name - neologize. If you've got a precise concept, you might just be able to get away with a homonym, but think twice.
See also: DeGeneralization. A cough made-up term cough describing this particular kind of homonymn.
(started on ComponentDefinition)
I don't wish to spoil the party, but these definitions are going the way of object i.e. trying to apply specific attributes to a generic term. I find this somewhat objectionable because I don't necessarily agree with the OO value system (sorry). In physical/instance terms a component is a separable element. That's all. You may wish to add a style qualifier e.g. an OO component, but this is by no means the only way to componentize software.
'Object' - in the phrase ObjectOriented - has a reasonably specific meaning. Object, out of the context of ObjectOriented, has the generic meaning you'll find in the dictionary. Ditto for 'component' and 'component based development'. Refer back to the top of the page: 'Let this be the place in WikiWiki where we discuss the definition of a component in today's fast-moving world of ComponentBasedDevelopment.'
As you wish. The proliferation of special meanings does nothing to help people understand. It simply creates a political movement like "OO" has become. Very bourgeois with various wrangles over the "true" meaning of object, who does them, how well they do them etc etc. Here we have "component" and the turf-war immediately starts. I see this a lot in academic literature, and it sucks. Check out any of the pseudo-postmodern literature for this sort of thing. Remove the need to be new and unique (PhD! PhD! Patent! Ownership! Territory!), and the old words do just fine. A component is an identifiable part of something. Therefore it must have an identifiable boundary. That has implications to software development and so on, but save me from redefinitions of component. I've got one in my dictionary and it works great. Rant over :).
Look this up in that dictionary: context. eg on dictionary.com: 1. The part of a text or statement that surrounds a particular word or passage and determines its meaning. . Words don't stand alone. If someone tells me that they are doing component based programming, clearly they mean something specific, and I would expect a better explanation from them than 'it means I'm programming with components'. I'd want them to tell me what they mean by component in that context. The word component was clearly chosen to suggest something that can be assembled, just as object was chosen for its grammatical meaning. The words are then placed in context to specialize their meaning. The alternative way of coming up with jargon for some specific thing is to neologize, which most folk don't do. To take an example from another field, look up 'set', 'category' or 'group'. These have nice old meanings. They suggest the right things, but the old meanings wouldn't get you very far in a conversation with a mathematician, for whom they have specialized meanings, in order to express concepts succinctly.
I don't doubt the fact of the phenomenon. I am suggesting it is counterproductive for a whole bunch of reasons. Neologisms may be unsightly, but at least they are relatively honest. "Component" doesn't need specializing beyond the existing engineering term. It works as it is, a replaceable part. Just as "object" works as it is, an identifiable piece. Consider the definitions above. To me they either overspecify and end up excluding most existing (non-OO) software components already out in the wild, or they simply restate the simple engineering meaning of component, a replaceable part.
Usually, word appropriation is more irritating to the group that the word is appropriated from. Many real architects are irritated daily when they search "Architecture" on Google and find all the pages specific to Information Technology.
There seems to be a lot of political pressure to dumb things down for the roving masses. We don't want to see our invention become a buzzword, and we don't want timid clients saying "Whoa! Slow down! I'm not buying anything that uses words I don't know and makes me feel like I don't understand things." Of course, people who don't care about that kind of thing don't make neologisms. They make alphabet soup. NeologismsNotAcronyms!
That said, the only source of real neologisms these days seem to be, sadly, trademarks. "Have you ever googled your name?" for example.
Hmmmm. My ranting seems to have sprouted a page. Fair enough. No need to stop the OO boys in their holy quest. Of course this gives me license to extemporize ungrammatically <mooohahahaha>. -- RichardHenderson.
Here we go. I thinked and thinked about this. Is it a big deal? This appropriation of terms? Why is it not a good thing? Is it possible to find a middle way here? So I thinked and thunked and thanked and thonked my head against the words until I found the smallest knot, it lived in the word "definition". If I tweaked that word out, and inserted "description", then I had a middle way. "Words should follow nature", I thought. We observe a thing, then we describe it in words. We add words to qualify. Thus a SoftwareComponent is a component of software. It needs no redefinition. It needs description maybe, answer the question "What sort of animal is this?" The existing definition suffices, it provides the appropriate level of conceptual context. The alternative is to redefine the word so only a trace of its original meaning remains. It turns a conceptual thing into a physical thing, removing the heart of it, removing its power to communicate.
With the word "component", we already have a useful meaning. I consider that any redefinition actually reduces its value; a similar argument applies to "object".
A component is defined as a part of something. This isn't quite enough however. The Latin root relates to the verb "to put", so we get a sense of a placeable part. A part which may be put together with other components to make up some system. That is how the word is commonly used in engineering, and software is an engineering activity. We design/make/use engines that perform tasks. Inevitably we use components to do this. We compose prebuilt parts to make up a larger system. These systems may themselves be components of a larger whole and so on. So far that sounds like objects, but an objects primary attribute is identity. A component must also be placeable.
So, a software component, using the existing definitions, is a (re)placeable software part. That is all. No more is required. We may immediately move to describing components. Different programming styles will have different problems generating parts which may be replaced. Furthermore we can ask about when all this composition takes place. The current drive in software is to have some degree of dynamic composability, using a generic interface. This is a recent trend, however. DLL's are alive and well, as are exotica like loadable kernel modules and firmware interfaces. They all belong. They are all software components. Binding occurs at any time. Programming is a static composition activity. Deploying is semi-dynamic, and component servers are fully dynamic. We need not exclude any component from the family. Which is good. Exclusion leads to conflict.
Interestingly, if we use the existing generic terms for "object" and "component", an object in the OO sense is actually a component, defined using classes and suchlike. This frees the term "object" to go back to meaning an identifiable part, a thing with a boundary and an identity. The family of objects may now comfortably include any programming entity. No more arguing over whether an object is an object because you can't polymorph it or inherit it. We can just say whether it is an object of the people or the priesthood ;). Perhaps OO folk would prefer "class oriented"? No. I didn't think so :).
Back to component. If we can get past trying to redefine the language we can get back to describing the families of software components, their relationships, their good bits and bad bits, how they are described in the various styles and programming paradigms already. This sounds like a lot more fun to me than philosophising over what is the "one true component". That is ideology and I've got a job to do. -- RichardHenderson
I'm going to own up as the person who ranted back. I wrote the summary at the start of this page mainly to agree with you. I don't think its useful to appropriate vague terms to describe vague concepts. By the dictionary definition of component, we've been working with them since the 60s. I don't think the people who appropriated 'component' would argue that one back. The trouble is that these words are being used to describe specific claimed innovations. I'd like to have these people explain what these innovations are, and frankly I don't care if they call it component-oriented or boondoggle-oriented. However, jumping into an explanation of what they do mean, and trying to argue the case for the old meaning doesnt help me to understand what they're trying to get across at all.
An analogy might be to stand up in a lecture where someone is explaining the C 'switch' statement, and try to convince the audience that a switch only has two states - on and off - and that's a good enough definition to go with, so the lecturer should pipe down. Your argument would probably be that future new homonyms should be banned, mine that past uses of homonyms should be explained. However your contribution on ComponentDefinition came close to arguing that past uses of new homonyms should be banned.
Further, I would argue that your position can be dangerous, since the meaning of the 'new homonym' can be lost in this constant recourse to the analogy of the old meaning. For OleJohanDahl and KristenNygaard objects were something specific. They accepted messages and acted on 'their' data. They were simply structures which encapsulate state and behaviour. However, attempts to use definitions closer to (one of) the dictionary meanings have led to the one you gave above (a thing with a boundary and an identity - IIRC this comes from Booch's book?), a phrase so nearly devoid of meaning that people lose sight of what objects added to our armoury. It seems to be only in type theory that objects still stand for the original 'new homonym'; because you can't apply mathematics to snake oil.
Back to component. If we can get past trying to set the language in stone we can get back to describing the families of software components, their relationships, their good bits and bad bits, how they are described in the various styles and programming paradigms. This sounds like a lot more fun to me than philosophising over what is the "one true meaning of component". That is ideology and I've got a job to do. -- BrianEwins
Yes sir. I believe we are agreeing violently, or at least on the same page. There is a tension between the old and the new, I see no reason to add to it. Inevitably language changes, but I prefer a change based on convention to one based on assertion. This is an aesthetic consideration but I find the particular value system very useful. Furthermore an existing meaning, while unclean and imprecise, has the greatest chance of being understood, furthermore I just don't think we need to do it.
Considering "object". An identifiable thing (the common definition, Booch might have read a dictionary). OO is predicated on data and behaviour being part of a physically coherent lump. Cohesion and identity (more correctly identifiability) are the same thing at a physical level. This physical cohesion was then extended to logical definitions of objects such that the physical cohesion was in the specification (as textual cohesion) rather than the expression of that specification. Thus it is "object orient[at]ed". No redefinition of "object" required. Why bother? Does it add anything? I think not. So we start with encapsulation and identity as direct implications of "object". The trouble starts when we try to lever other attributes into the definition. For example, many OO definitions of "object" exclude structured data due to the lack of intrinsic behaviour. Why? How is something less an object because it doesn't do something? And so on. Redefinition tends to exclude. This exclusion, where before there was inclusion, is unhelpful. And unnecessary.
In my world "objects" are any identifiable programming entity, and life is a lot easier. No arguments. 'C' struct an object? Sure. Machine-code subroutine? Sure. Come on down. No object excluded. I might be particularly fond of objects of a particular style, but saying that things without mechanism are not objects? You end up with objects which aren't objects. Not so good and unnecessary.
Turning to "component". The basic definition, of a [re]placeable part. Is that generic so non-useful? It works fine for all other large-scale engineering. Most of the arguments about the definition of "component" are trying to lever in exclusive extras which misses the point of a generic, it is inclusive. So we have the same problem where redefinition leads to contradiction.
I start from the concept of a [re]placeable software part. I think of the Who/What/When/Where/Why/How's and I am up and running. I think of what would make a software component good or bad. These are the same goals we all have, I think. I find the redefinition of terms to be a SocialAntiPattern?, approached with extreme caution, and avoided as often as possible. Consider it a premature optimisation. YAGNI. -- RichardHenderson
This page may or may not be that related to AvoidNeologisms.
EditText of this page
(last edited November 7, 2014)
or FindPage with title or text search