Was sind Programmiersprachen?

[Calocybe]

Hi Michael und Andreas!

Gründe:

• Skripte lassen sich schnell entwickeln, da das compilieren und linken entfällt.

Ich finde, das Compilieren und Linken ist kaum mehr Arbeit als das Starten eines Scriptes. Wenn ich mir einen Batch schreibe und denn von der Befehlszeile immer wieder aufrufe, sind das dank Kommandowiederholung zwei Tastendrueck: Pfeil nach oben und Enter. Wenn ich eine Perlscript wiederholt starte, sind genau dieselben beiden Tasten zu druecken. Wenn ich ein JavaScript schreibe, muss ich einmal im Browser Reload druecken. Ich finde, da ist kein grosser Unterschied.

• In Skriptsprachen kann man sich zu nutze machen, daß der "Parser" (Interpreter/Übersetzer) auch zur Ausführungszeit aktiv ist und z.B. viel mehr "in Worten" programmieren (vgl. z.B. der 'eval'-Befehl in Javascript).

Das hat doch nichts damit zu tun, ob die Sprache interpretiert wird oder nicht!
Auch in einer Compilersprache könnte man eine eval-Funktion schreiben und per Bibliothek zu jedem beliebigen Programm hinzubinden. Man muß es nur tun (wollen) ...

Doch, es hat was damit zu tun. Klar koennte man auch fuer C ein eval schreiben. Nur muesste man da ja den ganzen C-Compiler nochmal mit in die Applikation einbauen. Da JS aber einfach nur Text interpretiert, macht es keinen Unterschied, ob der nun fest in einer Datei steht oder aus einem dynamisch zusammengesetzten String kommt. Ich glaube, das eval ist einfach ein Nebenprodukt der interpretierenden Sprachen, das man aufgrund seiner Maechtigkeit dem Scripter zur Verfuegung gestellt hat, ohne dass dafuer ein grosser Aufwand getrieben werden musste. Wie gesagt, bei einer kompilierenden Sprache kostet soetwas sehr viel, denn man muss einen (abgespeckten) Compiler mit in die EXE (or whatever) intergrieren.

Auch kann man z.B. Formeln auf leichteste Weise zur Laufzeit parsen lassen, so daß der Benutzer einer Anwendung z.B. statt Zahlen auch Formelausdrücke in irgendwelche Eingabefelder eingeben kann usw...

Auch das hat nichts mit der Programmiersprache zu tun, sondern mit dem Komfort einer Anwendung.
Ob ich in einem HTML-Formular JavaScript-Routinen für die Syntaxanalyse einer Formulareingabe anbiete oder nicht, ist meine Entscheidung, nicht aber eine Eigenschaft von HTML oder JavaScript.

Auch hier ist es eine Frage des Aufwands. Ich kann in C natuerlich einen Formelparser schreiben, wie ihn jedes vernuenftige Matheprogramm hat. Aber in JS ist er eben schon da, weil der Interpreter ihn ja selber braucht.

Ich teile Deine Vorhersage nur insofern, als daß in fünf Jahren wieder ganz *andere* Sprachen in Mode sein werden als heute. Aber auch heute programmiert man noch in C, was eine schon ziemlich alte Sprache ist - also werden wir unser aktuelles Perl-Wissen auch in fünf Jahren noch brauchen können.

Ueber die Zukunft solche Progrnosen zu stellen, wage ich lieber nicht. Nur soviel: Es ist sicher kein Zufall, dass sich C bis auf den heutigen Tag so stark behauptet hat. Es ist aber in der Tat an manchen Stellen aufgrund hoeherer Leistungen der modernen Rechner nicht mehr so notwendig wie frueher.

Aber ob so etwas letztlich interpretiert oder kompiliert wird, halte ich für völlig unwichtig.
Wichtig ist, wie es für den Benutzer aussieht - nicht, wie es intern realisiert wird.

Richtig.

Bye, Calocybe