"C++ ist leider sehr kompliziert. Zum Glück braucht man nicht alles zu können, um sinnvoll C++ programmieren zu können, aber es kann schwierig werden, Code von anderen Leuten zu lesen."

BjarneStroustrups Entgegnung zu "C++ is too complex" und verwandten Bemerkungen ("C++ is not Object-oriented", "C++ sucks", ...): http://www.research.att.com/~bs/blast.html

Frage: Welche Sprachen (neben dem naheliegenden "prozeduralen C") meinst du da noch? Eine objektorientierte Sprache? Eine generisch-templateorientierte Sprache?

C++ enthält:

• Eine stark typisierte OO-Sprache
• Eine (fast) typlose OO-Sprache, die einigen eingebauten Typen eine Sonderstellung einräumt
• Eine prozedurale Programmiersprache
• Eine generische Programmiersprache
• Eine modulare Programmiersprache

"Generisch" und "modular" sind Eigenschaften von Sprachen, keine Subsprachen. Jede typisierte Sprache enthält eine untypisierte, ob man will oder nicht. Bleiben "prozedural" und "OO", aber da OO nur "prozedural mit speziellen Konventionen" bedeutet, ist C++ eine polymorph typisierte OO-Sprache mit Modulsystem. Wo liegt das Problem?

Frage: Was heißt in dem Zusammenhang zu kompliziert? Zu kompliziert für Personen mit bestimmter Qualifikation? Zu kompliziert als Erstsprache (wie sind da die Erfahrungen an den Unis)? Zu kompliziert für bestimmte Aufgaben?

Eigentlich steht oben sehr kompliziert, nicht zu kompliziert. // aber die Seite heißt -seltsamerweise- CppIstZuKompliziert)

Dass C++ mächtig genug ist, um jede Aufgabe, die in einer anderen Programmiersprache lösbar ist, auch in C++ lösen zu können, ist wohl nicht fraglich; allerdings gibt es Probleme, bei denen der Einsatz von C++ weder wirtschaftlich noch subjektiv ökonomisch ist. Der Aufwand für einen Textfilter in AWK ist so viel geringer, dass es nicht ökonomisch sein kann, einen solchen Filter in C++ zu schreiben. Dasselbe gilt aber auch für andere nicht spezialisierte Sprachen. -- kw

Die gesuchte einheitlich Idee hinter C++ ist wohl, dass niemand (mit Laufzeit oder Resourcenverbrauch) für etwas bezahlen muss, was nicht verwendet wird. Den Preis in Form von Lernaufwand wollte weder der Erfinder noch das Standardisierungskommitee in Erwägung ziehen.

Wozu C++ wirklich ungeeignet ist, ist, ein bestimmtes von C++ unterstütztes Programmierparadigma zu erlernen --kw

"Mehrparadigmensprache" gefällt mir besser, weil es ja nicht so ist, dass C++ im Gegensatz zu anderen Programmiersprachen mehrere verschiedene nützliche Eigenschaften hat, sondern eher so, dass sie mit C++ der gleiche Nutzen auf verschiedenen Wegen erreichen lässt. Im Gegensatz zur "eierlegenden Wollmilchsau" ist der mit C++ erreichbare Nutzen nicht verschiedenartiger als der mit anderen höheren Programmiersprachen mit hardwarenaher Ausrichtung (MODULA, C, ...) erreichbare. "C++ unterstützt mehere Programmierparadigmen" sehe ich als Vor- und gleichzeitig als Nachteil von C++ --kw

