ScriptsprachenHatte die letzten Tage wieder eine der Phasen, wo ich entschlossen war, Scriptsprachen wie
Python zu benutzen, nur um reumütig wieder zu C++ zurückzukommen. Es gibt zwei Probleme bei Python, Ruby und Perl, mit denen ich nicht zurechtkomme:
- Es gibt keine konsequente und durchgängige API-Dokumentation. Bei Qt und KDE kommt man sehr weit mit den Online-Dokumentationen, und bei Java ohnehin. Aber Scriptsprachen haben durchgängig schwache Online-Dokumentation, und dabei vor allem ein Problem: es geht aus den Prototypen der Funktionen niemals der benötigte Typ der Parameter hervor. Bei simplen Funktionen ist das kein Problem. Bei komplizierten Funktionen, die Objekte als Parameter bekommen, kann man nur raten. Wenn die Dokumentation dann wenigstens im Text die Typen erwähnen würde (was unpraktisch, da weniger schematisch wäre, aber zumindest eine Lösung ohne Raten), könnte ich damit leben. Aber wenn ich für jede Funktion mir den Source Code ansehen muss, ist jegliche Zeitersparniss der Scriptsprache dahin.
- Es fehlt mir bei allen üblichen Kandidaten die Möglichkeit, einfach und ohne grössere Installation GUI Applikationen in Python oder Ruby zu schreiben (Perl mag ich nicht für GUIs). TK bietet keine Zeitgemässe Oberfläche, PyQT/PyKDE ist kompliziert zu installieren und kann keine Designer-UI-Files einlesen, GTK ist nicht akzeptabel, wxWindows fehlt das Qt Backend und ist auch nicht so toll. Solange es keine einfache Möglichkeit gibt, beliebige C++/C APIs anzusprechen, zB durch ein COM-ähnliches Modell, lohnt sich der Umstieg für mich einfach nicht, weil ich meine gewohnten, umfangreichen APIs nicht habe und mich wieder mit Kleinkram abgeben muss, der in C++ einfacher gelösst wird weil die APIs einem mehr Arbeit abnehmen. Ein Komponentenmodell wie The Hub steht weit oben auf meiner Wunschliste.
geschrieben um 23:04. (0 Kommentare, Direkter Link)
