Python GUI, C++ Kern - Erfahrungen?
-
Hallo zusammen,
in unserem Unternehmen werden wir in näherer Zukunft einige neue Projekte starten. Gleichzeitig pflegen wir verschiedene Eigenentwicklungen, die teilweise ihren Urpsrung in den 80er auf einer VAX hatten und irgendwann auf Windows in Delphi portiert wurden. Seit ich im Unternehmen bin, sind auch noch ein paar C++ Schätzchen dazu gekommen (konsolenbasiert oder Qt Ui). Naja und unzählige chaotische VBA Tools, die irgendwie jeder Ingenieur für sich pflegt schwirren durchs Netz.
Wir entwickeln Simulations- und Auslegungssoftware, teilweise extrem performancekritisch (Laufzeit selbst aud GPUs Tage bis Wochen), zum Teil aber vom Rechenaufwand auch eher trivial. Platform ist eigentlich ausnahmslos Windows. Auch die Server, die wir haben sind glaube ich alles Windows Server. Darauf habe ich auch leider keinen Einfluss.
Für die kommenden Projekte und evtl. einer langsamen Portierung von alten Systemen suche ich nun eine möglichst einheitliche Technologie. Eines der großen Probleme sind wohl die vorhandenen Kenntnisse. Es sind hauptsächlich Delphikenntnisse vorhanden, zum Teil auch rudimentäre C# Grundlagen, C++ eigentlich nur bei mir. Nachdem ich mich jetzt ein knappes Jahr mit Delphi rumgequält habe, will ich dem Weg keine weitere Chance mehr geben.
Zunächst hatte ich eigentlich eindeutig an .Net gedacht. Sicher für alle halbwegs einfach zu erlernen und vor allem auch sinnvoll, wenn einige Anwendungen neben der Desktopvariante auch webbasiert angeboten werden sollen. Außerdem, wie ich dachte wohl sehr zukunftssicher (bis ich neulich las, dass MS die Zukunft von Windows Desktopanwendungen in HTML5+javascript sieht.. keine Ahnung was da nun dran ist).Naja kommen wir mal zum eigentlichen Sinn dieses Threads. Im Moment denke ich über die Alternative Python für die Benutzerschnittstelle und C++ für die Berechnung nach. Die Schnittstelle sollte mit boost python wohl recht komfortabel herzustellen sein. Leider habe ich damit überhaupt keine Erfahrung. Mit Python habe ich zwar schon sehr zufriedenstellend gearbeitet aber weder mit einem UI Framework noch mit boost python. Daher die Frage an Euch, wer damit arbeitet oder gearbeitet hat und welche Erfahrungen gemacht hat. Mit welchen Python GUI Frameworks habt ihr dabei gearbeitet und welches könnt ihr besonders empfehlen (ich würde mir wohl als erstes PyQt und wxPython ansehen). Wie sieht es vor allem mit boost python aus? Wie funktioniert das Deployment. Welche IDE, Build Tools/Server habt ihr eingesetzt?
Ich möchte keine Dikussion was die tollste Programmiersprache ist (das ist ja sowieso C++
), sondern wirklich nur Erfahrungen/Empfehlungen zu diesem Thema hören.
Grüße
brotbernd
-
Hallo,
ich kann Nichts sehr konkretes beisteuern, bin an dem Thema aber sehr interessiert, deshalb klink ich mich hier mal dezent ein.Habe bis jetzt lediglich mit Py/Tkinter gearbeitet für kleinere Sachen.
Das ist OK für kleine Prototypen, aber sehr beschränkt was die Widgets angeht. Mit Tix dazu geht mehr, aber davon ist die Dokumentation besch*eiden.Die Integration Python <=> C++ steht bei mir demnächst auch an.
-
Gute Kombi. Vorausgesetzt du brauchst wirklich C++.
In den meisten Fällen wird pures Python auch ausreichen.
mfg, pyfan
-
Wenn selbst mit der GPU die Berechnungen Tage bis Wochen dauern, ist Python wohl eher ungeeignet für so perfomancekritische Berechnungen.
-
bitmap.button schrieb:
Wenn selbst mit der GPU die Berechnungen Tage bis Wochen dauern, ist Python wohl eher ungeeignet für so perfomancekritische Berechnungen.
Ähnliches gilt für managed languages, d.h. .NET, C#, Java etc. dürften ausfallen. Nicht weil sie allgemein furchtbar unperformant wären, sondern weil weitgehend die Möglichkeiten fehlen, an den kritischen Stellen mit viel Fingerspitzengefühl noch ein wenig Performance rauszukitzeln.
-
Was stört dich denn an C++/Qt oder Delphi/VCL? Die Antwort darauf würde sicher dabei helfen, vernünftige Vorschläge zu bringen.
-
CPPD schrieb:
Was stört dich denn an C++/Qt oder Delphi/VCL? Die Antwort darauf würde sicher dabei helfen, vernünftige Vorschläge zu bringen.
- Unnötiger Arbeitsaufwand
- Unnötige Fehleranfälligkeit
- Zeit = Geld
- Beschissen zu warten
- Veraltet
-
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.
-
Ich würde hier GUI und Simulation grundsätzlich getrennt betrachten. Für die Simulation ist, bei einem derart massiven Rechenleistungbedarf, wohl eher Parallelisierung auf mehrere CPU und GPU-Cores ein Thema. Da fährst du mit C/C++ ,ggf. auch Assembler, ganz gut.
Für die GUI-Entwicklung kann ich Qt nur empfehlen. Bei uns in der Firma hat sich das seit Jahren absolut bewährt.
Python sehe ich eher als RAD-Tool, für kleine Projekte oder Scripting-Möglichkeit für eine Applikation.
-
!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 verlassenAlso unsere Zukunft liegt sicher nicht in Delphi.