• In C++ ist eine recht brauchbare einfache Programmiersprache enthalten. Wer der Standardbibliothek als Nutzer entgegentritt, ohne den Anspruch zu erheben, neue abstrakte Behälter zu entwerfen, die mit den Algorithmen der Standardbibliothek zusammenarbeiten, kann ohne grosses Vorwissen bald produktiv arbeiten. Es gibt eine brauchbare Implementation von Zeichenketten, die wie ein eingebauter Typ verwendet werden können. Für viele einfache Anwendungen genügt dieser Sprachumfang.
• Die Sprache ist ohne einen tieferen Einstieg um problemrelevante Typen erweiterbar, die wie eingebaute Typen verwendet werden können. Wenn ein tieferer Einstieg nicht gewünscht oder erforderlich ist, genügt es einige Duzend Regeln einzuhalten. Auch eine Arbeitsteilung zwischen Teammitgliedern, die diese problemorientierten Spracherweiterungen bereitstellen, und solchen, die daraus Anwendungsprogramme bauen, ist ohne Schwierigkeiten möglich.
• Wer Code wartet, muss die Sprache kennen, in der dieser Code geschrieben ist. Der Anspruch, dass "Code von anderen Leuten" auch ohne diese Kenntnis lesbar sein muss, ist meines Erachtens in keiner Sprache realistisch.

Ich glaube, wir sind am (absehbaren) Ende der Fahnenstange angelangt. C++ gehört sicher zu den komplizierteren Sprachen, aber es gibt keinen Grund, es als "zu kompliziert" zu bezeichnen. Ich verstehe nach dem Lesen dieser Diskussion jedenfalls besser, warum ich nie mit C++ warm geworden bin. Wenn es eine Sprache gibt, in der es schwer ist, die Idealform einer Lösung dingfest zu machen, dann ist es - auf Grund der Vielschichtigkeit - wahrscheinlich C++. Bleibt die Frage: WasIstKompliziert. -- hl

C++ ist komplizierter als es in vielen Fällen sinnvoll ist. Ein wesentlicher Schwachpunkt von C++ (und Java), der sehr oft als Stärke dargestellt wird, ist die statische Typisierung. Viele Sprachmittel von C++ sind in dynamisch typisierten Sprachen schlichtweg überflüssig. Was die Einfachheit angeht, würde ich exemplarisch in etwa folgende Reihenfolge unterstellen:

Kompliziert | C++ <-> Java <-> Smalltalk | Einfach

Ich bringe hier Smalltalk und Java ins Spiel, um auf folgenden interessanten Link verweisen zu können:

   http://www.smalltalkchronicles.net/edition3-1/whyjava.html

Der Entscheidungsbaum ist Blödsinn. Schon die Frage: "What is the Object?" läßt gar nicht zu, dass etwas kein Object ist. Mathematische Abstraktionen, Ideen, Namen, etc. sind aber keine Objekte, sondern Werte. Man kann sie kopieren, sie haben keine Identität, usw. usf. Also ist der Entscheidungsbaum ein ganzes Stück komplizierter, noch bevor irgendeine Sprache ins Spiel kommt.

In Smalltalk und Ruby ist in der Tat alles ein Objekt. Und man kann Klassen nachträglich Methoden zufügen. Letzteres führt nach meiner Erfahrung durchaus einiges an zusätzlicher Komplexität ein, erweist sich aber andererseits in vielen Fällen als immens praktisch. Funktionen können über Klassenmethoden emuliert werden. Häufen sich diese, stellt sich durchaus die Frage, ob eine Kapselung in Form eines Kontext-Objekts Sinn macht.

Bzgl. der abstrakten Entitäten: Der Entscheidungsbaum hilft nicht bei der Entscheidung zwischen einer objektorientierten Programmiersprache und einer funktionalen Programmiersprache. Ist wohl eher ein Relikt aus dem alten Smalltalk vs. Java Disput.

Was 'unstrittig', 'Blödsinn' und 'professionell' ist, mag ich nicht entscheiden. Ehrlich gesagt bin ich bei diesem Thema mittlerweile ein wenig diskussionsmüde.

--SDö

