en
Naming conventions in programming are a touchy subject. Program text layout is equally touchy. Mere reflections on the choice of a good programming language can lead to flame wars. Procedure nesting is all but extinct.
This is a rather sorry state of affairs.
I give here my own views, they really are mine only, so don't bother to tell me I'm wrong.
What could the phrase Computer Science possibly mean? Science is the study of some part of reality with the goal to obtain a theory and laws of nature. How can this possibly apply to computers, all of which have been constructed by us humans? Should we not already know what is in them and how they operate? Computer engineering is a term I could understand, though few computers and little software seem to have been engineered. I'll quote David Pogue:
After two weeks, it finally hit me: I'm not a Mac bigot. In fact, I have no particular attachment to the Mac at all; if something superior comes along, I'm there.
No, what I am is an elegance bigot. If I'm going to sit in front of a piece of equipment for hours a day, I want to feel the intelligence that went into my operating system.
I want to sense that an English major lost sleep over the wording of the dialogue boxes. I should not have to teach my computer what kinds of files it has by adding .txt and .psd to their names. I don't want a default system font that looks like somebody drew it on the bus on his way to work.
And I want my OS components to be represented by icons that I can move or throw away—not lines of code that I must edit when troubleshooting.
David Pogue, May 1998
However, there clearly is a mathematics of computation and also a physics of computation. So that's where the science is. Three disciplines should be named correctly:
But, please, there is no such thing as computer science.
Look at the lighter side too…
The current level of complexity of software and the lack of documentation force many software authors to spend an increasing amount of time in software experiments. I find this rather frightening.
I heard one web programmer recently state that what one does is (I quote) throw masses of code at the wall and hope some of it sticks.
The only way to find out what a piece of code does seems to be to try it, and if it works, fine. If not… Many programming environments are shoddily designed, especially those used with C, C++ and above all JavaScript.
This is shameful: the failure of an entire discipline?
xkcd expressed it this way.
The term core-dump refers to something cryptic only computer geeks are supposed to understand, but I wonder how many of today's geeks actually know the origin of this expression.
In Unix and DOS (and many operating systems built in the 60s and 70s) there was a habit of indicating the type of content of a file as a part of the file name. Thus we had file names like PROGMAIN.TXT or SUB1.OBJ. In addition, filename syntax was extremely restricted: 8 uppercase characters for the name part and three uppercase characters for the type part.
The type indicating part became known as the extension.
Extensions are not enough for day-to-day use of documents in a GUI interface. Not only do you want to know that ABC.TXT is a text file, you may want the system to open it with the nedit editor rather than with emacs when you double-click it.
Another attribute is needed: the default application for that file (not for .TXT files in general, but for the specific file ABC.TXT). Apple introduced two attributes (did this come from Xerox?): the file type and the file creator. Both were separate from the file name. In its 1984 GUI, the Mac presented the object ABC.TXT as an icon with under it the name ABC only. The icon's form would be a rectangle with a dog-ear to indicate that it is a data file (as opposed to an application or a folder), inside the icon was a graphic design that indicated two things: the general design told you with which application it was created and the icon's more specific details told you what type it was within the family of documents handled by that application. Here is such a family of icons from Mac OS X, belonging to Adobe Golive (now unfortunately defunct):
 |
 |
 |
 |
| application | text document | other document | piece of code |
The general design of Golive document icons is blue and has a star, the Golive logo, in it to indicate that the creator of the documents is the Golive application. The specific designs indicate the type of each document. In fact we note that there is still more: the extension .html means both that the document is a text file and that it is in hypertext markup format. This should convincingly show that the idea of extensions of filenames was naïve: far more attributes are needed than just the type of contents to describe a file. All of these attributes are independent of a file's name. Contaminating the name with an extension is just ugly and in any case insufficient.
The icons adopted in the early Mac systems are remarkably similar to the two-level semantics of (earlier) international traffic signs and (later) MIME-types:
There are shapes for the classes of prohibition, warning and obligation (corresponding to the classes of application, document, folder):
Then there are shapes for classes like people and bicycles (corresponding to text and images):
And they can be presented in all combinations:
The idea of at least two dimensions is therefore not new at all.
Well, just read the Unix Haters Handbook (available here courtesy www.simson.net).
In a few applications, notably web browsers, as soon as I click in a text field the whole text gets selected. Then I have to click once more to place the insertion point. Where did this anomalous behaviour come from? It is present in the URL field of more and more applications.
Ever wanted to select a number of words or phrases and emphasise them by making them bold? In most text processors you could only do it on one piece of text at a time. All other applications allow you to make discontiguous selections: spreadsheets, drawing programs, even the file system. But not word processors. Fortunately this has been getting better, and now (2013) many editors do allow discontiguous text selections. Why were text processors forbidding discontiguous selections?
Aren't USB connectors ugly? (before USB-C) They are not symmetric: you must connect with the right side up. But the marking is usually not very visible and the outward shape is symmetric. There is no way to feel the orientation and anyway different manufacturers use different socket orientations. Connectors that are round with one side flat are much more user-friendly: you can feel the orientation even when you cannot see the plug, such as when it goes into a socket at the back of a device. USB plugs used to have the USB icon on top, but I have recently acquired one (2002-03) that has the icon on both sides. I now have to look inside the plug to see which way is up. Progress.
Someone said that Murphy's law guarantees that youwill always fail on the first try to stick a USB plug into a USB socket, to which someone else remarked that it actually takes three attemtps: the first one fails because you aligned the plug and socket badly, but it was actually correct, you then try the other way around, which is incorrect, and finally you get it right the third time. True.
We have now USB-C or Thunderbolt, and it is great progress.
(up to 2008) Sales people in computer shops keep proposing USB-2 devices to me because it's faster than FireWire. Nominally USB-2 runs at 480Mb/s and FireWire 400 "only" at 400Mb/s but the protocols are completely different. USB transfer goes through the CPU whereas FireWire devices can directly talk to each other (see the specification). So it was no surprise to me that transferring files to my LaCie external disk was more than twice as fast with FireWire 400 than with USB-2 (same files, same external disk, same CPU). In addition:
| USB-1 | USB-2 | FireWire 400 | FireWire 800 | |
|---|---|---|---|---|
| standard | proprietary | proprietary | IEEE 1394 | IEEE 1394B |
| nominal speed | 12Mb/s | 480 Mb/s | 400Mb/s | 800Mb/s |
| actual test (100MB file) |
135.0s | 9.66s | 4.3s | [2.3s] |
| power | adapter needed | adapter needed | from the cable | from the cable |
| can boot from disk | no | no(?) | yes | yes |
No, thanks... I'll stick to the IEEE standard.
Why do we have this? Only because of too few pixels per millimeter?
There is a separate page for that.
This is a very touchy subject, causing violent debates among programmers. I have tried to find my own set of conventions with the purpose of avoiding errors and retaining some readability and compatibility with many systems.