IM IN YR LOOP\n VISIBLE FOO\n IM OUTTA YR LOOP - Der Programmierer-Spamthread #2

[DFYX]

Welches komplexere (Enterprise) CMS zickt nicht rum, wenn man nicht das notwendige Know-How zu dessen Konfiguration und Einrichtung mitbringt?

...

Auch von einem Enterprise CMS erwarte ich, dass es funktioniert, wenn man einen Eintrag kopiert und einen Dateipfad anpasst. Davon abgesehen war einer von uns dreien der Admin der Firma und arbeitet schon seit längerem mit Typo 3. Trotzdem ist er 5 Stunden lang dran verzweifelt, weil einiges nicht so funktioniert hat, wie es (auch laut Doku) sollte.

[MagicMagor]

Vielleicht eignet sich für die Frage auch ein eigener Thread, aber ich stelle sie dennoch mal hier.
Ich überlege, in meinem üblichen programmiertechnischen Größenwahn, so etwas wie einen Game Maker zu schreiben - zumindest aber wohl eine Spielengine + Editor.
Die Frage die sich mir stellt, ist die nach der Sprache, bzw ob es zwischen den beiden Alternativen gravierende Performance-Unterschiede oder sonstige Argumente gibt.

Java
Java hat den Vorteil, das ich in der Uni sowieso einige Zeit damit gearbeitet habe und die Sprache mittlerweile recht lieb gewonnen habe. Plattformunabhänig wäre die Sache sowieso und es gäbe keinerlei Probleme mit Bibliotheken beim Ausliefern des fertigen Programms.
In dem kleinen Testprogramm das ich habe, arbeite ich mit einem Graphics2D-Objekt auf einem JPanel als Zeichenfläche (entnommen aus einem Tutorial für Java-Game Programmierung).
Hier würde ich momentan am ehesten zu tendieren, sofern es nicht extreme Performanceprobleme gibt.

Python+Pygame
Das wäre die zweite Alternative. Der Nachteil wäre hier, daß ich eine extra GUI-Bibliothek für den Editor nehmen müsste, was wieder eventuelle Probleme bei der Auslieferung macht. (Irgendwie ist meine Erfahrung mit externen Bibliotheken zu 80% das es irgendwie rumzickt)
Da Python auch interpretiert ist, bin ich mir nicht 100%ig sicher ob es zu Java so einen riesigen Performance-Vorteil hätte.

[DFYX]

Für alle, die der theoretischen Informatik zugeneigt sind: die gefühlt undertste Auflage von "Ich beweise, dass P != NP. Herausgegeben vorgestern. Hatte bis jetzt noch keine Zeit, mit das komplett durchzulesen, aber ich nehme an, dass sich irgendwo auf den 66 Seiten ein Fehler finden wird.

[Tabris]

Naja, die meisten "Beweise" waren ja für P = NP. Der Beweis scheint übrigens (zumindest in der aktuellen Version) fehlerhaft zu sein. Wer mehr erfahren will, dem empfehle ich Richard Liptons hervorragenden Blog: http://rjlipton.wordpress.com/.

[Kyuu]

MagicMagor: Python ist definitiv keine schlechte Wahl. Ich kenne einige, die mit Python + Pygame gute Erfahrungen gesammelt haben. Mit Pygame fährst du in Sachen Spieleprogrammierung sowieso gut, da die Bibliothek genau dafür entwickelt wurde und dementsprechend alles bietet, was du brauchen wirst. Für das GUI würde ich dann Qt nehmen, bzw. PythonQt. Qt ist sehr ausgereift, wird professionell weiterentwickelt und ist für zahlreiche Plattformen verfügbar. Ich glaube nicht, dass du mit Qt irgendwelche Schwierigkeiten bei der Auslieferung der Binaries haben wirst.

Bezüglich des Performanceunterschieds, da müsste eigentlich Python den kürzeren ziehen, da Java dynamisch in Maschinencode übersetzt wird. Allerdings gibt es den JIT-Compiler Psyco für Python, nur für den Fall, dass zusätzliche Performance benötigt wird.

[Lukas]

Aus Interesse: Was spricht für PythonQt gegenüber PyQt (bzw. PySide, was die selbe API wie PyQt implementiert und vom Qt-Hersteller kommt)? Davon hör ich nämlich zum ersten Mal, und die anderen haben eine gewisse Verbreitung …

Und Psyco ist de facto tot und macht wohl auch hauptsächlich number crunching schneller, da würd ich mich nicht drauf verlassen.

[Kyuu]