Ich habe das OO-Paradigma noch nie als Korsett empfunden. Die Designidee hinter der Objektorientierung war, ein Computerprogramm auf kleinere Einheiten herunterzubrechen. Jedes Objekt kann als Minicomputer mit eigenem Speicher und eigenem Befehlssatz aufgefasst werden. Diese vielen Minicomputer lösen dann gemeinschaftlich das Gesamtproblem. In diesem Ansatz kann ich keinerlei Beschränkung entdecken. (Siehe http://www.metaobject.com/papers/Smallhistory.pdf.) -- {SDö}}

C++ Experten genießen eine gute Reputation. Aus gutem Grund - die Sprache ist eben kompliziert. Insofern wird man kaum gute C++-Entwickler finden, die eingestehen, dass die Sprache zu kompliziert ist.

SaschaDördelmann

Gegenrede

Unabhängig davon, ob die Aussage "C++ ist komplizierter als es in vielen Fällen sinnvoll ist." überhaupt ein sinnvoller Satz der deutschen Spache ist (geschweige denn, den Tatsachen entspricht), sie ist gänzlich unerheblich. Erheblich dagegen ist, und das dürfte einigermaßen unstrittig sein, dass C++ für sehr viele, nämlich Abertausende von Fällen ein mehr oder weniger offenbar gut bewältigbar gewesenens Maß an Komplexität besaß bzw. weiterhin besitzt.

Eine wesentliche Stärke und "by design" exakt so gewollte Eigenschaft von C++ ist die statische Typisierung, was von Unbelehrbaren jedoch oft als Schwachpunkt dargestellt wird. (Das Unbelehrbare bezieht sich dabei oft weniger auf die Uneinsicht, dass statische Typisierung eine Stärke sei, als auf die fehlende Einsicht/Akzeptanz bzw. den fehlenden Glauben, dass die Eigenschaft wohlmöglich in der Tat gewollt sein könnte.) "Beim Kunden" laufende Anwendungen haben dadurch nämlich per se eine höhere Robustheit, als das bei mit dynamisch typisierten Sprachen erstellten Anwendungen möglich wäre. (Diese Thematik werden wir hier wohl nicht ausdiskutieren können. Das tut auch nicht nötig, denn diese Diskussionen sind nun wirklich bis zum Erbrechen in u. a. den einschlägigen Newsgruppen geführt worden, und sie werden weiterhin geführt werden.)

Ich unterstelle folgende Reihenfolge der Sprachen:

Solides Werkzeug für echte (Programmier-)Männer und echte Anwendungen | C++ <-> Java <-> Smalltalk | Spielzeug für Kinder, Frauen und sonstige Warmduscher (obiger Smalltalk-Artikel wurde natürlich von einer Frau verfasst)

Ich finde die Behauptung, C++ = solides Werkzeug und Smalltalk = Kinderkram, ja schon sehr gewagt, selbst als Befürworter streng typisierter Sprachen, das aber noch mit deiner Weltanschauung über Kinder, Frauen, Warmduscher und "echte" Männer zu verbinden, disqualifiziert deinen gesamten Text als Beitrag zu dieser Diskussion. Schade drum. -- hz (Gegen Niveaulosigkeit)

Hör schon auf. Sascha hatte schließlich damit angefangen, befremdliche Reihenfolgen anzugeben, warum kritisierst du nicht (auch) ihn? Meine Reihenfolge ist _selbstverständlich_ nicht ernst gemeint (s. u.). -- VolkerGlave

Okay, gleich höre ich auf. :-) Nur das noch. Das mit der Reihenfolge finde ich nicht schlimm. Das kann ja eine Meinung sein. Vielmehr stieß mir auf, dass du Frauen als Programmierer zweiter Klasse betrachtest und den Inhalt des Artikel damit erklärst, dass er natürlich von einer Frau kommt. Dabei macht doch Sascha gerade deutlich, dass die Meinung zu Smalltalk nicht unbedingt geschlechtsspziefisch ist oder gehört er für dich in die Rubrik Warmduscher? Wenn du das alles nicht ernst meinst, gebe bitte dem geneigten Leser eine Chance dies zu erkennen ohne ein Persöhnlichkeitsanalyse von dir anfertigen zu müssen. -- hz

