(A Love of Jargons)
People in the computing field like to spur the use of spurious jargons. The less educated they are, the more they like extraneous jargons, such as in the Unix ＆ Perl community. Unlike mathematicians, where in mathematics there are no fewer jargons but each and every one are absolutely necessary. For example, polytope, manifold, injection/bijection/surjection, group/ring/field.., homological, projective, pencil, bundle, lattice, affine, topology, isomorphism, isometry, homeomorphism, aleph-0, fractal, supremum/infimum, simplex, matrix, quaternions, derivative/integral, … and so on. Each and every one of these captures a concept, for which practical and theoretical considerations made the terms a necessity. Often there are synonyms for them because of historical developments, but never “jargons for jargon's sake” because mathematicians hate bloats and irrelevance.
The jargon-soaked stupidity in computing field can be grouped into classes. First of all, there are jargons for marketing purposes. Thus you have Mac OS “X”, Windows “XP”, Sun OS to Solaris and the versioning confusion of 4.x to 7 to 8 and also the so called “Platform” instead of OS. One flagrant example is Sun Microsystem's Java stuff. Oak, Java, JDK, JSDK, J2EE, J2SE enterprise edition or no, from java 1.x to 1.2 == Java 2 now 1.3, JavaOne, JFC, Jini, JavaBeans, entity Beans, Awk, Swing… f���ing stupid Java and f��� Sun Microsystems. This is just one example of Jargon hodgepodge of one single commercial entity. Marketing jargons cannot be avoided in modern society. They abound outside computing field too. The Jargons of marketing came from business practice, and they can be excusable because they are kinda a necessity or can be considered as a naturally evolved strategy for attracting attention in a laissez-faire economy system.
The other class of jargon stupidity is from computing practitioners, of which the Unix/Perl community is exemplary. For example, the name Unix ＆ Perl themselves are good examples of buzzing jargons. Unix is supposed to be opposed of Multics and hints on the offensive and tasteless term eunuchs. PERL is cooked up to be “Practical Extraction ＆ Reporting Language” and for the precise marketing drama of being also “Pathologically Eclectic Rubbish Lister”. These types of jargons exude juvenile humor. Cheesiness and low-taste is their hall-mark. If you are familiar with unixism and perl programing, you'll find tons and tons of such jargons embraced and verbalized by unix ＆ perl lovers. ⁖ grep, glob, shell, pipe, man, regex, more, less, tarball, shebang, Schwartzian Transform, croak, bless, interpolation, TIMTOWTDI, DWIM, RFC, RTFM, I-ANAL, and YMMV!
There is another class of jargon moronicity, which i find them most damaging to society, are jargons or spurious and vague terms used and brandished about by programers that we see and hear daily among design meetings, online tech group postings, or even in lots of computing textbooks or tutorials. I think the reason for these, is that these massive body of average programers usually don't have much knowledge of significant mathematics, yet they are capable of technical thinking that is not too abstract, thus you ends up with these people defining or hatching terms a-dime-a-dozen that's vague, context dependent, vacuous, and their commonality is often a result of sopho-morons trying to sound big.
Here are some examples of the terms in question:
My time is limited, so i'll just give a brief explanation of my thesis on selective few of these examples among the umpteen.
In a branch of math called lambda calculus, in which much theories of computation are based on, is the origin of the jargon _lambda function_ that is so frequently reciprocated by advanced programering donkeys. In practice, a subroutine without side-effects is supposed to be what “lambda function” means. Functional languages often can define them without assigning them to some variable (name), therefore the “function without side-effects” are also called “anonymous functions”. One can see that these are two distinct concepts. If mathematicians are designing computer languages, they would probably just called such thing _pure functions_. The term conveys the meaning, without the “lamba” abstruseness. (in fact, the mathematics oriented language Mathematica refers to lambda function as pure function, with the keyword Function.) Because most programers are sopho-morons who are less capable of clear thinking but nevertheless possess human vanity, we can see that they have not adopted the clear and fitting term, but instead you see lambda function this and that obfuscations dropping from their mouths constantly.
Now the term “closure” can and indeed have meant several things in the computing field. The most common is for it to mean a subroutine that holds some memory but without some disadvantages of modifying a global variable. Usually such is a feature of a programing language. When taken to extreme, we have the what's called Object Oriented Programing methodology and languages. The other meaning of “closure” i have seen in text books, is for it to indicate that the things in the language is “closed” under the operations of the language. For example, for some languages you can apply operations or subroutines to any thing in the language. (These languages are often what's called “dynamic typing” or “typeless”). However, in other languages, things have types and cannot be passed around subroutines or operators arbitrarily. One can see that the term “closure” is quite vague in conveying its meaning. The term nevertheless is very popular among talkative programers and dense tutorials, precisely because it is vague and mysterious. These pseudo-wit living zombies, never thought for a moment that they are using a moronic term, mostly because they never clearly understand the concepts behind the term among the contexts. One can particular see this exhibition among Perl programers. (for a example of the fantastically stupid write-up on closure by the Perl folks, see “perldoc perlfaq7” and “perldoc perlref”.)
in the so-called “high-level” computing languages, there are often data types that's some kind of a collection. The most illustrative is LISt Processing language's lists. Essentially, the essential concept is that the language can treat a collection of things as if it's a single entity. As computer languages evolve, such collection entity feature also diversified, from syntax to semantics to implementation. Thus, beside lists, there are also terms like vector, array, matrix, tree, hash/“hash table”/dictionary. Often each particular term is to convey a particular implementation of collection so that it has certain properties to facilitate specialized uses of such groupy. The Java language has such groupy that can illustrate the point well. In Java, there are these hierarchy of collection-type of things:
Collection Set (AbstractSet, HashSet) SortedSet (TreeSet) List (AbstractList, LinkedList, Vector, ArrayList) Map (AbstractMap, HashMap, Hashtable) SortedMap (TreeMap)
The words without parenthesis are Java Interfaces, and ones in are implementations. The interface hold a concept. The deeper the level, the more specific or specialized. The implementation carry out concepts. Different implementation gives different algorithmic properties. Essentially, these hierarchies of Java show the potential complexity and confusion around groupy entities in computer languages. Now, among the programers we see daily, who never really thought out of these things, will attach their own specific meaning to list/array/vector/matrix/etc type of jargons in driveling and arguments, oblivious to any thought of formalizing what the f��� they are really talking about. (one may think from the above tree-diagram that Java the language has at least put clear distinction to interface and implementation, whereas in my opinion they are one fantastic f��� up too, in many respects. 〔☛ On Java's Interface〕