[ih] Geek Terminology (was Re: Resource sharing)

[John Day]

Indeed.  But I would think they have become more egregious.  How 
about the almost universal use of the word "topology" to mean 
"graph"?  So much so, that when in a meeting of top experts in the 
field, I was asked what I meant by the term "topological" and replied 
with one of the shorter standard definitions:  "invariant under a 
homeomorphism" I was looked at like I had horns coming out of my 
head.  (Of course, I did, but that is beside the point.)

The original use to designate graphs with a common property was 
correct.  However, that use is far less than .1% of the occurrences. 
It just sounds so much more impressive to talk about the topology of 
a network than the graph.  This has gotten so ubiquitous that you 
can't use the word correctly.  In fact, most practitioners believe it 
does mean graph.

Or the use of "architecture" to be synonymous with "hardware." 
Rather than designating a "style of construction"  IOW, a class of 
things rather than a thing.

Even the nebulous use of "cloud" rather than what it is a "data 
center."  It sounds so much more reassuring that my stuff is just out 
there in the cloud, rather stored with someone else in their data 
center.  (Even that is a euphemism).

There are many others.


At 13:54 -0600 23/12/12, Larry Sheldon wrote:
>On 12/23/2012 12:47 PM, John Day wrote:
>>>Remote Procedure Call?
>>
>>I have never been impressed with this.  First because RPC was always
>>  synchronous, i.e. blocking.  (To me this is distributed in name
>>only.) Computer scientists seem to be afraid of asynchrony. Second,
>>because it isn't a *procedure* call at all. At best it has the
>>semantics of a Fortran[sic**] function call, not even a subroutine call,
>>let alone a procedure call.  At the time I would tease the RPC
>>zealots (and they were) with either it was like co-routines in
>>Cobol[sic**} or it was an elaborate way to encode one bit
>>(request/response).  ;-)
>>
>>(I really detest the way we inflate terminology to make ourselves
>>look good.)
>>
>>Similarly, when I have asked what was the big deal about peer-to-peer
>>  [sic], a consistent answer I get as the speaker's eyes fog over and
>>he says reverently, "A Host can be both a client and a server at the
>>same time!"  Of course he is a bit crestfallen when I point out this
>>has been true since the first IMP went in.  When you boil it down it
>>turns out to be mainly a different name resolution facility, with a
>>technique for hogging bandwidth that makes it look like a DDOS
>>attack.
>
>While I have been involved in "computing machines" (starting with
>mechanical and electro-mechanical analog machines, continuing with
>telephone switching machines and networks, the digital machines parsing
>telephone book entries on a fixed-word-length machine BC*) and dealt 
>with dial-up computer networks (including 230.4 kb and 1.3 mbit) in 
>the 1970s, I did not get into Internetish stuff until the early 
>1990s.  So I missed a lot of the fun discussed here, but I have long 
>been interested in it as an old newbie might be expected to be.
>
>Focusing on "(I really detest the way we inflate terminology to make 
>ourselves look good.)" above there are several things about the use 
>terminology that have long intrigued me, especially the fact that 
>we*** have, in fact, a very limited vocabulary, and reuse terms for 
>very disparate concepts ("program", "code", "address", "relay) or 
>very similar words for disparate concepts ("thread", "string").
>
>And we used to spend a lot of time debating the nature of the tools 
>("interpreter", "assembler", "compiler") and their outputs 
>("absolute", "executable" ("dot bat"?), "relocatable", "collected", 
>"linked").
>
>And what is a CPU?
>
>*Before COBOL
>
>**I am always amused at "knowledgeable people" who don't know how to
>spell FORTRAN and COBOL, but the speelchooker in Thunderbird does.
>
>***Please forgive and forebear the arrogant use of "we", but I too 
>am guilty of the charges here.
>--
>Requiescas in pace o email           Two identifying characteristics
>                                         of System Administrators:
>Ex turpi causa non oritur actio      Infallibility, and the ability to
>                                         learn from their mistakes.
>ICBM Data:  http://g.co/maps/e5gmy        (Adapted from Stephen Pinker)