Hallo Peter,
ich habe keine grundsätzlichen Einwände zu Deinem Paper, möchte Dir aber meine Gedanken, Anregungen und kleinen Verbesserungsvorschläge nicht vorenthalten.
Zunächst scheint es mir sinnvoll, darauf hinzuweisen, dass - so banal das jetzt klingen mag - Programme die Funktion haben, ein Problem oder eine Aufgabenstellung zu lösen. Höhere Programmiersprachen grenzen sich von Assembler oder gar Maschinensprache dadurch ab, dass sie losgelöst sind von der konkreten Funktionsweise der Hardware und Systemsoftware eines Rechners und sich ausschließlich auf das zu lösenden Problem konzentrieren. Dies ist Dir natürlich klar und klingt in Deinem ersten Paper auch an, sollte aber vielleicht noch deutlicher gesagt werden.
Deine beiden Fragen zur Abgrenzung "prozedural" vs. "deklarativ" treffen ganz gut den entscheidenden Unterschied. Man könnte auch sagen, beschreibe ich den Lösungsweg als geordnete Sequenz von Anweisungen, die nacheinander ausgeführt werden und damit verkettet sind, oder definiere ich die Lösung und überlasse die Abarbeitung der Programmengine.
Beim Programmierbeispiel zu den imperativen Sprachen wäre es vielleicht hilfreich, einen Initialwert zu geben und einen Output zu zeigen,z.B.
x=1;
x=x+1;
writeln(x) --> Output: 2
Die Beschreibung der logischen Programmiersprachen passt meines Erachtens perfekt zu Prolog.
XSLT sehe ich persönlich nicht so sehr als Beispiel für ein logisches Inferenzmodell. Der XML-Parser analysiert zunächst die Inputdatei und generiert den Input-Baum. Die Verarbeitung wird getrieben von -Instruktionen, deren unter Umständen hochkomplexes match-Attribut die passenden Elemente aus dem Datenstrom bzw. dem Input-Baum pickt, die nach den Instruktionen innerhalb der template-Elemente verarbeitet werden. Dabei wird ein Output-Baum generiert, der schließlich als Outputdatei serialisiert wird. Das heisst ich sehe hier fast eine neue Kategorie template-oder patternbasierte Programmiersprachen. Wie siehst Du das?
Bei den objektorientierten Sprachen würde ich unbedingt am Anfang den Begriff "Objekt" einführen. Die Sprache modelliert einen Wirklichkeitsausschnitt - denke auch an UML - indem sie logische Objekte definiert, die für Gegenstände, Personen (in bestimmten Rollen), Organisationseinheiten, etc. der realen Welt stehen. Diese Objekte haben Eigenschaften (Attribute) und verfügen, wie Du korrekt beschreibst, über Prozeduren und Funktionen zu Ihrer Bearbeitung (Methoden). Ich fände einen kleinen Ausschnitt aus einer fiktiven Klassenhierarchie als Baumdiagramm hilfreich (z.B. Fahrzeug - Auto - 4WD), bei dem man in Kästchen zeigen kann, welches Objekt welche Eigenschaften und Methoden hat, wer was woher erbt oder überschreibt.
Bei den objektorientierten Sprachen würde ich noch Java und C# ergänzen.
Bitte verstehe meine Äußerungen nicht als Kritik, zumal der grundlegende Ansatz doch stimmig ist, sondern als Hinweis.
Noch ein schönes Wochenende und líebe Grüße
Wolfgang (saxon) |