Naja das stimmt so nicht ganz. In Haskell hast du let und where, in Python generatoren, in Erlang fun und sogar in JavaScript kannst du ja die funktion auch in einer Variable speichern die dann als macro fungiert. Oder missverstehe ich deine Definition von "Macro"?

Ja, teilweise. Generatoren würde ich auch nicht ansatzweise als Macro bezeichnen den Rest als Krücken. Meine – und ich glaube die übliche – Definition von Macro ist diese hier: Ein Syntaxkonstrukt, das vor dem Evaluieren zu einer anderen Syntax umgewandelt wird. Und diese wird dann geparst und evaluiert.

Ich sehe Macros also mehr als eine Abstraktion für den Programmierer denn für den Compiler/Interpreter. Man ist nicht mehr an die syntaktischen Konstrukte der Sprache gebunden, sondern kann was eigenes machen. Für sich selbst, für Lesbarkeit und Klarheit. Und damit ist das ein Anwendungsfall immer dann, wenn man für sich und die anderen Leser des Quellcodes Redundanz vermeiden will. Oder wenn man Dinge auslagern will.

Und warum nicht Funktionen? Funktionen haben Overhead. Aufruf, Stack, Scope, Closures, etc. Dafür sind sie ideal, aber dennoch braucht es sie für obige Anwendungsfälle nicht. Macros ziehen nur eine Ebene zwischen dem geschriebenen Quellcode und dem Evaluieren des Parsetrees ein. Und dazu kommt, dass man bei „echten Macros“ sehr viel mehr syntaktische Freiheit hat – kann man auf den Parsetree zugreifen – als bei Funktionsaufrufen, deswegen greift die reine Macros-als-vermeintliche-Funktionsaufrufe-Syntax des C-Preprozessors etwas zu kurz.

Ich hab natürlich für meine „echten Macros“ etwas vor Augen, die Macros aus den LISP-Dialekten. Lisp hat den Vorteil (und Nachteil), dass die syntaktische Struktur letztendlich nur die Text-Variante eines Parsetrees ist. Dadurch kann man diesen in Macros wunderbar manipulieren. Les mal das Macro-Kapitel aus Practical Common Lisp quer. Und staune später, was für Konstruktionen möglich sind, wie das loop-Macro, das so etwas ist, wie Pythons generator expressions oder noch besser C#s LINQ auf Steroiden. Denn wenn man die Möglichkeit hat, für sich komplexe Aktionen syntaktisch wegzuabstrahieren, kann man sehr viel mehr in sehr viel weniger ausdrücken, die Programmiersprache für seinen Problemfall erweitern und damit geeigneter und klarer machen. Von Paul Graham stammt der (sinngemäße) Auspruch, dass Programmieren in Lisp bedeutet, sich eine Sprache für sein Problem zusammenzubauen und dann das Problem geeigneter zu lösen, ich glaube aus seinem Buch On Lisp. Macros sind also eine Möglichkeit, sich DSLs zu basteln.

Und im Vergleich sind dann Funktionen oder Methoden wie in Ruby eher nur Krücken, um Abstraktionen zu erreichen. Gut, in einer massiv funktionalen Sprache wie Haskell gilt das nicht unbedingt, let und where liefern dem Interpreter/Compiler durchaus genug Informationen um Rausabstrahiertes inlinen zu können. Aber dennoch.

Das klingt wirklich danach dass du eigentlich diesen Kurs aus dem die Videos sind besuchen wollen würdest er hieß damals "Programming Paradigms" und hat mit funktionaler Programmierung angefangen ist dann über concurrent zu Imperativ und schließlich zu Objektorientiert und Logischem programmieren.

Ich les ja genügend quer und wild rum, um so ein ähnliches Halbwissen zu erlangen. Aber dennoch, neulich im Query mit CK:

„Warst Du nicht auch die letzten Jahre manchmal neidisch auf Jeenas Studienprogramm? Chalmers scheint mit all den Sprachen das viel interessanter zu machen als die deutsche Durchschnittsuni.“
„grinsendes Bejahen.“

;)