Ja, jeden Freitag ein Video, wir allerdings sehen, wie wir weitere Serien unterbringen.

Ich selbst hab nie professionell mit funktionaler Programmierung gearbeitet, weil es nie eine Anforderung von Unternehmen war. Aber ich sprech mit meinem Kollegen, der darin Experte ist. Vielleicht machen wir dann mal eine eigene Serie zu FP.

@@MemoryLeekDE Wie wäre es generell erstmal die verschiedenen Programmierparadigmen vorzustellen? Ich kann wohl einigermaßen den Unterschied von deklarativen zu imperativem Code verstehen, aber der Unterschied zwischen funktional und objektorientiert, da wirds echt schwammig, wenn man ehrlich ist. Der Rückgabewert einer Funktion ist letzten Endes ein Objekt. Und ein Objekt besteht widerum aus Funktionen

Wir werden liefern :)

Wir sind dran, ein wenig wird es aber schon dauern, weil wir erstmal bei 1 Video / Woche bleiben.

Auf jedenfall. Wenn man einmal alle kennt, dann hat man sehr viele Aha-Erlebnisse in Bibliotheken, die man sich importiert. "So haben die das also implementiert ..."

Der häufige Fehler ist nur, daß man mit Kenntnis der Entwurfsmuster nur noch in diesen Mustern denkt. Oft sind ganze Teams darauf fixiert. Unbestritten ist es gut, sich mit den Mustern auseinanderzusetzen, um eine Idee zu bekommen, wie man etwas umsetzen _könnte_ und welche Vor- und Nachteile daraus resultieren. Noch wichtiger finde ich die Anti-Patterns. Da sollte man sich mit der Diskussion auseinandersetzen, wieso die sich als problematisch erwiesen haben. Viele der Anti-Patterns galten einmal als tolle Designpatterns. Ich persönlich würde z.B. das Singleton zu den Antipatterns zählen - wird leider immer noch als super Designpattern gehandelt. Entwurfsmuster sollte man auch immer in Hinblick auf die Sprache beurteilen. In modernen dynamischen Skripten sind sehr viele Designpattern hinfällig und unnötiger Overhead - sowohl in der Entwicklung als auch zur Laufzeit.

Ich freu mich, dass du mit an Bord bist!

Nach Jahrzehnten OOP hinterfrage ich sogar das Konzept insgesamt. Erst einmal mußte ich beim Einstieg in OOP feststellen, daß es nichts Neues unter der Sonne war. Verbundvariablen (records) gab es schon in Turbo Pascal. Die hat man an eine Funktion übergeben. Nun kam Syntax-Sugar hinzu, daß man die Funktion (Methode) direkt ans Objekt klemmen konnte. Neu waren nur die Zugriffsmodifikatoren. Tolle Sache, man konnte beim Entwurf festlegen, welche Methoden und Eigenschaften als Schnittstelle gelten. Außerdem ersparte einem die Vererbung einiges an Tipparbeit. Mittlerweile gilt Vererbung im Sinne der Kopplung ja schon wieder als ganz ganz böse. Mit der Zeit stellt man aber fest, daß die Zugriffsmodifikatoren eine Selbstbeschränkung sind, die im späteren Projektverlauf häufig zu riesigen Workarounds und Abstraktionen führen. Da frage ich mich oft: Wäre es nicht sinnvoller, Klassen zu dokumentieren und sich möglichst an die gedachten Schnittstellen zu halten. Manchmal tritt dann der Fall auf, wo vielleicht doch mal ein Eingriff in die Mechanik ein Problem ganz simpel lösen könnte. Auch solche "Mißbräuche" müssen dann dokumentiert werden. (Beim guten alten abgesoffenen Vergaser steckte man einen Schraubenzieher in die Kaltstartklappe, und der Wagen sprang an. War so nicht vorgesehen, aber funktionierte.) Ich bin der Meinung, man könnte auch "schmutzig" einigermaßen wartbaren, zukunftsträchtigen Code schreiben, und das oft viel schneller und auch laufzeitperformanter. Diese ganze Selbstbeschränkung und Schutz vor dem Team sehe ich heute sehr ambivalent. Eigentlich ist es Ausdruck von wenig Vertrauen in die Kompetenz. Ich stelle mir manchmal vor, ein hochintelligenter Außerirdischer sieht sich den Code an. Er würde auch verworrenen Spaghetticode schnell überblicken und wahrscheinlich sogar so programmieren, weil es für ihn ein triviales Problem ist. Dann sieht er Unmengen an "strukturierendem" Code, der keinerlei Funktion hat.

Wir sind vor 2 Wochen gestartet. Schau in 2 Wochen nochmal ;)

Genau der ist das! Die Großen Denker im Softwarebereich aus dieser Zeit haben oft wirklich großen Impact in vielen Bereichen gehabt. Zeitgenössische Denker sind offensichtlich immer schwerer einzuschätzen!

@@MemoryLeekDE Haha ja :D Gefühlt habe ich in meiner Thesis immer wieder nur die Namen, Kent Beck, Uncle Bob, Erich Gamma etc. gelesen. Es ist auch echt interessant, wie "klein" die Szene dann doch wieder ist.

Ich habe mich oft dabei entdeckt, Iteratoren zu Schleifen umzuschreiben, und die Laufzeit hat sich ganz erheblich verbessert - die Lesbarkeit als Nebeneffekt auch. In der Programmierung bin ich ein Ressourcengeizhals.