Adventskalender 8. Dezember 2022 - Doug McIlroy Facts

[Meillo]

Heute geht es um die Person, die Rob Pike den unbesungenen Helden von Unix nennt ... die Person, die Ken Thompson (selbst einer der kluegsten Programmierer ueberhaupt) ``the smartest of all of us'' nennt ...

Es geht um Doug McIlroy, dem nicht nur Shell-Pipelines zu verdanken sind, sondern zudem auch Macros. Neben Programmen, wie `diff' und `sort', die er beigetragen hat, war er es auch, der die Unix Philosophie formuliert und auf den Punkt gebracht hat:

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

Nicht zuletzt hat er sich fuer eine hohe Qualitaet der Manpages eingesetzt. Bekannt ist auch sein Ausspruch:

The real hero of programming is the one who writes negative code.

https://en.wikipedia.org/wiki/Douglas_McIlroy
https://de.wikipedia.org/wiki/Douglas_McIlroy
https://en.wikiquote.org/wiki/Doug_McIlroy


Nach dieser Vorrede komme ich nun zum eigentlichen Inhalt dieses Tuerchens: den Doug McIlroy Facts. Beispielsweise:

Doug McIlroy can get a 1 out of /dev/zero.

Doug McIlroy can hard-link across devices.

Schaut mal hier rein: https://web.archive.org/web/20110606075 ... ug=mcilroy

Falls ihr noch welche ergaenzen wollt, dann postet sie. Ansonsten schreibt gerne, welche euch besonders gefallen oder welche ihr erklaert haben wollt.

[mn77de]

Doug McIlroy supervises the hypervisor.

WOW! Man lernt nie aus! Und ja, es gibt einige (leider) unbekannte Helden da draußen, die den Weg zum Status Quo wesentlich geprägt haben.

An dieser Stelle möchte ich Dennis Richie erwähnen:

"Ritchie gehörte in den 70er Jahren zu den Miterfindern und wesentlichen Entwicklern der Programmiersprache C und des Betriebssystems Unix. Er wurde 70 Jahre alt und ist am 12. Oktober 2011 gestorben. Steve Jobs ist fast zur gleichen Zeit von der Erde gegangen und zwar am 5. Oktober 2011. Durch den wochenlangen Presse-Rummel ging der Tod von Ritchie fast unter. Dabei hat er die Computerei wohl nachhaltiger verändert als Steve Jobs. Ohne Ritchie gäbe es kein Linux, kein Windows, kein Mac OS X."

https://taz.de/Unix--und-C-Erfinder-Rit ... /!5109963/

[paedubucher]

The real hero of programming is the one who writes negative code.

Was ist damit gemeint? Jemand, der Code löscht, bzw. einen Weg findet, Code zu reduzieren? Oder jemand, der negative Fälle behandelt?

[hikaru]

Ansonsten schreibt gerne, welche euch besonders gefallen oder welche ihr erklaert haben wollt.

Oh gern!:

Doug McIlroy prototyped /dev/random with a toothpick and 4 cans of baked beans.

Das verstehe ich nicht.

Durch den wochenlangen Presse-Rummel ging der Tod von Ritchie fast unter.

Ich erinnere mich. Selbst in völlig IT-fernen Communities ging Jobs' Tod hoch und runter. Bei Ritchie hieß es nur: "Dennis ... Wer?"

[tobo]

Doug McIlroy prototyped /dev/random with a toothpick and 4 cans of baked beans.

Das verstehe ich nicht.

Das ist

Wenn Chuck Norris von einer Kugel getroffen wird, blutet nicht er, sondern die Kugel.

zur Basis 2.

[heisenberg]

Ansonsten schreibt gerne, welche euch besonders gefallen oder welche ihr erklaert haben wollt.

Das ist ein Sinn dabei? Hört sich für mich erst Mal nur wie ein Developer-Theme für Chuck-Norris Sprüche an. Also mäßig lustig.

