Nicht aufs Warten warten müssen
Was ist der größte Fehler, den Sie in Bezug auf Design oder Programmierung gemacht haben? Was haben Sie daraus gelernt?
Chuck: Vor etwa 20 Jahren wollte ich ein Tool zum Designen von VLSI-Chips entwickeln. Ich hatte auf meinem neuen PC kein Forth, daher gedachte ich, einen anderen Ansatz zu versuchen: Maschinensprache. Nicht Assembler, sondern tatsächlich die Eingabe der Hex-Anweisungen.
Ich baute den Code so auf, wie ich es in Forth getan hätte, mit vielen einfachen Wörtern, die hierarchisch interagieren. Es funktionierte. Ich nutzte das Tool zehn Jahre lang. Aber es war schwierig zu warten und zu dokumentieren. Schließlich baute ich es in Forth nach, und es wurde kleiner und einfacher.
Meine Schlussfolgerung war, dass Forth effizienter als Maschinensprache ist. Teils aufgrund seiner Interaktivität und teils aufgrund seiner Syntax. Ein netter Aspekt von Forth-Code ist, dass Zahlen durch die Ausdrücke dokumentiert werden können, aus denen sie berechnet wurden.
Welchen Ratschlag würden Sie einem Anfänger geben, damit das Programmieren angenehmer und effektiver wird?
Chuck: Nun, sicherlich nicht überraschenderweise würde ich sagen, dass Sie lernen sollten, Forth-Code zu schreiben. Selbst wenn Sie das nicht beruflich tun werden, werden Sie einige dieser Lektionen lernen und eine bessere Sichtweise auf jegliche andere Sprache erhalten. Wenn ich ein C-Programm schrieb - ich habe kaum welche geschrieben - tat ich das im Forth-Stil mit vielen einfachen Unterroutinen. Selbst wenn das teurer war, lohnte es sich meiner Meinung nach, weil die Wartbarkeit deutlich stieg.
Die andere Sache ist, das Ganze einfach zu halten. Der unvermeidliche Trend beim Entwerfen eines Flugzeugs oder beim Schreiben einer Anwendung, selbst einer Textverarbeitung, ist, Features über Features hinzuzufügen, bis das Ganze nicht mehr wartbar ist. Es wäre besser, ein halbes Dutzend Textverarbeitungen zu haben, die sich auf unterschiedliche Märkte konzentrieren. Das Schreiben einer E-Mail mit Word ist verrückt, 99 Prozent der verfügbaren Features sind unnötig. Sie sollten einen E-Mail-Editor haben. Es gab solche Editoren, aber der Trend scheint davon wegzuweisen. Mir ist nicht klar, warum das so ist.
Halten Sie es einfach. Wenn Sie mit einer Anwendung zu tun haben, wenn Sie ein Teil des Designteams sind, versuchen Sie, die anderen Leute auch davon zu überzeugen, es einfach zu halten. Greifen Sie nicht zu weit vor. Lösen Sie keine Probleme, von denen Sie glauben, dass sie in Zukunft auftreten könnten. Lösen Sie die Probleme, die Sie jetzt haben. Vorausschauen ist sehr ineffizient. Sie können sich zehn Sachen vorstellen, die passieren könnten, von denen nur eine eintreten wird. Also haben Sie viel Aufwand umsonst getrieben.
Wie erkennen Sie einen guten Programmierer?
Chuck: Ein guter Programmierer schreibt schnell guten Code. Guter Code ist korrekt, kompakt und lesbar. "Schnell" bedeutet Stunden oder Tage.
Ein schlechter Programmierer wird über das Problem sprechen wollen, Zeit mit Planung statt mit Schreiben verschwenden und auf dem Schreiben und Debuggen von Code seine Karriere aufbauen.