Ich würde an dieser Stelle mal meine Vermutung kundtun, daß in den kommenden Jahren immer mehr Skriptsprachen auch für große Anwendungen verwendet werden.
Hm - mit "Skriptsprachen" meinst Du "interpetierte Sprachen"? Letzten Endes ist es doch gar keine Eigenschaft der Sprache, ob sie interpretiert oder kopmiliert wird. Du kannst sehr wohl einen C-Interpreter schreiben ... das wird halt keiner wollen, weil C-Programmierer keine Angst vor Übersetzen und Binden haben. ;-)
Gründe:
- Skripte lassen sich schnell entwickeln, da das compilieren und linken entfällt.
(gulp ...) Ich lasse auch meine Perl-Skripte "kompilieren" - ich habe zu jedem Skript meines Projekts eine Batch-Datei, die "perl -c" für dieses Skript ausführt.
Ich möchte meine Fehler nämlich selbst finden und das nicht dem Kunden überlassen. ("Bananen-Software")
- Die Rechner werden so schnell, daß die Ausführungsgeschwindigkeit gegenüber der Entwicklungszeit immer mehr an Bedeutung verliert.
Das mag für Anwendungen für einzelne Benutzer gelten (die dezentrale Rechenkraft ist durch das Client-Server-Prinzip in der Tat immens gestiegen), aber für Server-Anwendungen mit tausenden von Benutzern wird man weiterhin optimieren (müssen).
- 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) ...
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.
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.
Meine "Vorhersage" ist, daß die Zahl der (oftmals proprietären) Programmiersprachen nicht kleiner werden wird als bisher, daß der durchschnittliche Programmierer aber mehr verschiedene Sprachen verwenden muß als bisher. Und dabei zähle ich Sprachen etwa zur Programmierung von Word- oder Excel-Makros mit!
Konsequenterweise wird der Sprachkern fast aller neuen Sprachen klein sein (kurze Anlernzeit - Schulung ist teuer!); das Lernen einer Sprache wird mehr darin bestehen, die Semantik der zugrundeliegenden Anwendung zu verstehen (das Komplexe an SQL ist keineswegs die Syntax, sondern die Struktur und die Fähigkeiten des darunterliegenden Relationalen Datenbanksystems).
Man wird also bei seiner Ausbildung noch mehr Wert darauf legen müssen, "lernen" zu lernen, also ständig neue spezialisierte Werkzeuge einzusetzen.
Insofern ist das Konzept der "Energie des Verstehens" genau das, was ich jedem empfehlen kann, der "am Ball bleiben" will: Nicht die Syntax ist letztlich interessant, sondern die damit umsetzbaren Konzepte.
Die Grenze zwischen "anwenden" (Menü-Klickerei) und "programmieren" (Anweisungen in Dateien schreiben) wird mehr und mehr verschwimmen, weil viele Dinge auf beiden Ebenen möglich sein werden. Als Beispiele nenne ich hier ganz bewußt
- WYSIWYG-Generatoren für Web-Dokumente (gerade hier verschwimmt ja die Grenze zwischen Gestalten und Programmieren, was auch der Anlaß für diesen thread war) oder
- Report-Generatoren für Datenbankabfragen (da kann man schon seit Jahren Tabellen mit der Maus zusammenklicken und das Ausgabeformat mit graphischen Interaktionen zusammenstellen, um daraus entsprechende Abfrageskripte mit SELECT-Anweisungen generieren zu lassen).
Aber ob so etwas letztlich interpretiert oder kompiliert wird, halte ich für völlig unwichtig.
Ein intelligentes "make" ist bereits in vielen PC-Entwicklungsumgebungen (z. B. Borland) enthalten; der compile-link-go-Mechanismus wird vor dem Programmierer mehr und mehr verborgen werden, weil dieser beim Anklicken des Menü-Eintrags "Programm laufen lassen" gar nicht mitbekommen muß, daß diese Funktion erst mal via "make" prüft, ob sie etwas übersetzen muß oder nicht.
Wichtig ist, wie es für den Benutzer aussieht - nicht, wie es intern realisiert wird.