Posts tagged ‘Lisp’

S.O.L.I.D. for dynamic and functional languages at SoCraTes 2011

At the SoCraTes 2011 conference I facilitated a session about applying the S.O.L.I.D. design principles to dynamic OO languages and to functional languages.

I prepared some Flipcharts with the SOLID principles (Slideshare), code examples for Java, Ruby, Scala and Clojure (GitHub) and a paper with a description of the SOLID design principles and some thesis about their application to dynamic OO and functional languages (PDF).

I am not sure if the session can be counted as a success. We had three groups. One was working on the application of SOLID to dynamic OO languages with the Ruby code examples. The second group was working on the application of SOLID to statically typed functional languages with the Scala code examples. The third group worked on the application of the SOLID principles to dynamic functional languages with the Clojure examples.

The results were ambiguous and we didn’t find final answers. What became clear is that the SOLID design principles can be applied to all these types of languages. What stayed fuzzy was the question if that application would be useful for the everyday work with these languages. While I tend to think that in fact not every principle is useful in every languages there were others having the opposite opinion.

One of the problems within the workshop was that today OO thinking is baked into out heads. And so the Scala and the Clojure group created designs in OO style. And if you do that with a functional language of course SOLID is applicable and at least to a certain degree useful 🙂

In the end of the session we had a discussion in a smaller group of people if it may be to misleading to apply SOLID to functional programming. Perhaps it drives our thinking in the wrong direction. Perhaps it would be better to go back to the underlying principles of cohesion and coupling and creating new design principles for functional languages on top of these. And perhaps such design principles already exist and I am just to blind to see them.

So: There is still a lot to learn and a lot of experiments to do. If you like to contribute I would really much appreciate it.

 

 

September 9, 2011 at 3:12 pm 2 comments

Buchtipp: Practical Clojure

Wenn ich mit meinem vorigen Blogpost den einen oder anderen neugierig auf Clojure gemacht habe, gibt es hier gleich noch das passende Buch. “Practical Clojure” von Luke VanderHart und Stuart Sierra führt prägnant und kurz in die Sprache Clojure und die zugehörigen Bibiotheken ein. Das Thema Parallelität mit Clojure wird ausführlich behandelt.

Das Buch kommt schnell auf den Punkt. Für jemanden, der Lisp noch nie gesehen hat und für den funktionale Programmierung ganz neu ist, könnte das Buch evtl. etwas schwer verständlich sein.

 

November 22, 2010 at 7:26 pm Leave a comment

Clojure lernen

Um gedanklich nicht einzurosten, sehe ich mir dann und wann eine neue Programmiersprache an. Diesmal war Clojure an der Reihe. Clojure ist eine funktionale Sprache, die auf der Java VM läuft. Und letztlich ist Clojure nicht wirklich eine neue Programmiersprache, sondern ein Lisp-Dialekt. Clojure bietet an der einen oder anderen Stelle syntaktischen Zucker, so dass der Quelltext etwas aufgelockerter aussieht (nicht soviele runde Klammern) und dadurch für Lisp-Neulinge leichter lesbar ist. Ansonsten ist Clojure aber ein vollständiges Lisp, das sich im Gegensatz zu Common Lisp aber zu beschränken weiß: kein Mega-For-Konstruktur, kein CLOS, etc. Und einige Antiquitäten sind moderneren Einrichtungsmöbeln gewichen: car heißt jetzt first und cdr heißt tail.

Ich finde, das Resultat ist eine einfache, fokussierte Sprache, die einfach zu lernen ist und Spaß macht. Dazu trägt auch bei, dass Clojure bewusst funktional ist und kein OO-Hybrid. So wird man als OO-Entwickler gezwungen, sich einer anderen Perspektive beim Programmieren zu öffnen und das ist auf jeden Fall nützlich – und sei es nur zur Horizonterweiterung.

Neben der eigentlichen Sprache bietet Clojure einige eigene Bibiotheken, insbesondere für die Programmierung paralleler Algorithmen. Durch die funktionale Struktur von Clojure-Systemen gestaltet sich dieses Themengebiet in Clojure viel einfacher als z.B. in Java. Ich bin zwar der Meinung, dass parallele Algorithmen im Moment deutlich überschätzt sind. Aber wenn man meint, dass man es braucht, dann sollte man sich Clojure auf jeden Fall mal ansehen.

Und wenn man keine parallelen Algorithmen braucht, sollte man sich Clojure auch ansehen und z.B. die eine oder andere Code-Kata in Clojure programmieren. Es hat schon seinen eigenen Charme, vollständig funktional zu programmieren.

 

 

November 22, 2010 at 7:19 pm 3 comments

Terminplaner in Prolog