[hikaru]

The real hero of programming is the one who writes negative code.

Was ist damit gemeint? Jemand, der Code löscht, bzw. einen Weg findet, Code zu reduzieren?

Ja. Ein guter Programmierer schreibt prägnanten (kurzen aber verständlichen) Code.

Doug McIlroy prototyped /dev/random with a toothpick and 4 cans of baked beans.

Das verstehe ich nicht.

Das ist

Wenn Chuck Norris von einer Kugel getroffen wird, blutet nicht er, sondern die Kugel.

zur Basis 2.

Danke! Ich war gedanklich noch nicht zu den Bohnen vorgedrungen, sondern hatte noch die verschlossenen Dosen vor mir. Ich bin halt kein Mathematiker.

Das ist ein Sinn dabei? Hört sich für mich erst Mal nur wie ein Developer-Theme für Chuck-Norris Sprüche an. Also mäßig lustig.

Ja, es ist ein IT-Spin der Chuck-Norris-Witze - welche auch nur lustig sind, wenn man mit dem "Kulturphänomen Chuck Norris" vertraut ist.

[Meillo]

The real hero of programming is the one who writes negative code.

Was ist damit gemeint? Jemand, der Code löscht, bzw. einen Weg findet, Code zu reduzieren? Oder jemand, der negative Fälle behandelt?

Siehe beispielsweise:

One of my most productive days was throwing away 1,000 lines of code.

Eine Meisterleistung ist es, bei gleicher (oder manchmal sogar groesserer) Leistungsfaehigkeit des Programmes, den Code zu reduzieren. Das ist gemeint. Meist gelingt das, indem man allerlei Spezialfallbehandlungen und komplizierte Datenstrukturen in etwas Generelleres und Einfacheres ueberfuehrt, das man zuvor noch nicht als Moeglichkeit gesehen hat. Wenn man mal auf die Idee kommt, dass man das Gleiche auch einfacher erreichen kann, hat man die Moeglichkeit die Codemenge zu reduzieren, ohne Funktionen zu verlieren.

Der Hintergrund ist, was Dijkstra in EWD 1036 auch beschreibt:

My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.

Und hier noch die bekannte Geschichte ueber Bill Atkinson, die es vielleicht am besten auf den Punkt bringt:

When the Lisa team was pushing to finalize their software in 1982, project managers started requiring programmers to submit weekly forms reporting on the number of lines of code they had written. Bill Atkinson thought that was silly. For the week in which he had rewritten QuickDraw’s region calculation routines to be six times faster and 2000 lines shorter, he put “-2000″ on the form. After a few more weeks the managers stopped asking him to fill out the form, and he gladly complied.

[tobo]

Also mäßig lustig.

Das ist dann wohl wie mit dem Affen und der Seife - Geschmackssache. Ich kannte die gar nicht und finde sie richtig gut...

PS: Soll das so sein, dass man mehrfach und auhc unterschiedlich abstimmen kann? (Von der unteren Auswahl könnte man eine Stimme löschen...)

PS2: Ich sehe gerade, dass bei Mehrfachnennung automatisch nur die letzte Antwort zählt. Nett.

[Meillo]

PS: Soll das so sein, dass man mehrfach und auhc unterschiedlich abstimmen kann? (Von der unteren Auswahl könnte man eine Stimme löschen...)

Ich hab gedacht, dass es nicht schadet, wenn man seine Stimme nachtraeglich aendern kann. Es ist kein mehrfaches Abstimmen, sondern nur ein Aendern der einen Stimme, die du hast.

[TuxPeter]

Jetzt habe ich erst in meinem Kopf - vergeblich - gesucht, wie der Film-Prügelknabe (also der nie Prügel bezog, sondern immer nur selber austeilte) hieß um dann mit der Web-Suche endlich auf "Wenn Chuck Norris einen Stein im Schuh hat, wird es für den Stein sehr schmerzhaft." zu kommen. Und nun sehe ich, dass das hier im Thread schon weiter oben steht ... ist ja auch naheliegend anhand der Sprüche. Aber interessanter find' ich das mit Doug McIlroy schon! Das waren schon Genies, diese frühen Pioniere.