Die Schlußbemerkung ist "[...] Insofern wird man kaum gute C++-Entwickler finden, die eingestehen, dass [ihnen, oder was?] die Sprache zu kompliziert ist.". Für das Eingeständnis "zu kompliziert" besteht kein Anlass. Das Eingeständnis "kompliziert" (ohne "zu") ist hingegen machbar, aber normal kompliziert. So wie Smalltalk und Java.

VolkerGlave

Kommentar zur Gegenrede

Ich dachte eigentlich, ich sei sachlich geblieben. Nach meiner Erfahrung sind eher die Männer die Warmduscher (mich eingeschlossen) aber das tut hier eigentlich nichts zu Sache.

Ich kann nach etwa 10 Jahren C++-Erfahrung und 6 Jahren Smalltalk sagen, dass es erheblich einfacher ist, in Smalltalk robuste Anwendungen zu schreiben als in C++. Ob eine Spracheigenschaft gewollt oder ungewollt ist, sollte einen nicht von einer Bewertung abhalten. Nicht, dass einem statische Typisierung nicht manchmal in Smalltalk fehlen würde, nur ist die Implikation falsch, dass dies zu weniger robusten Programmen führt. Der dynamische Charakter von SpracheSmalltalk ermöglicht u. a. wesentlich bessere Debuggingwerkzeuge und ein ausgefeilteres Exceptionhandling. Buffer Overflows oder Underruns sind konzeptionell ausgeschlossen, Speicherzugriffsfehler ebenfalls. Umgekehrt ist Typsicherheit in C++ nur dann gegeben, wenn man auch stets entsprechende Typen definiert, was für über Basistypen modellierbare Objekte allgemein unüblich zu sein scheint.

Es ist sicher nicht per se so, dass dynamisch typisierte Sprachen den Verzicht auf statische Typprüfungen in überzeugende Vorteile umsetzen können. Smalltalk jedoch ist nicht für Spielzeuganwendungen gedacht. Evtl. könnte der Eindruck entstehen, wenn man sich SqueakSmalltalk oder GNU Smalltalk ansieht, aber die übrigen Smalltalk-Dialekte werden eher in Großprojekten (bei Banken, Versicherungen, Autoherstellern, Logistikunternehmen, etc.) zu finden sein. Ich kann nur jedem empfehlen, sich mit einer Sprache zu beschäftigen bevor man sie kritisiert.

SaschaDördelmann

Zunächst, nein, du warst nicht sachlich geblieben, und zwar ging das gleich mit den ersten beiden Sätzen los. "<X> ist komplizierter als es in vielen Fällen sinnvoll ist." (für einen zusammengesetzten Gegenstand <X>, hier C++) ist eine allgemeingültige Nullaussage, in meiner Wahrnehmung eine Beleidigung an mitdenkende Leser, somit unsachliche Provokation. "Ein wesentlicher Schwachpunkt von C++ [...], der sehr oft als Stärke dargestellt wird, ist die statische Typisierung." ist ebenfalls unsachlich, da der Satz dreist in Form einer Tatsachenfeststellung steht, statt sich als das, was es ist, nämlich allenfalls Tatsachenbehauptung oder Meinungsäußerung, zu erkennen zu geben.

Ok, sehe ich ein. Ärgerlich, dass ich hier provoziere obwohl mir bei der Geschichte der Inhalt wichtig ist. Vielleicht hapert's bei mir noch mit der sprachlichen Differenziertheit. Aber: ist nicht jeder Beitrag in einer Diskussion irgendwie subjektiv? - SD

