Dieser kurze Test kann Ihren Standort als Programmierer feststellen:
Eine Variable i
(C-Definition: int
i
) enthalte die Werte 1 oder 2. Erstellen Sie ein Programm, das
den Wert von i ändert. Enthält i
den Wert 1, so
wird er in 2 geändert und umgekehrt.
if (i == '2') i = 1; else i = 2;
Absolvent eines Programmierkurses
Wahrscheinlich verstehen nur 10% der Absolventen von Programmierlehrgängen den Unterschied zwischen 2 und '2'. Es ist ein Geheimnis, wie man erfolgreich programmieren kann, ohne ein so grundsätzliches Prinzip zu verstehen.
if (i == 2) i = 1; if (i == 1) i = 2;
Programmier-Ausbilder
Die Lösung ist ebenso falsch, wie die vorhergehende. Es ist fraglich, wie viele Dozenten irgend welche bedeutenden Programme entworfen, codiert und getestet haben.
if (i == 1) goto skip; i = 1; goto done;
skip: i = 2; done: ;
Erfahrener FORTRAN-Programmierer, der eben einen C-Kurs absolviert hat
Man kann einem alten Hund keinen neuen Tricks zeigen. Die Lösung ergibt ein angemessenes Resultat; mehr kann man dazu nicht sagen.
j = 2; if (i == 2) j = 1; i = j;
Assembler-Programmierer, den denselben Kurs besucht hat
An sich ist die Lösung recht gut lesbar, aber nicht gerade sehr zielgerichtet und effizient; wahrscheinlich ein Resultat des C-Trainings. Immerhin ist bemerkenswert, dass die Lösung keinen selbst modifizierenden Code enthält.
int onetwo[2] = { 2, 1}; i = onetwo[i-1];
Informatiker
Wahrscheinlich ist dies die cleverste Lösung. Da sie jedoch nicht erläutert wird, haben normale Sterbliche einige Verständnisschwierigkeiten.
i = 3 - i;
Mathematiker
Ähnlich wie die vorhergehende Lösung ist auch diese ziemlich elegant, aber ohne zusätzliche Erklärung nur schwer zu verstehen.
if(!(i=i==2?i>>1:i==1?i<<1:0))
fprintf(stderr, "falscher Wert fuer i");
Automatisierungstechniker (Dank an Tobias Tautz)
Absoluter Spitzenreiter, was die Anzahl der Operatoren angeht. Wer kennt Assoziativitäten und Präzedenzen auswendig?
i ^= 3;
Maschinenbauer (Dank an U.K.)
Hardware-naher Entwickler mit Oszilloskop am Datenbus.
i = (~(i-1)&1)+1; // ohne Kommentar
i = (1-(i-1))+1; // zu Lösung des Mathematikers
i = (i%2)+1; // Fan der modularen Arithmetik
i = (i&1)+1; // Schleichwerbung
Ein weiterer Kollege der Ostfalia (Dank an J.W.)
Informatiker mit starkem Drang zur Mathematik und den Bits.
i = i - (i/2 * 2) + 1;
Auf Arbeitsplatzsicherung bedachter Programmierer
Dies ist eine sehr kunstvolle Lösung und natürlich wird sie auch nicht erläutert. Sie funktioniert tatsächlich, aber wie Lewis Carrol sagt: "Ich hätte dies sehr viel komplizierter machen können, sagte die rote Königin ungeheuer stolz".
if (i == 2) { i = 1; } else { i = 2; }
Fan der strukturierten Programmierung
Man könnte dies als billige Polemik gegen die strukturierte Programmierung bezeichnen. Zu viele diskutieren jedoch darüber, wieviele Spalten man einrücken müsste, anstatt die Techniken richtig anzuwenden.
if ((i == 1) || (i == 2))
if (i == 1) i = 2; else i = 1; else
fprintf(stderr, "falscher Wert für i");
Guter Programmierer
Haben Sie bemerkt, dass fast keine der anderen Lösung i daraufhin geprüft hat, ob es Werte außerhalb der angegebenen Grenzen enthält. Dies is sehr gefährlich, trotzdem allgemein üblich. Unglücklicherweise helfen alle Programmiertechniken, trickreiche oder elegante Lösungen nicht, wenn i zu Beginn einen anderen Wert als 1 oder 2 enthält.
Dieser Test kam mir vor vielen Jahren in die Hand. Er war ursprünglich für PL/I formuliert, ich habe ihn dann für C umgeschrieben. Herkunft leider unbekannt.
Wenn Ihnen die Geschichte von Unix und einiger der Unix-Systemprogramme nicht unbekannt sind, sollten Sie diesen Versuch einer Einordung von Unix-Benutzern lesen.
People who come into contact with UNIX systems are often told: "If you have trouble, see so-and-so, he's a guru", or "Bob there is a real Unix hacker". Often, they are baffled by there applications, and do not purpose the matter further. What is a "Unix Hacker?" How does he/she differ from a "guru"? To answer these and other questions, I present a draft of the "UNIX Hierarchy":
insecure with the concept of a terminal
has yet to learn
the basics of vi
has not figured out how to get a
directory
still has trouble with typing RETURN after each
line
knows that
ls
will produce a directory
uses the editor, but calls it
'vye'
has heard of 'C' but never used it
has had
his first bad experience with rm
is wondering how to read
mail
is wondering why the person next to him seems to like
Unix so very much
uses vi and nroff, but inexpertly
had heard of
regular-expr's but never seen one
uses egrep to search for
fixed strings
has figured out that '-' precedes options
is wondering how to move a directory
has attempted to
write a 'C' program and has decided to stick with pascal
thinks that sdb is a brand of stereo component
knows how
to read his mail and is wondering how to read news
uses nroff with no trouble, and is beginning to learn tbl and eqn
thinks that fgrep is "fast grep"
has figured out that mv
(1) will move directories
has learned that learn doesn't
help
somebody has shown him how to write 'C' programs
once used sed to do some text substitution
has seen sdb
used but does not use it himself
thinks that make is only
for wimps
uses sed when necessary
uses macro's in vi, uses ex when
necessary
posts news at every possible opportunity
writes csh scripts occasionally
writes 'C' programs using
vi and compiles with cc
has figured out what '
&&
' and '
||
' are for
thinks that human history started with '!h'
uses sed and awk with comfort
uses undocumented features
of vi
wites 'C' code with '
cat >
' and compiles with '!cc'
uses adb because he doesn't
trust source debuggers
can answer questions about user
environment
writes his own nroff macros to supplement
standard ones
writes scripts for Bourne shell (/bin/sh)
uses m4 and lex with comfort
writes assembly code with '
cat >
'
uses adb on the kernel while system is loaded
customize utilities by patching the source
reads device
driver source whis his/her breakfast
can answer any Unix
question after a little thought
uses make for anything
that requires two or more distinct commands to achieve
has
learned how to breach security, but no longer needs to try
writes device drivers with '
cat >
'
fixes bugs by patching binaries
can answer any
question before you can ask
writes his own troff macro
packages
is on first-name basis with Dennis, Bill and Ken
This text is from the "Adventures in ... UNIX" books (Kernel Structure and Flow) from Bill Rieken and Jim Webb.