Konzepte h¨oherer Programmiersprachen (Entwurf) - WSI ...
Konzepte h¨oherer Programmiersprachen (Entwurf) - WSI ...
Konzepte h¨oherer Programmiersprachen (Entwurf) - WSI ...
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
6 1.2 <strong>Konzepte</strong> und ihre Umsetzung<br />
oder auch gar nicht. Keine Sprache kann jemals die Lösung für alle Probleme liefern<br />
und bislang sind alle Versuche gescheitert, die eine und wahre Programmiersprache<br />
zur Beseitigung aller <strong>Programmiersprachen</strong> zu konstruieren. Eine solche Sprache kann<br />
es auch aus systematischen Gründen gar nicht geben; das Problem liegt darin, dass sich<br />
mache <strong>Konzepte</strong> einfach widersprechen und sich deshalb nicht durch noch so gewagte<br />
Konstruktionen in einer einzigen Sprache vereinigen lassen 7 .<br />
Um außerdem auch dem missionarischen Eifer mancher Sprachfans vorzubeugen,<br />
sei darauf hingewiesen, dass keine Programmiersprache dieser Welt das Programmieren<br />
letztlich einfach macht und dass ebenso keine Sprache verhindern kann, dass jemand<br />
darin schlechte Programme schreibt. Das kommt in den folgenden beiden Zitaten<br />
von Dijkstra bzw. Wulf zum Ausdruck:<br />
As an aside I would like to insert a warning to those who identify the difficulty of the programming<br />
task with the struggle against the inadequacies of our current tools, because they might conclude that,<br />
once our tools will be much more adequate, programming will no longer be a problem. Programming<br />
will remain very difficult, because once we have freed ourselves from the circumstantial cumbersomeness,<br />
we will find ourselves free to tackle problems that are now well beyond our programming capacity.<br />
E. W. Dijkstra (1987), The Humble Programmer<br />
Language is the vehicle by which we express our thoughts, and the relation between those thoughts<br />
and our language is a subtle and involuted one. The nature of language actually shapes and models<br />
the way we think. . . . If, by providing appropriate language constructs we can improve the programs<br />
written using these structures, the entire field will benefit. . . . A language design should at least provide<br />
facilities which allow comprehensible expression of algorithms: at best, a language suggests better<br />
forms of expression. But language is not a panacea. A language cannot, for example, prevent the creation<br />
of obscure programs: the ingenious programmer can always find an infinite number of paths to<br />
obfuscation.<br />
W. Wulf, 1977<br />
1.2 <strong>Konzepte</strong> und ihre Umsetzung<br />
Manchmal ist es ausgesprochen schwierig, die <strong>Konzepte</strong> sauber auseinanderzuhalten<br />
von der Art und Weise, wie sie in Form gewisser Vorrichtungen ( ” Features“) in <strong>Programmiersprachen</strong><br />
eingebaut sind. Wenn man also sagt ” Die Programmiersprache X<br />
erlaubt (unterstützt, fördert, erzwingt) das Konzept Y “, so mag man häufiger dabei<br />
auch auf Widerspruch stoßen. Manchmal ist das Konzept tatsächlich in Reinform vorhanden<br />
und der Unterschied liegt lediglich in der Syntax, manchmal ist eine Vorrichtung<br />
der Sprache aber allgemeiner zu verwenden als das Konzept vorsieht oder aber<br />
auch weniger allgemein. In schweren Fällen kann ein Konzept sogar in einigen Aspekten<br />
allgemeiner, in anderen weniger allgemein verwirklicht sein.<br />
Wir wollen dies am Beispiel der Zählschleife einmal vorführen:<br />
Beispiel: Eine (einfache) Zählschleife in imperativen <strong>Programmiersprachen</strong> besteht<br />
konzeptuell aus der Spezifikation einer Schleifenvariablen, einem Anfangs- und<br />
7 Im angelsächsischen Sprachraum spricht man hier von ” feature interaction“: Bestimmte Vorrichtungen,<br />
die für sich selbst gesehen einfach und sinnvoll sind, können durch ihre Kombination ungeahnte<br />
Probleme hervorrufen.<br />
koeinf.pdf