Ein guter Punkt von ist die Empfehlung "pure functions", also Funktionen, die keine Nebeneffekte haben. Das kann man natürlich auch auf Methoden erweitern oder auf Klassen, d.h. Klassen, in denen außer dem Konstruktor keine Methode das Objekt verändert. Ich finde, das man ziemlich guten Code schreiben kann, wenn man solche Klassen hat. Es darf natürlich auch Ausnahmen geben, denn wir machen ja schließlich kein Haskell hier ;) Aber die Veränderung des States macht komplexe objektorientierte Datenstrukturen oft unnötig kompliziert und verursachen auch gerne mal Bugs. Wenn es performancemäßig keine Bedenken gibt, schreibe ich also gerne auch Methoden, die eine Kopie des Objektes mit kleinen Veränderungen zurückgeben, statt die Veränderungen am Objekt selbst vorzunehmen. Das sollte man mal ausprobieren, wenn man es noch nicht getan hat.

Andere Punkte von ihm sind schon seltsam. Also dass er von 1000 Zeilen langen Funktionen schwärmt und sich Sprachen wünscht, die es ihm noch leichter zu machen, so lange Funktionen zu schreiben und darin auch noch Unterfunktionen zu definieren... das kann doch keine bessere Codequalität bringen. Im Gegenteil finde ich oft, dass Code besser wird, wenn ich Funktionen aufsplitte.

(Ich habe das Video übrigens nicht ganz geguckt. Es ist ja auch ziemlich lang. Hat es übrigens einen Grund, dass ein Timestamp in deinem Video-Link drin war?)