Ich liebe Lisp. Richtig, das 'ineffiziente', 'schwer verständliche', vom 'Mainstream' weit entfernte und 'klammerbesessene' Lisp. Ich liebe es schamlos.
Lisp ist natürlich die mächtigste Sprache, die es gibt. Stimmt, was wie eine seltsame Syntax aussieht, ist in Wirklichkeit eine knappe Syntax, die ein hohes Maß an Konfigurierbarkeit ermöglicht. Während Sie es wahrscheinlich gewohnt sind, eine Kombination aus Schlüsselwörtern und Interpunktion zu formulieren, um Ihre Ideen zu vermitteln, kodieren Sie in Lisp direkt in Parse-Bäumen, die von Compilern anderer Sprachen erzeugt werden. Listenprogramme sind Listen (von Listen von Listen...) und die Parse-Bäume von Lisp sind ebenfalls Listen und die Erzeugung von Parse-Bäumen im Code ist daher sehr einfach.
Ein Programm, das einen Parse-Baum generiert und/oder manipuliert, ist praktisch ein Programm, das Programme (neu) schreibt. Das mag wie ein Gimmick erscheinen, das nur in einem Spiel um die Trümpfe der Geeks von Bedeutung ist, aber es eröffnet tatsächlich einen ganz anderen Stil der Programmierung. In Lisp sind Sie nicht darauf beschränkt, ein Programm in Richtung der Sprache zu schreiben, sondern Sie können auch die Sprache in Richtung des Programms aufbauen. Wenn Sie jemals denken: "Mensch, ich wünschte, ich hätte dieses oder jenes Konstrukt, um mein Problem zu lösen", dann können Sie dieses Konstrukt schreiben, um dieses spezielle Problem zu lösen. Und unweigerlich werden Sie feststellen, dass die Verwendung dieses neuen Konstrukts den Entwurf eines anderen Teils des Programms vereinfachen würde, und so weiter und so fort: Sprache und Programm entwickeln sich gemeinsam weiter. Am Ende haben Sie ein Programm, das so aussieht, als wäre die Sprache speziell dafür entwickelt worden. Und dass Sprache und Programm optimal zueinander passen, sorgt dafür, dass der Code so klar, klein und effizient wie möglich bleibt. Nur sehr wenige Programmiersprachen unterstützen dieses Bottom-up-Design in dem Maße wie Lisp.
Der Ausdruck 'Design' steht absichtlich dort: um zu betonen, dass es nicht darum geht, dasselbe Programm in einer anderen Reihenfolge zu schreiben, sondern dass das resultierende Programm sehr, sehr anders strukturiert ist. Am Ende haben Sie eine größere Sprache mit abstrakteren (wage ich zu sagen: domänenspezifischeren?) Konstrukten und ein kleineres Programm, das in dieser Sprache geschrieben ist. Und ein kleineres Programm muss nicht in so viele Komponenten aufgeteilt werden. Weniger Komponenten bedeuten, dass das Programm leichter zu lesen und zu ändern ist und dass es weniger Verbindungen zwischen den Komponenten gibt und somit weniger Fehler auftreten können. Klein ist schön, und um Schönheit geht es.
Natürlich habe ich noch nie (nie!) Lisp in einem bezahlten Job eingesetzt. Und ich vermute, Sie haben das auch nicht. Das bedeutet, dass Sie und ich etwas sehr Wichtiges verpasst haben: die Möglichkeiten der serverseitigen Programmierung. Als ich mit dem Programmieren anfing, gab es nicht wirklich eine große Auswahl an Sprachen, die man für das Schreiben von Anwendungsprogrammen verwenden konnte. Damals bedeutete "Anwendungen" in der Regel, dass man Software für Desktop-Computer schrieb, und bei Desktop-Software gab es eine starke Tendenz, die Anwendung in der gleichen Sprache wie das Betriebssystem zu schreiben. Vor fünfzehn Jahren wurden in meiner Welt die Anwendungen in C/C++ geschrieben. Dann kam das Web und diese Dinge änderten sich: Bei serverbasierten Anwendungen ist es viel einfacher, die Technologie (Sprache, Betriebssystem, ...) zu verwenden, die Ihnen gefällt. Perl, PHP, Python, Ruby: Sie alle bekamen ihren Platz unter der Sonne, weil die Leute sie auf Servern einsetzten und nicht, weil sie für Desktop-Anwendungen verwendet wurden. Die Verlagerung von Software auf Server bedeutet einfach, dass weniger Druck besteht, Mainstream-Technologien (oder durchschnittliche oder mittelmäßige Technologien) zu verwenden.
Wenn sich das halbwegs vernünftig anhört, dann nur im Nachhinein, denn in den letzten 7 Jahren habe ich ausschließlich (und bis zu einem gewissen Grad unentschuldbar) serverbasierte Anwendungen mit dem Mainstream-Java-Stack entwickelt. Ich brauchte den Weckruf von Ruby on Rails, um mir die Vorteile von Lisp zu vergegenwärtigen. Ruby erlaubt es natürlich auch, die Sprache während der Laufzeit von innen heraus zu erweitern. Bei Rails wurde die Ruby-Basissprache abstrahiert, so dass das Problem der effektiven Erstellung von Webanwendungen und die Lösungssprache besser zueinander passen. Angesichts des ungebremsten Erfolgs von Rails sind die Vorteile (und Freuden!), die sich daraus ergeben, für viele Menschen offensichtlich. Und es sind die Bottom-up-Design-Fähigkeiten von Ruby, die das alles möglich machen. Deshalb heißt es auch Ruby on Rails und nicht Rails on Ruby (eine Tatsache, die dem Projektteam von Trails entgangen sein könnte).
Ruby und Groovy sind natürlich kein Lisp (die Makros von Lisp sind wirklich etwas anderes), aber sie sind effektiv genug, um die Früchte des Lisp-Stils zu präsentieren, so dass Java als Sprache, nun ja, klobig aussieht. Und zwar so klobig, dass ich es nicht ertrage, Java ohne die Bearbeitung und das Refactoring von Eclipse zu programmieren. Dennoch schätze ich die Java-Plattform mit ihren vielen großartigen, bewährten und gut verstandenen Technologien für objektrelationales Mapping (Hibernate, JPA), Anwendungskonfiguration (Spring) und Transaktionen (JTA), um nur einen Bereich zu nennen. Alle diese Technologien lassen sich natürlich perfekt mit Groovy und JRuby adressieren, so dass Sie Java - die Sprache - ablösen und gleichzeitig Java - die Plattform - nutzen können. Was gibt es da nicht zu mögen?
Lisp. Ruby oder Groovy... Ich würde sagen, die Zukunft der serverseitigen Programmierung ist funky!
Verfasst von
Ron Kersic
Contact
Let’s discuss how we can support your journey.



