Kompakte Syntax für Funktionen

[deamon]

Hallo,

neulich bin ich über das in Ruby geschriebene Web-Framework Sinatra gestolpert. Die Art, wie man in einem Sinatra-Controller eine Action definiert, finde ich beeindruckend kompakt und lesbar:

Code: Alles auswählen

get '/hi' do
  ...
end

Sinatra: The Book

Soweit meine dürftigen Ruby-Kenntnisse reichen, dürfte "get" eine Funktion sein, der ein String ("/hi") und anschließend ein Funktionsobjekt (do ... end) übergeben wird.

Wie könnte man sowas in Python machen?

[BlackJack]

So zum Beispiel:

Code: Alles auswählen

@get('/hi')
def foo():
    pass

Aber Python eignet sich nicht besonders gut um "domain specific languages" zu schreiben. Was man auch als Vorteil sehen kann.

[deamon]

Aber Python eignet sich nicht besonders gut um "domain specific languages" zu schreiben. Was man auch als Vorteil sehen kann.

Das stimmt allerdings! Die Beispiele zu Domain Specific Languages (DSL) sehen meistens erstmal schön aus, aber oft weichen sie so stark von der zugrunde liegenden Sprache ab, dass man ständig neue Sprachen lernen muss. Nach einem kleinen Ausflug zu Scala, wo ich gesehen habe, was man alles in Sachen DSLs anstellen kann, bin ich ziemlich skeptisch, ob das langfristig ein Segen für die Software-Welt ist. Die DSLs von heute, sind das Cobol von morgen.

Da ist mir ein allgemeiner, aber trotzdem kompakter Ansatz, wie er für Python typisch ist, lieber.

[sma]

Einspruch. Ich gehe da mit Steele konform, dass nur Sprachen, die in der Syntax erweiterbar sind (wie z.B. Lisp, Smalltalk, Forth, aber auch eingeschränkt Scala und Ruby) langfristig überleben werden. Sein OOPSLA-1998-Talk (Growing a Language) liefert die Argumente, die ich hier nicht wiederholen möchte. Den Talk übrigens unbedingt als Video schauen, sonst wird's nicht klar.

Wer keine Sprachabstraktionen einführen kann, ist (wie z.B. bei Java) verdammt, Sprachmuster und Entwurfsmuster immer und immer wieder in ihrer Implementierung hinzuschreiben, zu lesen und zu identifizieren und zu verstehen. Microsoft gleicht diese Schwäche bei C# dadurch aus, dass sie in relativ schneller Folge immer wieder neue C#-Versionen mit noch mehr Syntax herausbringen.

Stefan

[BlackJack]

@sma: Man sieht ja wie sich Lisp und Forth durchgesetzt haben. Und es hat sich ja auch noch nie jemand darüber beschwert, dass derartig erweiterbare Sprachen gerade dadurch unlesbar werden.

Die haben genau das gleiche Problem wie C# mit immer mehr Syntax: Man verliert früher oder später den Überblick. Bei den erweiterbaren Sprachen kommt dann noch dazu, dass man nicht in einer Standarddoku nachsehen kann, sondern auf die jeweiligen Syntaxerweiterungen eingehen muss. Und ob man nun 3rd-party Code erkennen und verstehen muss, der Muster in Syntax giesst, oder Muster in einer einfacheren aber starren Syntax erkennen muss, nimmt sich am Ende nicht so viel. No silver bullet here, IMHO.

[sma]

@sma: Man sieht ja wie sich Lisp und Forth durchgesetzt haben.

Als ich das abgeschickt hatte, wusste ich, dass dieses Argument kommen würde und bereute schon den Beitrag :) Zu Lisp kann ich nur sagen: Warten wir mal ab, ob auch noch über Java und C# in 50 Jahren gesprochen wird. Es ist da ja nicht die Erweiterbarkeit das Problem, sondern die "ungewöhnliche" Syntax. In beiden Sprachen muss sich der Mensch in der Syntax dem Computer unterwerfen, damit dieser es einfacher hat, die Sprache zu verarbeiten. So etwas sollte heutzutage nicht mehr notwendig sein.

kommt dann noch dazu, dass man nicht in einer Standarddoku nachsehen kann, sondern auf die jeweiligen Syntaxerweiterungen eingehen muss.

Der Überganz von Syntax zu Funktionen einer Standardbibliothek ist fließend und die Grenze beliebig. Ich muss auch nachgucken, was "kz4xx()" bedeutet, wenn dies keine von den von mir auswendig gelernten Standardfunktionen ist. In beiden Fällen sollte das "principle of least surprise" gelten und die Syntax (also die Funktionsnamen) möglichst gut zum Problem passen.

Manchmal will man aber nicht nur Funktionen passend benennen, sondern auch Schleifen oder Bedingungen und hier ist es dann sinnvoll, wenn man auch die Struktur des Programms anpassen kann. C# führt extra properties und events in der Sprache ein, um besser UIs programmieren zu können. Die führen eine SQL-artige Syntax ein, um besser (relationale) Datenbankabfragen integrieren zu können. Sie führen alle Arten von Annotationen ein, um dem Compiler besondere Dinge zu zeigen und bestimmte Metadaten für z.B. den UI-Builder erzeugen zu lassen.

Stefan

[Darii]

C# führt extra properties und events in der Sprache ein, um besser UIs programmieren zu können. Die führen eine SQL-artige Syntax ein, um besser (relationale) Datenbankabfragen integrieren zu können. Sie führen alle Arten von Annotationen ein, um dem Compiler besondere Dinge zu zeigen und bestimmte Metadaten für z.B. den UI-Builder erzeugen zu lassen.

Bei dem was du da beschreibst, fällt mir spontan Qt ein. Wie da per Compilermakros Nachrichtenversand und Properties auf C++ gepfropft werden, ist auch nicht schön(in meinen Augen falsche Sprache für das Problem gewählt).