Zu "Ich kann nach etwa 10 Jahren C++-Erfahrung und 6 Jahren Smalltalk sagen, dass es erheblich einfacher ist, in Smalltalk robuste Anwendungen zu schreiben als in C++.": Nein, das kannst du nicht sagen, allenfalls kannst du sagen, dass es für dich erheblich einfacher ist, in Smalltalk robuste Anwendungen zu schreiben als in C++.

Ok, sehe ich ein. Allerdings kenne ich Leute, die ähnliche Erfahrungen gemacht haben. Den umgekehrten Fall habe ich noch nicht erlebt, was nicht heißen muss, dass der nicht auch vorkommt. - SD

Zur "Reihenfolge": Dass die von mir angegebene Reihenfolge nicht ernst gemeint war, ist doch wohl hoffentlich klar(?). Natürlich halte ich Smalltalk nicht für eine Spielzeugsprache. Meine Reihenfolge ist einfach nur Unfug. Allerdings hattest du angefangen, denn deine Reihenfolge ist ebenfalls Unfug (den du jedoch unverständlicherweise offenbar ernst gemeint hattest).

Wenn ich etwas nicht ernst meine, kennzeichne ich das mit ;-) Smilies. Ich gehe davon aus, dass mein Humor, meine Ironie oder meine Ernsthaftigkeit in Schriftform nicht immer offensichtlich sind. Zur Sache: Generell ergibt sich die Komplexität einer Programmieraufgabe aus einer Vielzahl von Faktoren. Das die Syntax von Smalltalk ungleich einfacher ist als die von Java oder C++ liegt für mich auf der Hand. Nur, folgt daraus auch direkt, dass das Programmieren in einer Sprache mit einfacher Syntax einfacher ist? Nein. Ich fand daher die Idee des Artikels, einen Entscheidungsbaum aufzumalen sehr zündend. Ich bleibe dabei und sehe 'meine' Reihenfolge nicht als Unfug an.

Was du mit "Umgekehrt ist Typsicherheit in C++ nur dann gegeben, wenn man auch stets entsprechende Typen definiert, was für über Basistypen modellierbare Objekte allgemein unüblich zu sein scheint." auszudrücken versuchst, ist mir unklar. Typsicherheit ist in C++ _stets_ gegeben, abgesehen von extra dafür (zur Aufweichung der Typsicherheit) vorgesehenen Casts. Bei mir keimt der Verdacht auf, dass du C++ (trotz der 10 Jahre Erfahrung) nicht richtig kennst.

Typsicherheit in Bezug auf C++-Typen ist natürlich gegeben. Bei der Modellierung habe ich aber gewisse Freiräume. Bei einer Methode, die als Parameter zwei int bekommt, kann ein Vertauschen dieser beiden Parameter nicht vom Compiler entdeckt werden. Alternativ können beide int als verschiedene structs definiert werden. Wenn das entgegen meiner Aussage oft gemacht wird, habe ich mich geirrt. Fehler, die auf Vertauschung von Parametern basieren, erlebe ich in C++ häufiger als in Smalltalk. (Ich führe das z. T. auf die ungewöhnliche Smalltalk-Notation von Methoden zurück.) Zum Thema Erfahrung muss ich leidvoll eingestehen, dass mir der Schritt von C++ nach Smalltalk ungleich leichter gefallen ist, als der zurück nach C++. - SD

VolkerGlave

PS: Habe oben den Verweis auf Stroustrups Entgegnung zu "C++ is too complex" eingetragen.

Nachtrag

