C++, C#, Visual C#, Java, Tcl/Tk, ...?

[Der Martin]

Hallo Daniel,

Ich habe irgendwie den Eindruck, dass Du vor allem irgendwelchen systemnahen Kram vorzugsweise für eingebettete Systeme schreibst und dabei die Anwendungen auch noch nicht so wahnsinnig groß sind.

das trifft's teilweise. Ja, ich schreibe oft systemnahe Embedded-Anwendungen. Ich schreibe aber auch immer wieder mal Windows-GUI-Anwendungen.

Auf Bibliotheken generell zu verzichten, ist doch Wahnsinn. Es macht komplexere Anwendungen praktisch unmöglich (man kann einfach nicht ständig alles neu erfinden) und zweitens auf fehlerhafter.

Nein, man muss ja auch nicht alles neu erfinden, schon gar nicht "ständig". Das Zielsystem (in meinem Fall Windows) stellt ja auch ohne Zusatz-Bibliotheken schon eine ganze Menge an Funktionalität zur Verfügung. Wenn ich Windows-Applikationen schreibe, dann verwende ich ausschließlich das Windows-API und sonst nichts. Okay, natürlich greife ich auf einen Pool selbstgeschriebener Bausteine zurück, der kontinuierlich wächst.

Ab einem gewissen Komplexitätsgrad lohnt sich eine Bibliothek aber und wenn man mehrere Anwendungen eines Typs hat, lohnt sie sich auch noch viel schneller.

Ja, und was spricht dagegen, sich diese Bibliothek im Lauf der Zeit selber aufzubauen? Der Vorteil -ich kann es nicht oft genug betonen- liegt doch darin, dass man den Code dann exakt kennt und auch exakt weiß, was dieser Code tut, was er leisten kann und was nicht.

Wie schreibst Du GUIs ohne Bibliotheken? Du programmierst wirklich die gesamte Logik für das Zeichnen und die Ereignisverarbeitung selbst, womöglich noch für jede Anwendung, die Du schreibst erneut?

Ich nutze das API von Windows, das mir eine Menge von GUI-Grundfunktionen zur Verfügung stellt. Darüber hinaus: Ja, die Ereignisbearbeitung ist jedesmal wieder individuell neu.

Java, .NET u.ä. bieten ja vor allem zwei Dinge, eine Laufzeitumgebung für objektorientierte Programme mit GC etc. und eine Standardbibliothek.
An der Standardbibliothek gibt es meines Erachtens nicht viel zu zweifeln.

Richtig - ich nutze ja auch die C-Standardbibliothek, ansonsten die intrinsischen Datentypen von C. Höhere Strukturen realisiere ich in der Tat lieber selbst.

Nun zur Laufzeitumgebung: Bei manuell verwaltetem Speicher muss man immer wissen, wann ein Objekt nicht mehr benötigt wird. Dies schränkt die Möglichkeiten der Modularisierung ein.

Nicht im geringsten. Man muss nur seine Module kennen, man muss wissen, "wer" Speicher belegt, und "wer" ihn wieder freigeben muss.
Davon abgesehen stellt sich das Problem nur selten: Dynamisch erzeugte Objekte sind in der Regel lokale Strukturen innerhalb einer Funktion, die beim Beenden der Funktion wieder freigegeben werden.

Wenn ein Modul A bsw Objekte erzeugt, die andere Module verwenden, muss man immer einen (fehleranfälligen) Mechanismus bauen, um festzustellen, wann diese Objekte nicht mehr benötigt werden. Das macht richtige Objektorientierung sehr schwierig.

Nein. Man muss nur die Erzeugung und Entsorgung von dynamischen Datenstrukturen sauber ordnen. Es ist IMHO eine Unart vieler objektorientierter Ansätze, Objekte in Modul A zu erzeugen und in Modul B freizugeben. Das gehört sich nicht. Wer eine Datenstruktur dynamisch anlegt, hat auch dafür Sorge zu tragen, dass sie ordentlich wieder freigegeben wird. Alles andere ist meines Erachtens Spaghetticode.

Direkte Pointerarithmetik führt auch praktisch immer zu Fehlern und daraus resultierenden Sicherheitsproblemen, die es mit automatischer Speicherverwaltung schlicht nicht gibt.

Im Gegenteil: Sie eröffnet Möglichkeiten, die mit anderen Techniken quasi undenkbar sind. Ich weiß nicht, wo du da das Problem siehst - solange man nicht den Überblick oder die Disziplin verliert.

Dann noch zur Geschwindigkeit von JITs: Wirklich objektorientierte Programme ...

Ich habe es kürzlich erst gesagt: Objektorientierung findet in den Köpfen der Programmierer statt. Wenn die Programmiersprache das durch spezielle Notation oder gewisse Sprachstrukturen unterstützt, ist das aus meiner Sicht meistens ein Nachteil, weil dadurch der Blick des Programmierers von den entscheidenden Punkten abgelenkt wird, er quasi "in höheren Sphären schwebt". Damit verliert man das Gefühl dafür, was im eigenen Programm wirklich passiert.
Das ist ein Grund, warum ich "objektorientierte Programmiersprachen" ablehne und und objektorientierte Denkweisen lieber selbst nachbilde. Je nach Applikation bis herunter auf Assemblerebene. Dann weiß ich nämlich auch, was da wirklich abläuft.

Ich würde generell für schnell zu entwickelnde Desktopanwendungen ...

Definiere "schnell".
Abhängig von der Komplexität der Aufgabenstellung komme ich mit meinem Ansatz (Standard-C und reine API-Programmierung) meist innerhalb von ein bis maximal drei Tagen zu einem funktionsfähigen Grundgerüst. Das ist dann aber auch so sauber strukturiert, dass ich ohne Schwierigkeiten an allen Stellen Details ändern oder nachrüsten kann.

Nochmal: Ich erwarte nicht, dass jeder meine Programmier-Ideale nachvollziehen kann und damit ebensogut klarkommt. Aber für mich hat sich diese Vorgehensweise in vielen Jahren als optimaler Ansatz herauskristallisiert.

Schönes WE noch,
 Martin