[paedubucher]

The real hero of programming is the one who writes negative code.

Was ist damit gemeint? Jemand, der Code löscht, bzw. einen Weg findet, Code zu reduzieren? Oder jemand, der negative Fälle behandelt?

Siehe beispielsweise:

One of my most productive days was throwing away 1,000 lines of code.

Eine Meisterleistung ist es, bei gleicher (oder manchmal sogar groesserer) Leistungsfaehigkeit des Programmes, den Code zu reduzieren. Das ist gemeint. Meist gelingt das, indem man allerlei Spezialfallbehandlungen und komplizierte Datenstrukturen in etwas Generelleres und Einfacheres ueberfuehrt, das man zuvor noch nicht als Moeglichkeit gesehen hat. Wenn man mal auf die Idee kommt, dass man das Gleiche auch einfacher erreichen kann, hat man die Moeglichkeit die Codemenge zu reduzieren, ohne Funktionen zu verlieren.

Der Hintergrund ist, was Dijkstra in EWD 1036 auch beschreibt:

My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.

Und hier noch die bekannte Geschichte ueber Bill Atkinson, die es vielleicht am besten auf den Punkt bringt:

When the Lisa team was pushing to finalize their software in 1982, project managers started requiring programmers to submit weekly forms reporting on the number of lines of code they had written. Bill Atkinson thought that was silly. For the week in which he had rewritten QuickDraw’s region calculation routines to be six times faster and 2000 lines shorter, he put “-2000″ on the form. After a few more weeks the managers stopped asking him to fill out the form, and he gladly complied.

Danke für die Erläuterung; ich dachte mir schon, dass es in diese Richtung geht. Die Zitate von Thompson und Dijkstra waren mir schon bekannt, das Beispiel ist mir aber neu und sehr erhellend.

Ein ehemaliger Mitarbeiter hat mir kürzlich erzählt, dass zu unser gemeinsamer Zeit in der Firma der CEO ihn damit beauftragen wollte, ein Werkzeug einzuführen, womit man die Netto-Codezeilen pro Entwickler ermitteln konnte. Er konnte das zum Glück abschmettern. Die Entwickler sind dann doch früher oder später abgehauen

Das Reduzieren der Codmenge unter Beibehaltung der Funktionalität kann einerseits einem Genie gelingen, andererseits auch das Ergebnis einer langen Auseinandersetzung mit dem Code und dem zu lösenden Problem sein.

[Meillo]

Das Reduzieren der Codmenge unter Beibehaltung der Funktionalität kann einerseits einem Genie gelingen, andererseits auch das Ergebnis einer langen Auseinandersetzung mit dem Code und dem zu lösenden Problem sein.

Ich denke, dass das ein natuerlicher Prozess sein sollte. So wie wir bei allem was wir lernen, zuerst ungelenkt und umstaendlich agieren und erst nach und nach effektiver und effizienter werden, so ist das beim Code auch. Ein erstes Herunterprogrammieren wird immer ungelenk und umstaendlich sein, weil man ja erst noch verstehen muss, wie alles zusammenhaengt. Ueber Beschaeftigung mit der Materie und Uebung versteht man nach und nach besser, worauf es ankommt und kann dann die Ablaeufe effektiver umsetzen. Die Vorstellung, dass Code nur einmal aufgebaut wird, wie die Mauern eines Hauses, geht entweder davon aus, dass Programmieren so simpel waere wie das Mauern und die zu loesenden Probleme so einfach und altbekannt und statisch wie die Wandplanung eines Hauses; oder die Vorstellung geht davon aus, dass alle Programmierer Genies seien, so dass die das auf den ersten Anlauf gleich perfekt hinbekommen.

