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

[Daniel Thoma]

Hallo Martin,

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.

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. Ich stimme Dir zu, dass Bibliotheken zu verwenden ein Risiko ist und man oft besser keine Bibliothek, als eine Bibliothek, die man nicht versteht, verwendet.
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.
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?

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. So etwas wie Listen, Strings etc braucht man in jedem Programm, die APIs sind einfach zu verstehen und es führt definitiv zu besseren und schneller entwickelten Programmen, so etwas zu verwenden.

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. 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.
Direkte Pointerarithmetik führt auch praktisch immer zu Fehlern und daraus resultierenden Sicherheitsproblemen, die es mit automatischer Speicherverwaltung schlicht nicht gibt.
Dann noch zur Geschwindigkeit von JITs: Wirklich objektorientierte Programme haben sehr viele virtuelle Methoden. Damit steht erst zur Laufzeit fest, welche Methoden aufgerufen werden. Für solche Methoden ist ein Methode-Inlining zur Compile-Zeit unmöglich. Ein JIT-Compiler kann das tun, weil er weiß, welche Methode (meistens) aufgerufen wird.
Daher haben JIT-Compiler für objektorientierte Sprachen durchaus Vorteile.
Natürlich kann man ein überschaubares Problem in C oder meinetwegen auch Assembler effizienter implementieren, in einem großen, stark modularisierten Programm ist das aber eben schon schwerer realisierbar und auf jeden Fall sehr viel aufwendiger, der Aufwand muss sich dann eben auch lohnen.

Ich würde generell für schnell zu entwickelnde Desktopanwendungen auch zu Java raten. Die Technologie scheint mir auch aus Anwendersicht weit weniger Probleme zu machen, als ich mit typischen Windows VB-Irgendwas Anwendungen habe (ok ich kenne mich damit nicht aus). Bei der Entwicklung muss man sich weitestgehend keine Gedanken über Details der Zielplattform zu machen (insbesondere auch nicht um verschiedene Windowsversionen).
Im konkreten Fall sehe ich nur bei der Anbindung der seriellen Schnittstelle Probleme. Für USB gibt es meines Wissens eine Java-API, für die serielle Schnittstelle bin ich mir nicht ganz sicher, evtl. müsste man da auch eine native API zurückgreifen.

Grüße

Daniel