nicht angemeldet
Hi Mathias,
interessante Debatte, das. Mir ist dabei klar
geworden, wie sehr viele scheinbar klare Grenzen
verschwimmen.
für mich sind diese Grenzen überhaupt nicht klar.
Denn die wesentliche Frage ist für mich, was ich mit der Definition des Begriffs "Programmiersprache" letzten Endes _erreichen_ will.
So viele verschiedene Zwecke ich mir dafür vorstellen kann, so viele verschiedene Definitionen könnte ich mir aus den Fingern saugen.
Irgendwie hatte ich mir zurecht gelegt:
Scriptsprachen = Interpreter
Programmiersprachen = Compiler und der ganze Quark
Will ich beispielsweise eine Aussage über die Möglichkeit, Informationen über die Arbeitsweise des Programms zu verstecken, bekommen, dann taugt die Unterscheidung zwischen Interpretersprachen (fast immer Open Source, aus technischen Gründen) und Compilersprachen (Binaries, theoretisch zwar zu dekompilieren, aber mit Informationsverlust aller Identifier und aller Kommentare) durchaus etwas.
Will ich allerdings etwas über die Lösbarkeit bestimmter Probleme aussagen, dann interessiert mich die Unterscheidung zwischen Interpreter und Compiler praktisch nie. (In diesem Kontext interessieren mich eher die mathematischen Eigenschaften der Sprachen, so etwas wie "berechenbare Funktionen" oder "primitiv rekursiv" etc.)
Und im letzteren Sinne habe ich die aktuelle Diskussion über HTML aufgefaßt.
Aber tatsächlich: Wenn man ein wenig überlegt,
in welche Richtung sich manche Sprachen entwickelt
haben, haut das Ganze so einfach doch nicht mehr
hin, mir fallen dazu etwa Perl oder manche SQL-
Abteilungen dazu ein.
Eben. Bei SQL (und allen 4GL-Sprachen) greift das Attribut "algorithmisch" schon nicht mehr.
Ich verstehe "programmieren" nämlich durchaus _auch_ als "technische Modellierung von Daten" - ob ich in C ein "struct" definiere oder in PASCAL einen record oder in Perl einen Hash oder in SQL ein "CREATE TABLE"-Statement (oder sogar ein Constraint!), das ist für mich alles äquivalent: Ich "codiere" meine Vorstellung über das Wesen der zu verarbeitenden Daten in die Möglichkeiten der jeweiligen Programmiersprache.
Wobei die Umstellung zwischen "algorithmisch programmieren" und "in einer deskriptiven Sprache programmieren" vom Stil her durchaus erheblich sein kann. Aber beides beschreibt die "Anfertigung einer Beschreibung zur Automatisierung der Lösung eines Problems" - das eine durch eine Schrittfolge des Ablaufs, das andere durch eine Endbedingung, welche der "Interpreter" (der execution plan generator des RDBMS) irgendwie zu erreichen versucht.
Insofern sehe ich unterschiedliche Klassen von Programmiersprachen, welche unterschiedliche Programmierstile bedingen.
Vielleicht wird aus HTML/JAVASCRIPT/CSS/XML usw.
ja auch mal eine ausgewachsene Programmiersprache
Das sind lauter verschiedene Sprachen mit ganz verschiedenen Aufgabenfeldern.
Daraus sollte um himmelswillen keine Sprache werden, die einander widersprechende Eigenschaften aufweist!
Es mag verlockend sein, in PHP alles in eine Datei schreiben zu können - genauso wie es verlockend ist, mit Frontpage HTML-Code zu generieren.
Beides verstellt aber in meinen Augen den Blick für die Semantik. Vorhin gab es hier einen Thread, wo jemand eine Interaktion zwischen JavaScript und PHP versucht hat - die Tatsache, daß der gesamte Quelltext in einer einzigen Datei gespeichert wird, verschleiert dabei, daß der Inhalt dieser Datei nacheinander von verschiedenen Interpretern (auf verschiedenen Maschinen!) verarbeitet werden muß.
Wobei einmal mehr gesagt werden sollte, daß die Beschäftigung mit Konzepten (hier: Client / Server) wesentlich wichtiger ist als das Nachsehen in irgend einem Handbuch, wie man einen bestimmten Befehl in einer bestimmten Sprache korrekt schreibt.
'Valide' Seiten sind halt noch lange keine 'guten' Seiten ... und syntaktisch korrekte Programme noch lange nicht semantisch korrekt, oder performant, oder portabel, oder ...
So einen "Zwergdebugger" haben wir ja jetzt schon
mit dem Validator ;-)
Ein Debugger (mit "schrittweiser Ausführung" etc.) ist das eben gerade nicht, sondern lediglich ein Syntaxprüfer. Vergleiche den Validator mit "perl -cw", nicht mit "perl -d".
Und wenn sich SELFHTML so weiter entwickelt, wird
das Ganze angesichts der vielen Querverbindungen
und kleinen Helfer vielleicht auch mal zu einer
klassischen Programmierumgebung ;-)
Ich bezweifele, daß Stefan in diese Richtung gehen will. In meinen Augen ist SelfHTML in erster Linie ein Lehrbuch, kein Toolset.
(Obwohl ich die "So sieht's aus"-Seiten für eine der tollsten Einrichtungen des gesamten Werkes halte - auch wenn sie dem Self-Gedanken irgendwie total zuwider laufen ... ;-)
Viele Grüße
Michael