Ich habe meine Prolog-Kenntnisse aufgefrischt und dazu das Terminplaner-Beispiel in Prolog implementiert. Die geringe Anzahl Lines of Code (LoC) der Prolog-Lösung finde ich ziemlich beeindruckend. Ich habe die Größe der Lösung in den verschiedenen Programmiersprachen mal gegenüber gestellt (LoC: ohne Leerzeichen und Kommentare).

Sprache LoC LoC Tests
Java 187 109
Groovy 155 79
Ruby 141 90
Lisp (CLOS) 63 77
Prolog 34 93

LoC ist sicher kein besonders gutes Maß, um die Mächtigkeit einer Programmiersprache zu bewerten. Wenn man allerdings nur 34 Zeilen braucht, wo man sonst 150-200 Zeilen braucht, finde ich das schon ziemlich denkanstößig.

Der Code steht unter github bereit: http://github.com/stefanroock/Terminplaner/tree/master (Achtung: Die Python-Lösung funktioniert noch nicht).

July 13, 2009 at 7:30 pm 5 comments

Buchtipp: Practical Common Lisp

Peter Seibel führt mit Practical Common Lisp anhand praktischer Beispiele (Unit-Testing, MP3-Dateiparsing, Web-Anwendungen etc.) in Common Lisp ein und zeigt damit eindrucksvoll, dass Common Lisp keineswegs auf künstliche Intelligenz oder funktionale Programmierung beschränkt ist.
Das Buch gehört zu den sehr wenigen IT-Büchern, bei denen das Lesen Spaß macht.

Auch wenn man selbst nicht mit Common Lisp arbeiten wird, öffnet das Buch ganz neue Perspektiven. Es ist schon erstaunlich, wie weit Common Lisp seiner Zeit voraus war und noch ist. Ich kenne keine andere Programmiersprache, die so mächtige Features hat wie Common Lisp.

Das Macro-System (nicht zu vergleichen mit dem C-Macros) erlaubt die Definition eigener Sprachen in Common Lisp – ein Ansatz, der heute als DSL (Domain Specific Language) bekannt ist und mit vergleichsweise wahnsinnig hohem Aufwand und Code-Generierung betrieben wird.

So kann man eigentlich bei jedem Feature anderer Programmiersprachen sagen: “Das hat Common Lisp auch, nur mächtiger und flexibler.” Da stimmt es mich schon etwas traurig, dass sich Common Lisp nicht in der Breite durchgesetzt hat und man heute noch mit vergleichsweisen Krücken unterwegs ist.

Da drängt sich natürlich die Frage auf, warum wir dann nicht einfach alle in Common Lisp programmieren. Eine Antwort gibt Paul Graham.

Dem habe ich noch hinzuzufügen, dass Common Lisp zwar unbestreitbar sehr mächtig ist, aber auf eigenartige Weise etwas schief zusammengesetzt wirkt. Das ist aber kein wirklich starkes Argument, weil mit Scheme und NewLisp weitere Lisp-Dialekte zur Verfügung stehen.

March 6, 2007 at 7:07 pm 1 comment

Lisp vs. XML

Ein ebenso beliebtes wie altes Argument gegen Lisp sind die Klammerungen: “Durch die vielen Klammernist der Code unleserlich.”

Interessanterweise stören sich dieselben Leute aber nicht an XML. Oder wollen die allen Ernstes behaupten, dieser XML-Code


<html>
<body>
<h1>Eine Überschrift</h1>
<p>Findest Du mich zwischen all dem XML?</p>
</body>
</html>

sei besser lesbar als seine Entsprechung in Lisp


(html
(body
(h1 "Eine Überschrift")
(p "Ich bin ganz leicht zu finden!")))

?

(Für die Erbsenzähler: Der XML-Code benötigt 50% mehr Zeilen und 30% mehr Tastenanschläge – ohne Einrückungen).

Tse, tse…

January 30, 2007 at 8:17 am Leave a comment

Ruby goes Lisp

Mit ParseTree kann man zur Laufzeit die Struktur eines Ruby-Programms analysieren. Das was da rauskommt sieht sehr nach Lisp-S-Expressions aus, was Grahams These stützt, die Programmiersprachen würden sich mit der Zeit immer mehr Lisp annähern. Dass mit ParseTree bei weitem nicht die Flexibilität von Lisp erreicht ist, kann man auf der ParseTree-Homepage lesen: Es funktioniert nicht für die Ruby-Core-Klassen und verändern bzw. generieren kann man so einen ParseTree wohl auch nicht. Dennoch wahrscheinlich eine sehr nützliche Geschichte.

December 28, 2006 at 6:18 pm Leave a comment

Older Posts