Ich habe soeben BruceEckels Artikel "Strong Typing vs. Strong Testing" ( http://mindview.net/WebLog/log-0025/) gelesen und RobertCMartins Artikel "Are Dynamic Languages Going to Replace Static Languages?" ( http://www.artima.com/weblogs/viewpost.jsp?thread=4639) überflogen. Beide räumen statischer Typprüfung ein geringereres Gewicht ein, als sie es einst taten. Das nehme ich (etwas überrascht) zur Kenntnis und muss das Thema zukünftig offener sehen. Danke für die Antriggerung, Sascha.

Ja, die Links gingen kürzlich auch durch die Smalltalk-Newsgroup (zusammen mit http://www.paulgraham.com/hp.html). Ich muss gestehen, dass ich jetzt erst reingeschaut habe - Wirklich lesenswert! - SD

Noch ein Nachtrag, 2003-08-19

In iX 9/2003, S. 44, Artikel "PHP und APS.Net im Vergleich" (es geht also um andere Programmiersprachen, aber egal) wird hingegen wieder strenge Typprüfung propagiert: "[...] PHP 5 widmet sich dem Thema Datentypen [...] überhaupt nicht. Es gibt keine Möglichkeit, den Datentyp einer Variablen festzulegen. Für große Projekte und die Teamarbeit ist das ein Handicap. Inkonsistente Datentypen führen zu schwer zu entdeckenden Programmierfehlern. Anfängern mag dieser Mangel den Eintieg erleichtern, letzlich behindert es jedoch die Etablierung von PHP 5 für große Projekte. [...]"

Für all jene, die grundlegende Eigenschaften von C++ schätzen, es aber zu kompliziert finden: Vielleicht fühlt ihr euch bei SpracheD besser aufgehoben. -- SaschaDördelmann

Vermutlich trifft dein Tipp zu, mir geht es jedenfalls so, dass ich mit C++ nie warm geworden bin, mich aber mit D (obwohl noch pre-1.00) wohl fühle. Komplexität ist - mit Templates und Mixins - allerdings durchaus auch im Übermaß vorhanden.

Zu "...ich habe das OO-Paradigma noch nie als Korsett empfunden. Die Designidee hinter der Objektorientierung war, ein Computerprogramm auf kleinere Einheiten herunterzubrechen ... In diesem Ansatz kann ich keinerlei Beschränkung entdecken.":

• Ich habe nicht das Gefühl, dass es in OO um kleinere Einheiten ging. Es ging eher um größere Einheiten und besser abgegrenzte Einheiten (im Verhältnis zu den alten prozeduralen Funktionen und Datenstrukturen).
• Eine Beschränkung ergibt sich IMHO im Denken:
• Jedes Objekt ist ein gutes Objekt. OO hat nie eine kritisch diskriminierende Haltung gegenüber den vielfältigen Möglichkeiten von OO Implementierungen hervorgebracht. Komplexität (3500 Klassen in Java 1.2) versus Einfachheit ist nie als Problem gesehen worden.
• Nur ein als Objekt implementiertes Objekt ist ein gutes Objekt. OO hat kein gutes Verhältnis zu realen Objekten, die nicht sinnvoll als Objekt implementiert werden können.
• Insgesamt scheint mir die OO Welt der Implementierung Priorität gegenüber der Modellierung einzuräumen. Während ich denke, dass es umgekehrt sein müsste.

Die von dir beschriebene unkritische Haltung kenne ich so nicht. Immerhin hat die OO-Kultur Dinge wie Design-Patterns und eXtreme Programming hervorgebracht. Man darf nur nicht annehmen, alle OO-Programmierer wären Ästheten und der Rest Hacker (oder umgekehrt). Es ist wohl tendenziell eher so, dass ein lausiger Programmierer ein lausiger Programmierer bleibt, auch wenn er es mit einer anderen Programmiersprache versucht. Den letzten Punkt verstehe ich nicht so ganz. OO und UML sitzen z. B. ziemlich in einem Boot. Erst wenn es an generische oder funktionale Programmierung geht, habe ich mit UML Probleme.-- SDö

Andererseits sind DesignPatterns auch nur Notnägel für fehlende Abstraktion in der Wirtssprache und sogar das Vorzeigeprojekt der XP-Leute (C3 - ChryslerComprehensiveCompensation?) wurde eingemottet.

Durchgriff von Modellierung bis zum Ablauf im Maschinencode

Programmiert wird, indem das Problem zergliedert und modelliert wird, dann compiliert und gestartet. Was genau die CPU auf dem Mainboard treibt, wird schon richtig sein. Das geht bei typischen PC-Anwendungen gut, nicht aber bei Echtzeitsteuerungen. Auch bei typischen PC-Programmen könnte man ein besseres Gefühl haben, wenn man weiß, dass jemand im Bekanntenkreis oder im Umkreis von 100 km - wie auch immer - weiß, was die CPU tut. Ich meine, nicht die Verantwortung und die Beherrschung der Technik wenigen überlassen, die weit weg sind.

Da ich den Umgang mit CPUs selbstaufgelötet von Anfang an gelernt habe (Z80 in Assembler), und jetzt OO-Programmierung betreibe, gehöre ich zu denjenigen durchaus anzutreffenden Typen, die diesen Durchgriff vom Entwurf bis zum Prozessor beherrschen könnten. Das ist auch notwendig, denn wenn eine Echtzeitsteuerungs-Software bockt, aus sonstwas für Gründen, dann muss auch mal Hand angelegt werden und ein Speicherauszug in Hexa betrachtet werden, um die Ursache, beispielsweise eine fehlende Dateneingabe, oder einen Hardwarefehler in einer selbstverantworteten Anschaltung, zu erkennen.

In diesem Zusammenhang greift die Programmiersprache C. Grob gesagt, C ist ein besserer Makroassembler, und das ist auch gut so. Bei Programmzeilen in C habe ich, ohne in's Listing zu schauen, eine grobe Vorstellung, was der Prozessor treibt. Zusätzlich gibt es das Listing, oder im Visual Studio die Dissassemblierungsansicht usw. C ist damit ideal geeignet aus dieser Sicht.

Als Programmiersprache zum wirklichen Programmieren ist C ungeeignet. Punkt. Dazu ist schon vieles gesagt. - Und C++ ist auch nicht besser. Nicht wegen der Abwärtskompatibilität zu C, sondern eher weil wirkliche Anforderungen an die Programmierung auch in C++ ungelöst sind. C++ ist zu komplex, enthält zuviele Dinge ... alles oben bereits erwähnt.

Ich arbeite mit einem UML-Tool, grafische Modellierung, automatische Codegenerierung, Inhalte von Methoden werden mit C(++) gefüllt. C++ tritt als Zwischensprache für die Generierung auf. In diesem Zusammenhang ist C++, besser wäre C, richtig. Die Programmzeilen, die in die Methoden geschrieben werden, sehen an sich (fast) genauso wie Java oder ähnliches aus, und wünschenswert wäre, wenn man dort wirklich nicht in der Zielsprache schreiben müsste, sondern in einer Metasprache. Ich halte Java-style als Metasprache für sinnvoll. Aber soweit sind die UML-Tool-Hersteller noch nicht.

Damit ergibt sich folgende Konstellation:

 Modellierung in UML, grafisch, Objektmodell-Diagramme + Statecharts, 
 Funktionalität mit Metasprachen-Programmzeilen ergänzen.

  ==>

 Codegenerieren in C, damit ist der Durchgriff vom Modell zum Code möglich

  ==>

 Maschinencode mit C-Compiler, Durchgriff zum Maschinencode ist möglich

PS: Übrigens, auch bei Java habe ich eine ziemlich genaue Vorstellung, was die Virtuelle Maschine treibt, auch wenn ich mir noch nie den Bytecode angeschaut habe (habe ich wirklich noch nie, keine Zeit gehabt, kann mir aber denken, wie er aussieht). Die VM ist eine Schale, auf die man sich verlassen kann, ähnlich wie der Prozessor ein Hardwareschaltkreis ist, dessen Arbeitsweise man nachvollziehen aber nicht im Detail kennen braucht.