Die Wahl der Programmiersprache bei einer GUI. Ist Python wirklich das richtige dafür?

rüdiger

Bei der GUI ist ja die Ausführungsgeschwindigkeit in der Regel nicht das Problem, da du ohnehin die größte Zeit auf Usereingaben wartest. Wenn dein Backend komplexer ist, kannst du das ja auch in C++ schreiben und mit der Skriptsprache deiner Wahl ansteuern.

was GUIs angeht: noch einfacher als mit Python geht's oft mit Tcl/Tk. Außerdem ist die Syntax eleganter.

Naja die Frage nach Performance verschwindet immer weiter in den Hintergrund mit durchschnittlichem Speicher von 2-4 GB.
Grade bei Desktop Anwendungen, wenn NetBeans 400MB Ram frisst, kommts auf die 200 von Firefox auch nicht mehr drauf an.. ^^ (-.- iwie traurig aber egal)
Da kannst du es dir doch wirklich leicht machen, und das Framework deiner Wahl nehmen. C++ mit GTK oder Qt is auch recht easy mit nem GUI-Editor, oder Java mit SWT, oder Tk mit Perl, oder was dir sonst noch einfällt. ( ncurses mit C? ) Was dir am bequemsten über die Finger geht halt.

Ich frag mich im Moment grad, warum es so was einfaches wie Rails nicht für den Desktop Bereich gibt. Tendiere dazu, meine Apps als WebApp zu machen, nur weils schneller gewickelt ist

hustbaer

reiner on rails schrieb:

Naja die Frage nach Performance verschwindet immer weiter in den Hintergrund mit durchschnittlichem Speicher von 2-4 GB.
Grade bei Desktop Anwendungen, wenn NetBeans 400MB Ram frisst, (...)

Was hat der vorhandene Speicher mit rechenintensiven Programmen zu tun???

braucht viel Speicher != braucht dicke CPU

Python, Tcl, Ruby, Lua etc. sind nicht so sehr wahnsinnig Speicher-hungrig, sondern einfach langsam.

Blue-Tiger

ii__ii schrieb:

Python ist nicht nur eine Skriptsprache. Mann kann damit wunderbar objektorientiert Programmieren. Es gibt auch wxPython, kannst es ja mal damit probieren. SPE (Python-Editor) ist z.B. damit programmiert: http://pythonide.blogspot.com/

wie ich SPE vor 2 Jahren ausprobiert hab, war gerade seine gefuehlte "Langsamkeit", dass was mich davon abhielt den Editor weiterzuverwenden. k.A. ob das besser geworden ist.

Moin,
wie geht man überahupt allgemein vor, einem (Konsolen-)Programm eine Oberfläche
zu verpassen ohne großartig etwas am Programm zu verändern.
Persönlich gefällt mir idee, die Oberfläche als Client laufen zu lassen
und das eigentliche Programm als Server, also zwei relativ unabhängige
Programme, also der Client brauch dann ja nur noch ne Ausgabe/Eingabe Klasse, die alles an evtl. clienten schickt.
Und für den Clienten stellt sich dann wieder die Frage des Threadstaters.
(Was die Server/Client "architektur" unterstütz da man die Oberfläche dann rein in einer Script sprache entwickeln kann, die eine Netzwerok unterstützung hat)

Aber gibt es evtl auch andere Möglichkeiten.

MFG Papier

Nagila Hawa

http://de.wikipedia.org/wiki/MVC

Python als Sprache für Anwendungen zu benutzen ist generell in Ordnung. Viele Pythonfans vergessen aber, dass Performance nicht nur bei rechenintensiven Funktionen, sondern IMMER eine Rolle spielt. Zum Einen, weil die Anwendungen nicht alleine auf dem Rechner sind, sondern sich die Ressourcen mit anderen Anwendungen teilen müssen, zum Anderen, weil es auch Leistungsschwächere Rechner gibt.

Ich habe mir mal versucht ein voll funktionsfähiges aber ressourcenschonendes Desktopsystem zusammen zu bauen. Die meisten Python-Programme, die auf dem ersten Blick "leicht" aussahen, sind wieder rausgeflogen.