Ich bin also ganz deiner Meinung.


Code schreiben hat viel mehr mit dem Schreiben von Lyrik und Prosawerken oder dem Komponieren von Musik zu tun als mit dem Bauen von Haeusern. Der Software-Engineering-Ansatz ist unpassend. In der Engineering-Denkwelt wird fast nur aufgebaut aber nur wenig umgebaut. Bei Software muss vielleicht noch mehr umgebaut werden als in allen anderen Disziplinen. Das Umbauen koennte man sogar als (die) charakteristische Eigenschaft von Software ansehen. Das wird vernachlaessigt.

Um zurueck zu kommen: Weniger, genereller und simpler Code sind die beste Voraussetzung, um das Umbauen zu erleichtern. Das ist, was Doug schon frueh erkannt und propagiert hat.

[Phineas]

[off topic]

... (also der nie Prügel bezog, sondern immer nur selber austeilte)... Chuck Norris ...

Zumindest von Bruce Lee hat er kernig aufs Maul bekommen.
https://de.wikipedia.org/wiki/Die_Todes ... _wieder_zu

[/off topic]

[TuxPeter]

Code schreiben hat viel mehr mit dem Schreiben von Lyrik und Prosawerken oder dem Komponieren von Musik zu tun als mit dem Bauen von Haeusern.

Da ist es wenig überraschend, dass gute Programmierer oft eine echte Affinität zu Literatur haben. Bereits als Junge so in den frühen 60er Jahren (da seht ihr mal, was ich fürn alter Knochen bin) habe ich gestaunt, als ich einen Freund meiner Eltern, einen Engländer kennenlernte. Er sei mit den großen "Number Crunchern" beschäftigt, sagte er. Und was tat er u.a. nach seiner Pensionierung? Las das Nibelungenlied, was bekanntlich in ziemlich abgehangenem Deutsch verfasst ist. (Vielleicht ist das dem Altenglisch ja näher?)
Und in unserer LUG-Gruppe gibt es Leute mit excellenten literarischen Kenntnissen. So, ich schwafle wieder ... Was mich selber betrifft, so habe ich mir irgendwann überlegt, ob ich nun mal ein Buch oder Programm schreiben wollte.
Ich habe aber, rein von der, sagen wir mal begrifflichen Einordnung, immer ein Problem mit der Bezeichnung Programmiersprache gehabt. Eine Programmiersprache ist ein virtueller Computer, ihre Schlüsselwörter entsprechen eher den Schaltern und Reglern einer Maschine als den Wörtern einer lebendigen Sprache, und ihre vorgegebenen und sowie die vom Programmierer entwickelten Symbole haben eine exakt festgelegte, sozusagen maschinelle Extension und Intension, ganz im Gegensatz zur natürlichen Sprache, die sehr stark - historisch gesehen sogar komplett - vom sozialen Kontext aus mit ihren Bedeutungen aufgeladen wird.

Vielleicht führt da der Vergleich mit dem Komponieren und, möchte ich ergänzen, auch Spielen von Musik weiter, denn Musikinstrumente haben ja auch Knöpfe, und die Klaviatur heißt ja nicht umsonst "Keyboard".

[Meillo]

Ich habe aber, rein von der, sagen wir mal begrifflichen Einordnung, immer ein Problem mit der Bezeichnung Programmiersprache gehabt. Eine Programmiersprache ist ein virtueller Computer, ihre Schlüsselwörter entsprechen eher den Schaltern und Reglern einer Maschine als den Wörtern einer lebendigen Sprache, und ihre vorgegebenen und sowie die vom Programmierer entwickelten Symbole haben eine exakt festgelegte, sozusagen maschinelle Extension und Intension, ganz im Gegensatz zur natürlichen Sprache, die sehr stark - historisch gesehen sogar komplett - vom sozialen Kontext aus mit ihren Bedeutungen aufgeladen wird.

