Rob Pikes Programmierregeln (1989)

• Ein Artikel über Rob Pikes fünf Programmierregeln aus dem Jahr 1989
• Regel 1: Gehe nicht davon aus, wo ein Programm die meiste Zeit verbringen wird; Engpässe können unerwartet auftreten. Vermeide Speed-Hacks, bis ein Engpass nachgewiesen ist.
• Regel 2: Miss immer zuerst, bevor du auf Geschwindigkeit hin optimierst. Optimiere nur, wenn ein Teil des Codes einen erheblichen Einfluss auf den Rest hat.
• Regel 3: Komplexe Algorithmen sind langsam, wenn n klein ist. Das ist in den meisten Fällen so. Verwende komplexe Algorithmen nur, wenn n häufig groß ist, und wende auch dann zuerst Regel 2 an.
• Regel 4: Einfache Algorithmen und Datenstrukturen sind wünschenswert. Sie sind weniger fehleranfällig als komplexe und leichter zu implementieren.
• Regel 5: Die richtige Datenstruktur ist entscheidend für das Programmieren. Wenn die Daten gut strukturiert sind, wird der Algorithmus offensichtlich.
• Pikes Regeln 1 und 2 spiegeln Tony Hoares Diktum wider: "Vorzeitige Optimierung ist die Wurzel allen Übels."
• Ken Thompson formulierte Pikes Regeln 3 und 4 neu als: "Im Zweifel setze rohe Gewalt ein."
• Regeln 3 und 4 setzen die KISS-Designphilosophie (Keep It Simple, Stupid) um.
• Regel 5 stimmt mit einer Aussage aus Fred Brooks' The Mythical Man-Month überein, die oft verkürzt wird zu: "Schreibe dummen Code, der intelligente Objekte verwendet."

[GN⁺]

Hacker-News-Kommentare

• Ein Artikel über Rob Pikes Programmierregeln aus dem Jahr 1989
• Die Kommentierenden stimmen darin überein, dass der Kern des Programmierens eher Datenstrukturen als Algorithmen sind
• Kritik daran, dass LeetCode-Interviews sich nicht stärker auf Datenstrukturen als auf Algorithmen konzentrieren
• Die Behauptung, dass komplexe Algorithmen langsam sind, wenn n klein ist, und dass n in den meisten Fällen klein ist
• Die Kommentierenden betonen, wie wichtig die Wahl geeigneter Datenstrukturen und eine gute Ordnung sind
• Diskussion über den Missbrauch von Datenbanken und die negativen Auswirkungen von durch ORM erzeugten DB-Schemata
• Die Richtlinien wirken wie eine Strategie, um Overengineering und verfrühte Optimierung zu vermeiden
• Einige Kommentierende behaupten, dass sich kleine Verschwendungen bei der Performance summieren und Programme verlangsamen können
• Debatte über das Zitat „Vorzeitige Optimierung ist die Wurzel allen Übels“ und seinen Kontext
• Einige Kommentierende behaupten, gute Programmierer könnten vorhersagen, was langsam werden wird, und im Voraus lehrreiche Wetten abschließen
• Der Einwand, dass komplexe Algorithmen für einfache Daten große Performancegewinne bringen und sogar vereinfachen können
• Der Artikel hat den Ansatz mancher Leser in Bezug auf Design und Komplexität nachhaltig beeinflusst
• Diskussion über die Auslegung von Regel 5 und einige Uneinigkeit über die Formulierung „Schreibe dummen Code, der intelligente Objekte verwendet“