Wenn irgendwo ganz dringend eine Anwendung gebraucht wird und man nichts passendes findet, dann kann man Python verwenden. Aber den 5000. Musikspieler sollte man nicht ernsthaft mit Python schreiben. Ist zumindest meine Meinung.

Nagila Hawa schrieb:

Ich habe mir mal versucht ein voll funktionsfähiges aber ressourcenschonendes Desktopsystem zusammen zu bauen. Die meisten Python-Programme, die auf dem ersten Blick "leicht" aussahen, sind wieder rausgeflogen.

Wenn irgendwo ganz dringend eine Anwendung gebraucht wird und man nichts passendes findet, dann kann man Python verwenden. Aber den 5000. Musikspieler sollte man nicht ernsthaft mit Python schreiben. Ist zumindest meine Meinung.

Und ich kann da sogar ein gutes Beispiel nennen:
Deluge, ein Bittorrent Client geschrieben in Python mit GTK+ Oberfläche.

Das Ding braucht auf Windowssystemen sage und schreibe über 200 MB auf der Festplatte, da auch Python selbst und GTK noch dabei ist.
Und im RAM gehen ebenfalls über 150 MB dafür drauf und all das dafür,
daß man einen popeligen Torrent Client hat.

µtorrent, ein Bittorrent Client der in C geschrieben ist, kann funktional genau das gleiche, aber es braucht auf der Festplatte max. 1 MB und im Speicherverbrauch ist es auch extrem sparsam.

Von daher würde ich mal sagen, Python ist ok für Prototypen oder für Software die so spezielle ist, daß es keine Alternativen gibt,
aber wenn ich Alternativen in C/C++ habe, wie beim Torrent Client Beispiel, dann sollte man lieber diese nehmen.

Sprachen von Anfang an aus angeblichen Performancegründen auszuschließen, ist wohl das, was man premature optimization nennt.

volkard

the snake schrieb:

Sprachen von Anfang an aus angeblichen Performancegründen auszuschließen, ist wohl das, was man premature optimization nennt.

ganz falsch. die frage nach der angemessenen sprache sollte ganz am anfang stehen. denn es ist ne scheiß-arbeit, das programm nachträglich auf eine andere sprache zu portieren.

würd' sagen, das hängt davon ab, wie sich der Aufwand für Analyse/Design zum Aufwand für's Codieren verhält.

Ich hab' mal ein 15000-Z.-Projekt von C/C++ auf Python portiert, das Portieren dauerte (inkl. Zeitaufwand für's Lernen der Python-Syntax) 2-3 Wochen und damit einen winzigen Bruchteil der Zeit, die das Design und die Implementation der C/C++-Version dauerte, da fast die gesamte Denkarbeit (Datenstrukturen usw.) bereits bei der ersten Implementation geleistet worden war, die Spezifikation "stand", und das fertige Klassendesign lediglich in die Python-Syntax "gedolmetscht" werden mußte.

Aber Du hast natürlich recht, noch schneller ist, wenn man gleich die endgültige Sprache wählt, vor allem bei richtig großen Projekten mit 1e5+ Zeilen. Falls man keinen "proof-of-concept" braucht, den kann man wiederum oft schneller in einer Sprache wie Python herstellen.

u_ser-l schrieb:

würd' sagen, das hängt davon ab, wie sich der Aufwand für Analyse/Design zum Aufwand für's Codieren verhält.

Ich hab' mal ein 15000-Z.-Projekt von C/C++ auf Python portiert, das Portieren dauerte (inkl. Zeitaufwand für's Lernen der Python-Syntax) 2-3 Wochen und damit einen winzigen Bruchteil der Zeit, die das Design und die Implementation der C/C++-Version dauerte, da fast die gesamte Denkarbeit (Datenstrukturen usw.) bereits bei der ersten Implementation geleistet worden war, die Spezifikation "stand", und das fertige Klassendesign lediglich in die Python-Syntax "gedolmetscht" werden mußte.

Wieso habt ihr ein fertiges Programm von C++ nach Python portiert?