In erster Linie natürlich nichts, außer vielleicht im Vergleich zu PyQt, das keine LGPL-Lizenz anbietet, oder im Vergleich zu PySide, das laut der offiziellen Website noch keinen Windowsport besitzt.

Ehrlich gesagt habe ich mit keinem der Kandidaten Erfahrungen gesammelt und meine Python-Zeiten sind schon etwas länger her, so dass ich nicht mehr auf dem aktuellen Stand bin. Aus diesem Grund zitiere ich hier lieber die, die sich mehr auskennen:

Unlike PyQt and Qt Jambi, PythonQt is not designed to provide support for developers writing standalone applications. Instead, it provides facilities to embed a Python interpreter and focuses on making it easy to expose parts of the application to Python.

PythonQt makes extensive use of the Qt 4 meta-object system. Thus, PythonQt can dynamically script any QObject without any prior knowledge of it, using only the information supplied by QMetaObject (defined using Qt's moc tool in C++ applications). This dynamic approach allows several different script bindings to be embedded in the same application, each of which can use the same scripting API; e.g., JavaScript (QSA or QtScript) and Python.

...

Comparison with PyQt/PySide

PythonQt is not as pythonic as PyQt in many details (e.g. buffer protocol, pickling, translation support, ...) and it is mainly thought for embedding and intercommunication between Qt/Cpp and Python
PythonQt allows to communicate in both directions, e.g., calling a Python object from C++ AND calling a C++ method from Python, while PyQt only handles the Python->C++ direction
PythonQt offers properties as Python attributes, while PyQt offers them as setter/getter methods (e.g. QWidget.width is a property in PythonQt and a method in PyQt)
PythonQt currently does not support instanceof checks for Qt classes, except for the exact match and derived Python classes
QObject.emit to emit Qt signals from Python is not yet implemented but PythonQt allows to just emit a signal by calling it like a normal slot
PythonQt does not (yet) offer to add new signals to Python/C++ objects and it does not yet support the newstyle PyQt signals (so you need to connect via C++ string signatures)
Ownership of objects is a bit different in PythonQt, currently Python classes derived from a C++ class need to be manually referenced in Python to not get deleted too early (this will be fixed in a future version)
QStrings are always converted to unicode Python objects, QByteArray always stays a QByteArray and can be converted using str()
There are many details in the generated wrappers that could need some polishing, e.g., methods that use pointer arguments for additional return values could return a results tuple.
Not all types of QList/QVector/QHash templates are supported, some Qt methods use those as arguments/return values (but you can add your own handlers to handle them if you need them).
Probably there are lots of details that differ, I do not know PyQt that well to list them all.
In the long run, PythonQt will consider using/extending PySide with the features of PythonQt to get rid of its own generator and typesystem files, alternatively the KDE Smoke generator might be used in the future (this has not yet been decided, the current PythonQt generator works well and there is no hurry to switch).

...

BTW: So viel attraktiver wird PySide dadurch, dass es von einem Nokia-Tochterunternehmen entwickelt wird auch nicht. Zumindest macht MeVis ebenfalls was her.


Was Psyco angeht, kann es auf der einen Seite natürlich ein Problem darstellen, dass es nicht mehr weiterentwickelt wird, muss auf der anderen Seite aber nicht. Wie gesagt, wenn mehr Performance benötigt wird, kann man damit experimentieren.

Je nach Situation, kann eine Verbesserung der Rechenleistung durchaus etwas bringen, besonders in Spielen.

Außer Psyco kenne ich noch Unladen Swallow, aber das ist scheinbar 2009 auch ins Stocken geraten.

In jedem Fall ist es immernoch möglich performancekritischen Code nach C/C++ auszulagern. Das ist eigentlich auch eine bewährte Vorgehensweise.

[MagicMagor]

Ich bin mal so frei und nutze diesen Thread um meinen momentanen Ärger etwas Luft zu machen.

Ich sitze gerade an den Vorbereitungen für meine Bachelor-Arbeit, in der ich einen Orc Interpreter in Prolog schreiben muss.
Um mir die Arbeit des Parsings zu ersparen will ich den offiziellen Orc-Parser nutzen (in Java geschrieben, unter BSD-Lizenz verfügbar) und mit dem AST dieses Parsers weiterarbeiten.

Augenscheinlich schien bei der Entwicklung von Orc aber niemand daran gedacht zu haben, dass ein Aussenstehender jemals auf die Idee kommen könnte mit dem AST zu arbeiten.
Das fängt damit an, das es keine wirkliche Dokumentation gibt. Es gibt zwar eine Dokumentation per Javadoc, aber geschätzte 90-95% aller Klassen sind unkommentiert.
Der Versuch über die Namen der Klassen und Felder ein wenig die Bedeutung zu erfahren klappt an manchen Stellen ganz gut (Left, Right, body etc..) an anderen Stellen dafür weniger.
Was eine ConsExpr ist kann ich noch erahnen (Constant Expression?) was sich hinter den Kinderknoten "t" und "h" verrbirgt ist mir dagegen schleierhaft.

Bleibt mir nur, simple Testprogramme zu parsen und mir den resultierenden AST anzugucken. Glücklicherweise bietet der Orc-Quellcode direkt eine Funktion um den AST als XML-Datei abzulegen. Aber wirklich verständlich wird es dadurch auch nicht...
Folgendes Orc-Programm

Code:

2 + 5

Erzeugt einen AST, dessen XML-Datei zuviele Zeichen enthält, als das ich ihn hier posten könnte. Ungeachtet des Overheads der durch XML dazu kommt...
381.808 Zeichen in 1114 Zeilen sind ein wenig viel um den AST zu verstehen...

Ich glaub, bevor ich den AST verstehe krieg ich davon Alpträume.. Irgendwie hätte ich von Code, der immerhin an einer Universität entwickelt wird, ein wenig mehr Dokumentation erwartet...

[Kyuu]

Code (C++):

 
for (unsigned int i = foo.Length()-1; i >= 0; --i) //...
 

Wer findet den Bug? (Wahrscheinlich alle, ich bin nur etwas verblüfft sowas subtiles zu sehen.)

[Jesus_666]

Im Falle von foo.Length() == 0 wird die Schleife 2³²-, bzw. 2⁶⁴mal zu oft durchlaufen?

[Kyuu]

Ne, die Schleife wird nie beendet.

[DFYX]

Ah, ja, jetzt seh ichs. Ein >= 0 auf einem unsigned int... Wahnsinn.

[Mivey]

Ne, die Schleife wird nie beendet.

...

Weil sobald i 0 ist, es um eins reduziert wird, dadurch dann sofort den größtmöglichen Wert annimmt?

[Whiz-zarD]

Jop.

[DFYX]

Spaß mit verschachtelten Templates!

Code (C++):

std::map<size_t, std::map<std::string, std::pair<PropertyType, ParameterDefinitionList> > > m_mActions;

führt zu

Code:

1>c:\program files (x86)\microsoft visual studio 9.0\vc\include\xlocnum(135) : warning C4503: 'std::_Tree<_Traits>::_Buynode': Die Länge des ergänzten Namens wurde überschritten. Der Name wurde gekürzt.
1>        with
1>        [
1>            _Traits=std::_Tmap_traits<size_t,std::map<std::string,std::pair<DeviceManager::PropertyType,DeviceManager::ParameterDefinitionList>>,std::less<size_t>,std::allocator<std::pair<const size_t,std::map<std::string,std::pair<DeviceManager::PropertyType,DeviceManager::ParameterDefinitionList>>>>,false>
1>        ]

Mit komplett aufgelösten typedefs wäre es übrigens:

Code (C++):

std::map<size_t, std::map<std::string, std::pair<enum PropertyType, std::map<std::string, enum PropertyType> > > > m_mActions;

Ich könnte die Warnung umgehen, indem ich noch mehr Typedefs verwend, aber dazu bin ich ehrlich gesagt zu faul.

[nudelsalat]

Sleepsort: http://beust.com/weblog/2011/06/15/sleep-sort/

[FF]

Hat jemand zufällig eine Google+ oder wie das heißt einladung? Würde das gerne mal ausprobieren.

[drunken monkey]

Sleepsort: http://beust.com/weblog/2011/06/15/sleep-sort/

...

Quantum bogosort! \o/

Wikipedia: An in-joke among some computer scientists is that quantum computing could be used to effectively implement a bogosort with a time complexity of O(n). It uses true quantum randomness to randomly permute the list. The list is then inspected, and if it is not in order, the universe is destroyed.

...

Aber Sleepsort ist auch Spitze! Kannte ich allerdings schon …

[Mog]

Hat jemand zufällig eine Google+ oder wie das heißt einladung? Würde das gerne mal ausprobieren.

...

Bin in der Beta. Einladungen gibt es allerdings derweil keine mehr.

[DFYX]

Hab ich mal erwähnt, dass der Qt Creator als IDE wahnsinnig unhandlich ist? Deren Debuggerfrontend ist scheiße und gelegentlich verschwindet der Cursor einfach so. Dummerweise wird für ein Praktukum erwartet, dass wir damit arbeiten.