Rethinking software
Dec 1, 2013 5:22:52 GMT -5
Post by Deleted on Dec 1, 2013 5:22:52 GMT -5
Now that "Windows 8" has taken to addressing us with "Hi" and displaying images of ourselves as clothes-pegs, we realize do we not that a number of alterations and improvements must be made to the present state of programming. Urgently. Let us list them one by one, in no particular order.
1) The C language and its derivatives are inefficient and absurd. C was thought up before the time when chips were capable of multiplication and division. But since 1990 or so chips have had those capabilities, and there is no longer any good reason why assembly language should not be used. (It might be noted that around ninety-five per centum of to-day's programmers will disagree with this.)
2) The concept of a "stack" was thought up by a couple of German academics with nothing better to do, and has been vastly over-puffed. In fact there is no need to have or use a stack at all. It is simpler and better to pass arguments - and even return addresses - in registers, and to save states in preassigned and fixed memory locations. (With this one ninety-nine per centum of to-day's programmers will disagree.)
3) The idea of "multiple users" is entirely unnecessary for normal everyday use. It originated in the old old days of Unix. The same goes for the "super-user" or "administrator." In certain rare circumstances multiple users may be desirable. So . . . simply make such a configuration a mere option, a seldom-used exception.
4) "Pass words" are a juvenile comic gag and utterly out of place in the computer world. "Halt! Who goes there?" Would you permit your bicycle or motor to demand of you a "pass word" like that before you might use it? Again, in the circumstances where such over-kill may really be desirable, it could be made available as an optional and seldom-used configuration item.
5) "Forking" is a technical concept confined to the world of Unix, and very widely used therein. But forking is unduly complex and - this is the point - entirely unnecessary; it should simply be dumped!
6) "Groups" too are largely confined to the world of Unix. They too are unduly complex and entirely unnecessary; they too should be abandoned!
7) Explicit "mounting" is another Unix thing; it too is entirely unnecessary: the rubbish bin calls again does it not!
8) And one more Unix thing - the concept of a "shell" should be discarded. "Commands" - any number of them - are all that we require. Keep things simple.
9) Almost every one who has used a computer will have seen a text message flash onto his screen, only to disappear long before he has time to read it, digest it, and consider any response that may be required. There is absolutely no excuse for that. Every programmer who writes a programme that displays a message MUST give the user the chance to read that message; the programme should go no further until at least some confirmatory key has been pressed. One of the worst and least excusable examples is when pages upon pages of unnecessary garbage flash by when a system is booting. All that sort of thing must go.
10) A second point in relation to system booting is that it takes a ridiculously long time. There is no reason why the time between switching the computer on at the wall, and its being ready to use, should take any longer than one second. All the "hardware detection" that goes on is simply silly, because the configuration of a given machine rarely changes from one year to the next. Instead a special "re-detect hardware" command can be provided for use only in the unusual case where the user knows that something has changed.
11) Next comes the question of "standard directories" such as "windows/system" and "/etc" - Unix has many more of these than Windows. Get rid of the lot, and let the user decide and define his own directory structure, without exceptions!
12) And the dot and double-dot entries in directory listings constitute a confusion of purpose. They are mere abbreviations, and should not be thrown in with the real things (files and their names). Information relevant to directory structures should be displayed separately.
13) Now we come to the concept of the "PATH" - another piece of laziness thought up by idle academics! Much better to know exactly where you are going at all times. Abolish the PATH! (Again ninety-five per centum of to-day's users will object.)
14) So, we have already mentioned the (almost) instantaneous start-up, and now let us demand the truly instantaneous shutdown. Just lean over and flick the switch at the wall. No data should ever be lost, and there should be none of that silly waiting for network connections to close gracefully. The user's needs come first!
15) A programming problem: the proliferation of macros. Simply abolish them. The complexity they introduce and engender is in the end entirely unnecessary; so make them impossible.
16) Windows. Get rid of all those frames, resizings, overlappings and goodness knows what else. Simple boxes are all that is necessary. And ditch that silliest of Amercian inventions the computer "mouse"!
17) Another invention of bored academics is the concept of a dynamic library (sometimes knows as a dll). If a library must be used, just link in what you need, statically, with your programme and have done with it. No more missing libraries or endless searching for particular "versions."
18) Even when static libraries are used, often some "automatic" process will link in everything that there is in some library file, instead of picking out only the modules that are really needed. This is one of the many faults of many "C" compilers, and it is one of the reasons why many programmes are ten times larger than they should be. So make sure that the linker copies from static libraries only the parts needed.
19) When distributing your programme to its users, always ensure that you provide the complete source code. This allows users to make any alterations they wish to make. That always used to be the way until I.B.M. (and later Micro-soft) appeared on the scene with their "unbundling." - The unbundling to which I refer appeared around 1969, but I understand from Wikipædia, which calls it a "neologism," that the idea has re-emerged just recently. Here is the O.E.D.:
20) When distributing your programme to its users, never expect them to compile it themselves should they not wish to. That is to say, always provide precompiled binaries (as well as the source).
21) Never let the distinction between upper and lower case letters be significant (as Unix for instance does). For the normal operation of a computer a cat will be a Cat as will be a CAT as will be a cAt as will be a caT as will be a CAt as will be a cAT and as will be a CaT. Of course the exceptions will be when displaying messages on the screen in the user's language, or printing them.
22) Do not confuse the element number of an array with the mechanism of offsets used to implement that array in a programme. That is, the first element of a list of members, say, should be written something like: "member[1]" in any programming language (even assembly), even though the offset of that first element might be zero in memory.
1) The C language and its derivatives are inefficient and absurd. C was thought up before the time when chips were capable of multiplication and division. But since 1990 or so chips have had those capabilities, and there is no longer any good reason why assembly language should not be used. (It might be noted that around ninety-five per centum of to-day's programmers will disagree with this.)
2) The concept of a "stack" was thought up by a couple of German academics with nothing better to do, and has been vastly over-puffed. In fact there is no need to have or use a stack at all. It is simpler and better to pass arguments - and even return addresses - in registers, and to save states in preassigned and fixed memory locations. (With this one ninety-nine per centum of to-day's programmers will disagree.)
3) The idea of "multiple users" is entirely unnecessary for normal everyday use. It originated in the old old days of Unix. The same goes for the "super-user" or "administrator." In certain rare circumstances multiple users may be desirable. So . . . simply make such a configuration a mere option, a seldom-used exception.
4) "Pass words" are a juvenile comic gag and utterly out of place in the computer world. "Halt! Who goes there?" Would you permit your bicycle or motor to demand of you a "pass word" like that before you might use it? Again, in the circumstances where such over-kill may really be desirable, it could be made available as an optional and seldom-used configuration item.
5) "Forking" is a technical concept confined to the world of Unix, and very widely used therein. But forking is unduly complex and - this is the point - entirely unnecessary; it should simply be dumped!
6) "Groups" too are largely confined to the world of Unix. They too are unduly complex and entirely unnecessary; they too should be abandoned!
7) Explicit "mounting" is another Unix thing; it too is entirely unnecessary: the rubbish bin calls again does it not!
8) And one more Unix thing - the concept of a "shell" should be discarded. "Commands" - any number of them - are all that we require. Keep things simple.
9) Almost every one who has used a computer will have seen a text message flash onto his screen, only to disappear long before he has time to read it, digest it, and consider any response that may be required. There is absolutely no excuse for that. Every programmer who writes a programme that displays a message MUST give the user the chance to read that message; the programme should go no further until at least some confirmatory key has been pressed. One of the worst and least excusable examples is when pages upon pages of unnecessary garbage flash by when a system is booting. All that sort of thing must go.
10) A second point in relation to system booting is that it takes a ridiculously long time. There is no reason why the time between switching the computer on at the wall, and its being ready to use, should take any longer than one second. All the "hardware detection" that goes on is simply silly, because the configuration of a given machine rarely changes from one year to the next. Instead a special "re-detect hardware" command can be provided for use only in the unusual case where the user knows that something has changed.
11) Next comes the question of "standard directories" such as "windows/system" and "/etc" - Unix has many more of these than Windows. Get rid of the lot, and let the user decide and define his own directory structure, without exceptions!
12) And the dot and double-dot entries in directory listings constitute a confusion of purpose. They are mere abbreviations, and should not be thrown in with the real things (files and their names). Information relevant to directory structures should be displayed separately.
13) Now we come to the concept of the "PATH" - another piece of laziness thought up by idle academics! Much better to know exactly where you are going at all times. Abolish the PATH! (Again ninety-five per centum of to-day's users will object.)
14) So, we have already mentioned the (almost) instantaneous start-up, and now let us demand the truly instantaneous shutdown. Just lean over and flick the switch at the wall. No data should ever be lost, and there should be none of that silly waiting for network connections to close gracefully. The user's needs come first!
15) A programming problem: the proliferation of macros. Simply abolish them. The complexity they introduce and engender is in the end entirely unnecessary; so make them impossible.
16) Windows. Get rid of all those frames, resizings, overlappings and goodness knows what else. Simple boxes are all that is necessary. And ditch that silliest of Amercian inventions the computer "mouse"!
17) Another invention of bored academics is the concept of a dynamic library (sometimes knows as a dll). If a library must be used, just link in what you need, statically, with your programme and have done with it. No more missing libraries or endless searching for particular "versions."
18) Even when static libraries are used, often some "automatic" process will link in everything that there is in some library file, instead of picking out only the modules that are really needed. This is one of the many faults of many "C" compilers, and it is one of the reasons why many programmes are ten times larger than they should be. So make sure that the linker copies from static libraries only the parts needed.
19) When distributing your programme to its users, always ensure that you provide the complete source code. This allows users to make any alterations they wish to make. That always used to be the way until I.B.M. (and later Micro-soft) appeared on the scene with their "unbundling." - The unbundling to which I refer appeared around 1969, but I understand from Wikipædia, which calls it a "neologism," that the idea has re-emerged just recently. Here is the O.E.D.:
un'bundling vbl. n., (the introduction of) a policy of separate charging for related items.
1969 Datamation XV. 69/1 IBM ‘expects to make changes in the way it charges for and supports its data processing equipment’. The word for it is ‘unbundling’.
1971 E. F. Schoeters in B. de Ferranti Living with Computer viii. 72 These arguments are becoming academic in the light of separate pricing of hardware, software, support and staff training, commonly known by the unlovely name of ‘unbundling’.
1969 Datamation XV. 69/1 IBM ‘expects to make changes in the way it charges for and supports its data processing equipment’. The word for it is ‘unbundling’.
1971 E. F. Schoeters in B. de Ferranti Living with Computer viii. 72 These arguments are becoming academic in the light of separate pricing of hardware, software, support and staff training, commonly known by the unlovely name of ‘unbundling’.
20) When distributing your programme to its users, never expect them to compile it themselves should they not wish to. That is to say, always provide precompiled binaries (as well as the source).
21) Never let the distinction between upper and lower case letters be significant (as Unix for instance does). For the normal operation of a computer a cat will be a Cat as will be a CAT as will be a cAt as will be a caT as will be a CAt as will be a cAT and as will be a CaT. Of course the exceptions will be when displaying messages on the screen in the user's language, or printing them.
22) Do not confuse the element number of an array with the mechanism of offsets used to implement that array in a programme. That is, the first element of a list of members, say, should be written something like: "member[1]" in any programming language (even assembly), even though the offset of that first element might be zero in memory.