Python GUI, C++ Kern - Erfahrungen?



  • !rr!rr_. schrieb:

    ich durfte seinerzeit die mit python 2.2 oder 2.3 entwickelte Software auf python 2.5 portieren und deshalb an > 100 Stellen ändern, u.a. alle "string based exceptions" (glaube ich, ist schon ein paar Jahre her). War kein Vergnügen, und ich lernte den Wert einer unveränderliche Sprachdefinition zu schätzen.

    Portier mal eine vergleichbare Anwendung von Windows auf Linux oder umgekehrt (in C++). Und vergleiche mal wie lange du dafür brauchst.

    Python looks now pretty good, doesn't it?



  • sdfsdfd schrieb:

    Portier mal eine vergleichbare Anwendung von Windows auf Linux oder umgekehrt (in C++). Und vergleiche mal wie lange du dafür brauchst.

    0 Sekunden.

    sdfsdfd schrieb:

    Python looks now pretty good, doesn't it?

    Nicht wirklich. 😃



  • mir gefällt's nicht so.

    Ist irgendwie nicht Fisch und nicht Fleisch. Für eine Skriptsprache a la Perl, Tcl oder bash eigentlich zu üppig. Für performante Anwendungen a la C/C++ zu langsam. Änderungen am Sprachkern. Das Prinzip "least surprise" ist gut verwirklicht, andererseits aber keine konsequente "minimal syntax"-Sprache, wie es für eine Lernsprache optimal wäre. Das Objektmodell und die "self"s wirken auf mich "angeflanscht". Gibt es einen guten Debugger ? Eine gute IDE ? Refactoring ?



  • cooky451 schrieb:

    sdfsdfd schrieb:

    Portier mal eine vergleichbare Anwendung von Windows auf Linux oder umgekehrt (in C++). Und vergleiche mal wie lange du dafür brauchst.

    0 Sekunden.

    sdfsdfd schrieb:

    Python looks now pretty good, doesn't it?

    Nicht wirklich. 😃

    Trottel.



  • Also danke schonmal für Eure Antworten, wobei mir schon wieder zuviel gestritten wird ob Python toll oder nicht ist. Python gefällt mir prinzipiell schon ganz gut, es geht mir hier nur um die GUI Programmierung in Python und der Schnittstelle zu C++ und ob jemand von Erfahrungen in ernsthaften und großen Projekten (oder natürlich auch überhaupt irgendwelchen Erfahrungen) berichten kann.
    Zu C# kann ich noch sagen, dass die Performance für die meisten Anwendungen ausreichen wird und nur in Ausnahnmefällen durch unmanaged C++ Code erweitert werden müsste. Trotzdem habe ich aber auch C++ Anteile.

    Wieso ich komplett C++ (Qt o.ä) auschließe: Unsere Anwendungen haben of einen recht überschaubaren Domain Layer mit recht komplexer Benutzerschnittstelle obendrauf. Das Modellieren des physikalischen Modells durch den Anwender ist oft sehr komplex und damit auch die GUI und damit die Entwicklung dieser.
    Erfahrungsgemäß nimmt die Entwicklung, Testen und Debuggen des GUI Anteils einen der größten Teile der Zeit in Anspruch. Sicher kann man mit dem richtigen Framework auch in C++ gut GUIs programmieren. Leider haben wir aber nur einen guten C++ Programmierer und jeder von uns weiß denke ich, wie lange man braucht um ein solcher zu werden.

    Wieso ich Delphi/VCL ausschließe: Delphi geht mir tierisch auf den Sack! Ich hab vor etwa einem Jahr nach längere Analyse unserer "Altlasten" beschlossen, die System nicht auf eine andere moderne Technologie zu portieren, sondern lediglich ein paar neue Delphi 2010 Lizenzen beschaffen zu lassen, um das bis dato verwendete Delphi5 zu ersetzen. Heute muss ich sagen, dass das die teuerste und schlechteste IDE ist mit der ich bisher gearbeitet habe. Gleichzeitig ist die Sprache auf dem heutigen Stand auf den ersten Blick ganz schön anzusehen, aber bei genauerem Hinsehen durch ständige Richtungswechsel vollkommen verworren, der Compiler zudem total verbuggt.
    Hätte ich eine andere Meinung über Delphi, wäre es sicher die sinnvollste Lösung. Aber ich bin der Meinung, dass es keinen Sinn mehr macht länger daran festzuhalten.

    Vielleicht werde ich demnächst einfach mal ein kleines Projekt Python/C++ starten. Kann irgendwer was zu IDEs sagen? Ich denke ich würde sonst mal mit Eclipse pyDev pyQt C++ starten.



  • Ich hab schon in zwei größeren Projekten mitgearbeitet, in denen Python für Frontend und C++ für Backend eingesetzt wurde, verbunden jeweils mit boost python.

    Das Ganze funktioniert ganz gut, es gibt aber ein paar Haken, z.B. kann man natürlich nur eine der Sprachen gleichzeitig debuggen.

    Der Verbund ist imo eine ganz gute Lösung - besonders für Dich, da dir ja einige Alternativen wegfallen.



  • fdfdg schrieb:

    Ich hab schon in zwei größeren Projekten mitgearbeitet, in denen Python für Frontend und C++ für Backend eingesetzt wurde, verbunden jeweils mit boost python.

    Mit welcher IDE und welchem Framework habt ihr da gearbeitet? Ist das zu empfehlen?
    Habt ihr Unit Tests geschrieben? Wenn ja, wie den C++ Code getestet? Per C++ UnitTests oder geht das auch gut über Python.



  • brotbernd schrieb:

    Wieso ich komplett C++ (Qt o.ä) auschließe: Unsere Anwendungen haben of einen recht überschaubaren Domain Layer mit recht komplexer Benutzerschnittstelle obendrauf. Das Modellieren des physikalischen Modells durch den Anwender ist oft sehr komplex und damit auch die GUI und damit die Entwicklung dieser.
    Erfahrungsgemäß nimmt die Entwicklung, Testen und Debuggen des GUI Anteils einen der größten Teile der Zeit in Anspruch. Sicher kann man mit dem richtigen Framework auch in C++ gut GUIs programmieren. Leider haben wir aber nur einen guten C++ Programmierer und jeder von uns weiß denke ich, wie lange man braucht um ein solcher zu werden.

    Ich mutmaße eure GUI-Architektur ist nicht gut auf Testing so sprechen, lass dich etwas von WPF inspirieren. Test sind sehr einfach dafür zu schreiben.



  • Zeus schrieb:

    Ich mutmaße eure GUI-Architektur ist nicht gut auf Testing so sprechen, lass dich etwas von WPF inspirieren. Test sind sehr einfach dafür zu schreiben.

    Du sprichst das "aufwendige Testen" an? GUIs testen wir zur Zeit gar nicht automatisiert. Ich bin froh, dass ich jetzt seit einiger Zeit überhaupt langsam Unit Tests einführen konnte ohne größere Widerstände. Es ist halt keine Softwarebude und es wurde viele viele Jahre auf ziemlich chaotischem Niveau gewerkelt. Zum Glück sind aber alle recht offen für neue Dinge.

    Ich meinte halt eigentlich nur, dass die GUI Entwicklung einen hohen Anteil hat und die Erfahrung von einen einzelnen C++ Programmierer (das bin ich 🤡 ) da nicht ausreicht.
    Mit WPF hab ich ja auch als erste geliebäugelt.

    Ach da fällt mir ein, ich hatte es im ersten Post schon angedeutet. Dieses MS Gerücht die Zukunft läge bei HTML5+Javascript. Hat da jemand eine Meinung zu?



  • brotbernd schrieb:

    Ach da fällt mir ein, ich hatte es im ersten Post schon angedeutet. Dieses MS Gerücht die Zukunft läge bei HTML5+Javascript. Hat da jemand eine Meinung zu?

    Ich denke sowas in der Art wohin Qt will: QML/Javscript
    http://doc.qt.nokia.com/latest/qdeclarativejavascript.html



  • brotbernd schrieb:

    Es sind hauptsächlich Delphikenntnisse vorhanden, zum Teil auch rudimentäre C# Grundlagen, C++ eigentlich nur bei mir.

    Unabhaengig davon wie toll Sprache A und wie schlecht Sprache B ist:
    warum willst du fuer neue Anwendungen 2 neue Sprachen und ein neues GUI Toolkit einfuehren fuer die kein Know How vorhanden ist?

    Lohnt sich sowas wirklich? Oder waere es nicht besser zB .NET zu nehmen und einen Teil der Entwickler weiter in Delphi.NET arbeiten zu lassen?



  • Shade Of Mine schrieb:

    Lohnt sich sowas wirklich? Oder waere es nicht besser zB .NET zu nehmen und einen Teil der Entwickler weiter in Delphi.NET arbeiten zu lassen?

    Das ist ja sozusagen meine erste Variante. Wenn jemand kein C# kann, kann er auch in Delphi oder VB arbeiten. Wobei ich allerdings alle ermutigen würde langfristig doch in einer Sprache zu arbeiten. Die Variante .Net ist für mich keinesfalls gestorben, ich seh mich nur nach Alternativen um.
    Ich hatte mir damals bei der Untersuchung für die Portierung der alten System auch mal angesehen wie der Schritt vom vorhandenen Delphi/vcl zu Delphi.NET (bzw. Delphi Prism wie es sich jetzt [jetzt immer noch?] nennt) ist, sowohl durch manuelle Portierung als auch mit Hilfe so eines tollen Konvertierungstools (das, wie zu erwarten war nur Müll produzierte). Naja ich hatte beschlossen, dass die Sprachen im Detail doch recht weit auseinander liegen und sich der Aufwand nicht lohnt bzw. ich wenn, direkt auf C# portieren/umschulen würde.
    Es sind zwar zur Zeit hauptsächlich Delphi Kenntnisse vorhanden, aber wir werden in Zukunft die Softwareecke weiter aufbauen und da werde ich mich bei neuen Kapazitäten sicher nicht für Delphi einsetzen. Außerdem wird uns aufgrund fortgeschrittenen Alters demnächst eine Menge geballtes Delphi-Fachwissen verlassen 😉 Also unsere Zukunft liegt sicher nicht in Delphi.



  • brotbernd schrieb:

    Mit welcher IDE und welchem Framework habt ihr da gearbeitet? Ist das zu empfehlen?

    Visual Studio mit irgendeinem (kostenpflichtigen) Plugin, AFAIR für das Syntax-Highlighting der Python-Dateien. Bei einem Projekt wurde PyQt, bei dem anderen wxPython - PyQt hat mir besser gefallen.

    Habt ihr Unit Tests geschrieben? Wenn ja, wie den C++ Code getestet? Per C++ UnitTests oder geht das auch gut über Python.

    Leider keine Tests.



  • sdfsdfd schrieb:

    Portier mal eine vergleichbare Anwendung von Windows auf Linux oder umgekehrt (in C++). Und vergleiche mal wie lange du dafür brauchst.

    das bestreite ich gar nicht. Eine zehntausend Zeilen lange config zur Erzeugung des Makefiles besagt mehr über Portabilität als zehntausend Worte. Zur Debatte stand aber die Portabilität zwischen verschiedenen python-Versionen auf der selben Plattform. Ein passenderer Vergleich wäre der Portierungsaufwand zwischen K&R-C und C99.



  • brotbernd schrieb:

    Außerdem wird uns aufgrund fortgeschrittenen Alters demnächst eine Menge geballtes Delphi-Fachwissen verlassen 😉 Also unsere Zukunft liegt sicher nicht in Delphi.

    Ich will auch nicht fuer Delphi Argumentieren - aber ich finde es komisch 2 neue Sprachen einzufuehren um Delphi zu ersetzen. Reicht nicht eine? Vielleicht mit einer Plattform wo man nicht sofort die Sprache wechseln muss sondern erstmal nur das neue Toolkit lernen kann.

    Ich persoenlich wuerde mich sehr unwohl fuehlen soviel neues in ein Team einzufuehren.


Anmelden zum Antworten