weil das System in so kurzer Folge an sich ständig erweiternde Anforderungen angepaßt werden mußte, daß eine Neuimplementation in einer rapid-prototyping-tauglichen Sprache der effizienteste Weg war.

Ach so - hab' mich im Post von 23:00 unglücklich ausgedrückt: daß die Spezifikation "stand", bezieht sich auf den Zeitpunkt der *Neu*implementation, soll heißen, die Spezifikation war nun zu *diesem* Punkt vorgegeben - *nach* Neuimplementation änderte sich die Spezif. erwartungsgemäß weiterhin, das war ja gerade der Grund dafür, auf eine dynamische Sprache zu portieren.

hustbaer schrieb:

reiner on rails schrieb:

Naja die Frage nach Performance verschwindet immer weiter in den Hintergrund mit durchschnittlichem Speicher von 2-4 GB.
Grade bei Desktop Anwendungen, wenn NetBeans 400MB Ram frisst, (...)

Was hat der vorhandene Speicher mit rechenintensiven Programmen zu tun???

braucht viel Speicher != braucht dicke CPU

Python, Tcl, Ruby, Lua etc. sind nicht so sehr wahnsinnig Speicher-hungrig, sondern einfach langsam.

hab ich was von CPU gesagt?
das problem bei der gui ist doch nicht die ausführungsgeschwindigkeit, da man eh auf den user wartet. hier zählt ein kleiner footprint mMn mehr.
und java guis sind einfach dicker als native.

otze

volkard schrieb:

the snake schrieb:

Sprachen von Anfang an aus angeblichen Performancegründen auszuschließen, ist wohl das, was man premature optimization nennt.

ganz falsch. die frage nach der angemessenen sprache sollte ganz am anfang stehen. denn es ist ne scheiß-arbeit, das programm nachträglich auf eine andere sprache zu portieren.

Richtig. Die Frage ist aber, ob Geschwindigkeit dafür das oberste Kriterium sein sollte. Es gibt ja diesen alten Lehrsatz, dass ein Programm 90% der Zeit in 10% des Codes verbringt.

Nun sehe ich Python. Eine Sprache die zwar nicht die schnellste ist, aber in der man schnell und vor allem sauber Programmieren kann und die auch eine einfache Anbindung an C/C++ Code bietet. Warum sollte ich dann nicht, wenn die Wahl auf eine C-ähnliche Sprache fällt, die unkritischen 90% des Codes in Python schreiben, und die restlichen 10% dann in einer schnelleren Sprache?

Das Ganze hat ja auch in sofern Vorteile, als dass man sich über die Portierbarkeit von 90% des Codes keine Gedanken mehr machen muss. Darum kümmert sich Python.

python hat übrigens den Nachteil, daß die Sprachdefinition nicht feststeht, d.h. man ist gut beraten, einzukalkulieren, daß man komplexere Programme hin und wieder an neue python-Sprachversionen anpassen sollte/muß, wenn man die jeweils aktuellen Interpreter benutzen will. Es gibt für den Übergang allerdings einige (halb)automatische Portierungshilfen.

reiner on rails schrieb:

hab ich was von CPU gesagt?

nicht direkt, aber es geht in diesem thread um guis, scriptsprachen und deren performance. du hingegen schreibst irgendwas über java und setzt dabei performance mit speicherbedarf gleich, was ziemlicher unsinn ist.

u_ser-l schrieb:

python hat übrigens den Nachteil, daß die Sprachdefinition nicht feststeht, d.h. man ist gut beraten, einzukalkulieren, daß man komplexere Programme hin und wieder an neue python-Sprachversionen anpassen sollte/muß, wenn man die jeweils aktuellen Interpreter benutzen will. Es gibt für den Übergang allerdings einige (halb)automatische Portierungshilfen.

Python 2.5 und 2.6 bleiben aber konstant, bzw. werden nicht mehr allzu großartig verändert. Anpassen muss man die Programme halt von 2.5 && 2.6 auf 3.x, wobei das zur Zeit in der Tat nicht zu empfehlen ist ...