Ich denke, ich verstehe, was du meinst. Vielleicht ist dein Betrachtungswinkel von Programmiersprachen zu eng. Wenn du einen weiteren, entfernteren Blickwinkel einnimmst, dann sind Programmiersprachen genauso im Fluss. Auch wenn ein Wort in einer bestimmten, genau definierbaren Version einer Programmiersprache, eine eindeutige Bedeutung hat, die so in natuerlichen Sprachen nicht vorhanden ist, so veraendern sich Programmiersprachen ebenso, bilden Dialekte, haben Verwandtschaften. Wenn du dir beispielsweise das Schleifen-Keyword `for' in verschiedenen Sprachen eines Kulturraums anschaust (z.B. C, sh, awk, Go), dann sieht fuer mich der Sachverhalt recht aehnlich zu natuerlichen Sprachen aus. Dazu musst du deinen Blickwinkel aber von der nahen Betrachtung des technischen Programmierers loesen und ihn zurueckfahren zur breiten Betrachtung eines Kultur- und Sprachwissenschaftlers. Natuerlich gibt es weiterhin Unterschiede, aber die Aehnlichkeiten finde ich zumindest weit groesser.

Interessant waere es dann beispielsweise Idiome und weitere Aspekte der Sprachkultur zu untersuchen. Ein interessantes Phaenomen hierbei ist das Kommandozeilenprogramm `dd'. Hier die Anmerkungen aus Doug McIlroys Unix Reader (Seite 14):

Originally intended for converting files between the ASCII, little-endian, byte-stream world of DEC computers and the EBCDIC, big-endian, blocked world of IBM, dd was endowed with an appropriately bastard syntax (Thompson, v5). Pike has noted a cultural quirk. Much as families perpetuate the quaint sayings of children, users are wont to invoke dd with the JCL-ish formula, dd if=input of=output, or perhaps with cat input | dd of=output, but rarely with the elementary utterance dd <input >output.

Dieser ``Unix Reader'' lohnt durchaus mal einen Blick. Ein bisschen verwirrend ist, dass es allerlei verschiedene Dokumente gibt, die so bezeichnet werden. Das zitierte 15-seitige Dokument ist durchaus mal die Lektuere wert. Die 115-seitige volle Version ist da schon ein anderes Kaliber und mehr ein Nachschlagewerk. Interessant daran ist die Uebersicht am Ende, die zeigt, in welcher Version welche Tools enthalten waren. Da kann man beispielsweise sehen, dass `diff' in V5 dazugekommen ist, und `ed' natuerlich von Beginn an vorhanden war.

https://archive.org/details/a_research_unix_reader

[TuxPeter]

Es gibt, ganz gewiss, eine Menge struktureller und Ähnlichkeiten und Analogien zwischen natürlichen Sprachen und Programmiersprachen. Gerade diese Ähnlichkeiten sind es ja, die es dem menschlichen Kopf erlauben, produktiv und manchmal sogar lustvoll sich in Programmiersprachen auszudrücken, und dabei diese merkwürdig flexiblen Maschinen zu steuern, die wir Computer nennen. Dafür wurden die Programmiersprachen entwickelt, von der simplen Lochstreifensteuerung der Schalterstellungen der Registerinhalte über die mnemotechnischen Assembler-Direktiven bis hin zu hochintergrierten Konstrukten der Höheren Programmiersprachen. (übrigens ganz parallel zur Entwicklung der Integration in den Chips.)

Aber, und jetzt kommt das große Aber: Ihre Kernfunktion, ich würde sagen ihr "Wesen", wenn ich das Wort nicht hasste, ist eine gänzlich andere. Sprache ist, dem Bonmot eines der be- und verkanntesten Philosophen zufolge, das praktische Bewusstsein. Und mit praktischem Bewusstsein ist etwas Gesellschaftliches gemeint. Nun, wessen praktisches Bewusstsein wäre das nun im stummen Dialog zwischen dem Computer und seinem Programmierer? Gewiss, die Fans der "harten" KI würden sagen: "Bewusstsein - kein Problem. Haben die Maschinen schon jetzt oder bald." Aber ich glaube das nicht, und mir würden viele Gründe für solche Skepsis einfallen.

