nicht angemeldet
Aber wenn man nun mal ein spezielles Problem zu loesen hat wie beispielsweise das Sortieren von Zeilen ab einer bestimmten Zeichenposition, und die Programmiersprache haelt fuer dieses Problem keinen fertigen Funktionsaufruf in der Form sort(Liste,abZeichen24) bereit, dann musst du dir eben irgendwas einfallen lassen, oder nicht? Ist das denn in 4GL-Sprachen nicht auch so?
Wenn jede Programmiersprache für jedes Problem gleich gut geeignet wäre (oder eine für alle Probleme!), dann gäbe es nicht so viele verschiedene Programmiersprachen ;-)
Es gab über die Jahrzehnte immer wieder Versuche, die eierlegende Wollmilchsau der Programmiersprachen zu erschaffen (PL/I in den 70er Jahren, ADA vom US-Militär in den 80ern), aber der unvermeidliche trade-off ist, daß man entweder durch zu wenige Befehle eingeschränkt (Standard-Pascal, da gibt es nicht mal eine definierte Schnittstelle zu Dateien des Betriebssystems!) oder durch zu viele Befehle überfordert wird (die genannten Sprachen).
Die Konsequenz waren Sprachen wie C oder Perl: Kleiner Sprachkern plus Bibliotheken.
Man konnte also für einfache Probleme schnell eine Lösung schreiben, während man für schwierige Probleme einfach die Mächtigkeit der Sprache erweitern (bzw. solche Erweiterungen dazu kaufen) konnte. (Objektorientierte Sprachen mit ihren Klassenbibliotheken schlagen in dieselbe Kerbe, bringend lediglich mehr Disziplin und eine einheitlichere Syntax.)
Ich habe eher den Eindruck, dort darf man manche Probleme einfach nicht artikulieren, weil sie nicht ins Sprachkorsett passen <g>.
Völlig richtig. Mit SQL einen Editor zu schreiben ist etwa so elegant wie mit zwei Spitzhacken einen Wollpullover zu stricken.
Konkret bei SQL lassen sich allerdings einige Probleme dadurch lösen, daß man die Algorithmen nicht in der Sprache zur Ausgabe der Ergebnisse einbaut, sondern in die Datenbank selbst (intelligente Tabellen: Trigger, Constraints usw.). Wieso eine Konsistenzprüfung über den Datenbank inhalt in 10 verschiedenen Anwendungen, wenn man das auch einmal in der Datenbank erledigen kann? Die Anwendungsprogramme in 4GL-DML bleiben kurz und knapp, wenn die Datenstrukturen in DDL und 3GL schlau genug sind.
Zudem gibt es Hybridsprachen:
- Pro*C (Oracle) ist eine Obermenge von C, in der man durch bestimmte Metasyntax SQL-Anweisungen in den Quelltext schreiben kann; ein Precompiler ersetzt dies dann durch einen C-Quelltext mit Funktionsaufrufen der Oracle-API, der normal weiterübersetzt werden kann.
- PL*SQL (Oracle) hingegen ist eine Pascal-ähnliche Sprache mit Variablen und Kontrollstrukturen, aber man kann auch direkt SQL-Anweisungen darin verwenden und die Ausgabe über Funktionen an Variablen zuweisen ... und PL*SQL-Programme (Funktionen) kann man wiederum in der Datenbank abspeichern und in SQL-Anweisungen (DDL und DML!) als Funktionsaufrufe ansprechen.
Früher befaßte man sich noch mehr als heute mit Problemen wie
- Aufruf von Maschinensprachenroutinen aus einer Hochsprache oder
- Aufruf einer mathematischen Funktion aus einer Fortran-Bibliothek mit hochgenauer Zahldarstellung durch ein C-Programm
usw. - in C gibt es noch heute irgendwelche inlining-Möglichkeiten für Maschinensprache.
Erst seitdem Portabilität und Transparenz durch die wachsende Komplexität (wieviele Zeilen hat der Windows-Quelltext?) der Programme und die höhere Reevanz kaufmännischen Denkens bei der Softwareerstellung (die ersten Programmierer wollten ihre Programme nicht verkaufen, sondern laufen lassen!) immer wichtiger wurde, entfernte man dieses Feature wieder aus den Sprachdefinitionen; heute überläßt man die Verbindung von Programmen verschiedener Programmiersprachen sinnvollerweise dem Betriebssystem (DLL-Schnittstelle etc.).