Nur so viel noch: Das entscheidende an Sprache ist doch die Kommunikation zwischen Menschen. Direkt, im Gespräch, oder zeitverzögert, wenn wir die Schrift hinzunehmen, One-Way bei den alten Medien, potentiell auch in beide Richtungen bei den neuen.

Natürlich befindet sich die Programmierung ebenfalls in solch einer gesellschaftlichen, kommunikativen Verbindung, und das ist die zwischen Programmierer und Anwender. Da hat eine Programmiersprache in Etwa eine vergleichbare Funktion wie die Ansteuerung der Stimmlippen für das gesprochene Wort. Da diese Kommunikation wie in ach so vielen gesellschaftlichen Bereichen sehr mangelhaft abläuft, gibt es so viele beschissene Programme.

[Meillo]

Ich denke weiterhin, dass du einen engen Blick auf die Programmiersprachen hast, wenn du dich so sehr auf die Kommunikation zwischen einem Einzelprogrammierer und der Maschine fokussierst. In deinem Blickwinkel scheint noch nicht vorzukommen, dass die Programmiersprache die zentrale Kommunikationsform zwischen mehreren Programmierern im gleichen Projekt ist und vielleicht noch wichtiger, zwischen einem Programmierer und seinem Selbst in der Zukunft.

Mittels der Programmiersprache formuliert man (im besten Fall) sein Problemverstaendnis und seinen Loesungsansatz fuer alle zukuenftigen Programmierer (zu denen man selbst wahrscheinlich auch gehoert). Hierbei geht es nicht um das von dir angedeutete, sehr technisch-mechanische Auflisten von Anweisungen an die Maschine, wie es in der Fruehzeit der Programmierung ueblich war (vielleicht zeigt sich an dieser Stelle dein Alter oder die Programmierkultur, die du kennengelernt hast), sondern um eine individuelle und kulturelle Art Gedanken auszudruecken.

Ich bin nun mal in dem Umfeld von Freier Software, Unix und C gross geworden, in dem Code zum Lesen da ist. Er ist also eine Kommunikationsform von Menschen zu Menschen, in einem interaktiven Prozess. Darum habe ich hierbei vielleicht eine recht andere Sicht, als du sie beschreibst. Ich denke, es kommt wohl darauf an, welche Programmierkulturen man kennengelernt hat. Bei anderen Handwerken und Kuensten ist es ja nicht anders: je nachdem was man kennt, bewertet man ganz unterschiedlich.

[TuxPeter]

ich bin nun mal in dem Umfeld von Freier Software, Unix und C gross geworden, in dem Code zum Lesen da ist. Er ist also eine Kommunikationsform von Menschen zu Menschen, in einem interaktiven Prozess. Darum habe ich hierbei vielleicht eine recht andere Sicht, als du sie beschreibst

Da mögen unsere unterschiedlichen Sichtweisen herkommen. Ich habe zwar etliche Jahre als angestellter Programmierer gearbeitet, aber Teamwork war da eher ein frommer Wunsch, keinesfalls gelebte Realität. Ansonsten bin ich da ein ziemlicher Autodidakt.
Im Team wird die Beziehungskiste zwischen Mensch und Computer dann wohl eher zu einer Dreiecks- bzw. Vielecksgeschichte. Damit habe ich meine Sichtweise zwar noch nicht aufgegeben, muss mich jetzt allerdings erst mal um mein Kalendertürchen kümmern. Möglicherweise greife ich das Thema später gerne noch einmal auf.
Nachtrag:
Kommunikation ... "zwischen einem Programmierer und seinem Selbst in der Zukunft." Das würde ich allerdings für mich auch in vollem Umfang in Anspruch nehmen.