Programmierparadigmen, OOP-Verwirrung

[joost]

zurückgezogen

[kbrust]

Ja, da hast du in jedem Fall recht. Das Lemming-Phänomen tritt leider in sehr vielen Bereichen auf. Selbst ein Linux ist davon nicht sicher. Mein Bauchgefühl sagt mir aber, daß der Anteil bei einem Tool für Programmierer per Definition relativ gering sein sollte.

Das ist leider nicht so - ganz und gar nicht. Dafür gibt es viele Gründe. Für einen davon sieht man hier im Forum massenhaft Beispiele: Die Leute lesen einfach nicht (eine hoher Anteil der Fragen hier wäre durch einen Blick ins Tutorial oder die Referenz erledigt). Und da sie nicht lesen, nutzen sie oft nur einen kleinen Teil der Features der jeweiligen Software - von den anderen erfahren sie nie. Ich war mal Praktikant in einem größeren VB-Projekt (Hunderte von src-Dateien, Zeilenzahl irgendwo zwischen 30.000 und 100.000). Dort wurde nicht einmal der collection-Typ von VB eingesetzt, geschweige denn Klassen (die es auch in VB durchaus gibt). Und die Beurteilung des wenigen, was eingesetzt wird, hängt dann eventuell nur an irgendwelchen Kleinigkeiten, die auch in schlechter Software ja mal besser als woanders implementiert sein können.

Dass immer noch C und nicht durchgängig C++ programmiert wird (und C++ dadurch natürlich stark verbessert wäre), ist für mich auch ein Lemming-Effekt (OOP ist seit spätestens seit ungefähr 1995 ein Muss, und die großen C-Projekte wie gtk, tcl/TK u.s.w. bauen Objektorientierung in C nach) - und daran kann man sehen, wie sehr Programmierer dem unterliegen.

Hmmm. Wenn ich genauer darüber nachdenke, hast du auf jeden Fall recht, vorallem bei dem VB-Beispiel (Die Tatsache allein, das es noch so viele VB-Projekte in Bereichen gibt, wo die Sprache die denkbar schlechteste Wahl ist, unterstreicht das ganze sogar ).

Bei OOP wäre ich aber vorsichtiger, da hier ein grosser Teil darauf zurückzuführen ist, das es recht harter Tobak ist, falls man davor die imperative Programmierung verinnerlicht hatte. Der Umstieg kann da einige Probleme bereiten, sofern man nicht ein entsprechendes Talent in die Wiege gelegt bekommen hat.

[joost]

zurückgezogen

[joost]

zurückgezogen

[joost]

zurückgezogen

[birkenfeld]

*seufz* Man kann Posts auch editieren...

Fassen wir also zusammen: main() in eine Klasse packen zu müssen, ist für dich Unsinn. Deshalb magst du auch "if __name__ == '__main__'" nicht, weil das eben gerade nicht in einer Klasse steht? Kommt mir spanisch vor.

[gerold]

main() als Klasse ist daher ein Unding.

Hallo joost!

Auf was antwortest du hier? Wer verwendet schon ``main()`` als Klasse? ``main()`` soll eine Funktion sein, die aufgerufen wird, wenn das Modul nicht importiert, sondern direkt von der Kommandozeile aus aufgerufen wird.

Dass man dafür den Namen ``main`` verwendet, hat historische Gründe. C, C++, Visual Basic, ... Bei diesen Sprachen und vielen anderen ist eine Funktion/Methode mit dem Namen ``main`` der Einstiegspunkt.

Ich halte dieses Konstrukt für gar nicht mal so schlecht.

Code: Alles auswählen

def main():
    pass

if __name__ == "__main__":
    main()

Damit steuere ich das Verhalten des Moduls. Wenn es importiert wird, dann wird ``main()`` nicht ausgeführt. Wird das Modul direkt gestartet, dann wird ``main()`` ausgeführt.
Noch dazu hat man auch nach dem Importieren des Moduls immer noch die Wahl, vom importierenden Modul aus ``main()`` aufzurufen. Was unter Umständen ja auch nicht so schlecht sein muss.

mfg
Gerold


PS: Was hat das mit diesem Thema zu tun?

[gerold]

Der Code im pygtk-Tutorial z.B. läuft deshalb unter Windows gar nicht

Falls du diesen Code hier meinst: http://pygtk.org/pygtk2tutorial/ch-Gett ... HelloWorld

Der läuft bei mir ohne Probleme. Vom WingIDE aus aufgerufen, sowie direkt per Doppelklick gestartet.

Aber du hast recht, ``gtk.main()`` hat in der Klasse ``HelloWorld`` nichts zu suchen.

mfg
Gerold

[joost]

zurückgezogen

[birkenfeld]

Tut mir leid, aber ich habe keine Ahnung, was du eigentlich sagen willst.

[BlackJack]

@joost: OOP ist auf jeden Fall eine Abstraktionsebene höher als "normale" imperative Programmierung und damit auch etwas was man zusätzlich lernen muss und was vielleicht auch Probleme beim lernen macht, die man bis zu dem Punkt noch nicht hatte.

Ausserdem geht es nicht nur darum zu wissen was Klassen und Objekte sind, sondern man muss ein Programm damit auch sinnvoll entwerfen können. Mehr Möglichkeiten ein Programm zu strukturieren erfordern auch ein wenig mehr handwerkliches Geschick mit den zusätzlichen Werkzeugen umzugehen.

Das Argument mit den Klassenhierarchien kann man übrigens auch umkehren: Wer das "ordentlich" mit Java gelernt hat, braucht meistens eine kleine Eingewöhnungsphase bis er sich bei Python abgewöhnt hat alles in irgendwelche Hierarchien packen zu wollen, auch wenn das gar nicht notwendig ist.

Ansonsten schliesse ich mich birkenfeld an!?

[gerold]

(und es gibt sicherlich ein paar Module, die man so als Plugin brauchbar machen kann) - ich finde aber unsinnig, das durchgängig zu verwenden.

Hallo joost!

Sagen wir es mal so: Es gibt bei mir kaum ein Modul ohne diesen Konstrukt:

Code: Alles auswählen

def main():
    pass

if __name__ == "__main__":
    main()

``main()`` wird bei mir ziemlich oft zum Testen herangezogen. Ich bevorzuge es, kleine Teile funktionsfähig zu programmieren und in einem Hauptprogramm zu einem funktionsfähigen Ganzen zusammenzusetzen. Damit das so hinhaut, muss ich schon während dem Programmieren sicher stellen, dass die Einzelteile funktionieren. Diese Tests sind bei mir meistens in der ``main()``-Funktion zu finden.

Ich spreche bei meiner Art zu programmieren immer von "Legotechnik spielen". Mit dem Unterschied, dass ich mir meine Bauteile selber, in Form von Modulen, Klassen, Funktionen, wxPython-Frames, wxPython-Dialogen und sonstigen wxPython-Widgets herstelle. Ich liebe programmieren. Das ist wie den ganzen Tag mit Legotechnik zu spielen.

mfg
Gerold


PS: Jetzt habe ich es geschafft, in einem Offtopic-Thread Offtopic zu schreiben.

[joost]

zurückgezogen

[BlackJack]

Ich verstehe immer noch nicht worauf Du eigentlich hinaus willst. Also auf Python bezogen. Und vielleicht ziehst Du auch die Grenzen zu scharf bei Begriffen. Wo ist zum Beispiel der Unterschied zwischen Java, wo der Startcode in einer statischen Klasse steht und Python wo er in einem Modul steht, was man durchaus als statische Klasse oder Singleton ansehen und benutzen kann? Ich sehe da eigentlich nur syntaktische Unterschiede. Alles ist Objekt und irgendwo muss der Programmlauf nunmal anfangen.

Und wieso sollte es bei GUI-Programmen keine Klasse geben, die von einer "Application"-Klasse aus dem Toolkit abgeleitet ist und entsprechende Methoden und Funktionalität bereitstellt? Das es bei Klassen um Wiederverwendung geht heisst nicht, dass jede Klasse dazu gedacht sein muss wiederverwendet zu werden, es kann auch heissen, dass man bei einer nicht wiederverwendbaren Klasse, die sozusagen am Ende der "Nahrungskette" steht, etwas aus einer Basisklasse verwendet und diese erweitert. Eben um den Teil der diese *spezifische* Applikation ausmacht.

Edit: Ob man unbedingt Threads können muss? Also erstmal sehe ich noch nicht so ganz, dass jetzt alle Programme auf Threads umsteigen, weil Multicore-CPUs alleine nicht reichen ─ die Probleme müssen auch parallelisierbar sein. Und dann hoffe ich doch darauf, das sich einfachere und sichere APIs als Threads durchsetzen werden. Ich denke da an Actors/Coroutinen aus Io oder das Nebenläufigkeitsmodell von Erlang.

[joost]

zurückgezogen

[Leonidas]

Und ich wollte einmal bemerkt haben, dass das, was Java erzwingt und Leute in Python auch mit if __name__=='main' machen, kein sauberes OOP ist, und dass, wenn so etwas in Tutorials auftaucht, Anfängern der Zugang zu OOP wesentlich erschwert wird.

Quatsch.

Code: Alles auswählen

class MyStarter(object):
    def __init__(self):
        print "I'm starting"

if __name__ == '__main__':
    MyStarter()

Und wo wird da OOP erwschwert? Es wird nur nicht erzwunden, das ist alles. Aber ich habe das Gefühl, dass du nicht weißt, wozu ``if __name__ == '__main__'`` überhaupt ist.

PS: Stackless ist tot und niemand hat es je empfohlen. Es ist einfach eine Spezialversion von CPython ohne Stack, aber die damaligen Entwickler beschäftigen sich nun mit PyPy.

[BlackJack]

Sauberes OOP kann man nicht erzwingen weil das keine Spracheigenschaft sondern eine Denkweise, eine Art zu programmieren ist. Und ich verstehe *immer* noch nicht was Du immer mit dem ``if __name__ == '__main__':`` sagen willst!? Was ist daran unsauber? Warum sollte man diese Standardtechnik nicht in einem Tutorial zeigen? Mich stören im Gegenteil die Tutorials, die bis zum Ende immer Mmdulglobalen Code mitschleppen. Auf Modulebene gehört IMHO nur was beim Import zur Initialisierung des Modul-Objekts gehört. Wenn man das möglichst früh so einführt, merken die Leute zum Beispiel schnell, dass man Werte über die Argumente und Rückgabewerte von Funktionen austauschen muss und man sähe weniger Zugriffe auf Globales. Dieses Idiom fördert also saubere Programmierung sogar.

Alles ist Objekt ist eine Tatsache in Python. Das soll ein Grund für weniger Wiederverwendung von Code sein!? Dann sollte man wohl besser die Finger von Python lassen.

Hauptgründe gegen Wiederverwendung sind IMHO Linzenzmodelle, Bibliotheken die auf Wiederverwendbarkeit ausgelegt sind und damit so furchtbar generisch und komplex sind, dass sie niemand einsetzen möchte, der Drang etwas eigenes zu schaffen, und Sprachen wie Java, die generisches Programmieren erschweren. Keiner der Gründe ist speziell auf OOP beschränkt. Da wüsste ich nur: OOP als Allheilmittel ansehen. Es gibt einfach Sachen die sich funktional oder deklarativ wesentlich eleganter ausdrücken lassen.

[birkenfeld]

Und ich wollte einmal bemerkt haben, dass das, was Java erzwingt und Leute in Python auch mit if __name__=='main' machen, kein sauberes OOP ist, und dass, wenn so etwas in Tutorials auftaucht, Anfängern der Zugang zu OOP wesentlich erschwert wird.

So, und jetzt wird es wirklich lächerlich. Wo erzwingt Java ein Analogon zu "if __name__=='__main__'"? Und was ist daran *kein* OOP?

Und - alle Welt klagt darüber, dass auch unter Einsatz von OOP-Sprachen die Wiederverwendung von Code nicht zugenommen hat. Das kann nur an vermurksten Klassenhierarchien liegen und Sätzen wie (sorry, BlackJack):

Alles ist Objekt

.

Es ist nun mal so, ob es dir passt oder nicht, dass in Python alles ein Objekt ist.

[thelittlebug]

blub

ja?

mittlerweile ist mir in einigen threads aufgefallen das es joost scheinbar für unnötig hält die anderen wissen zu lassen was er von sich geben möchte.
joost, ich möchte dich in zukunft bitten, ich denke ich spreche für ein paar weitere user hier, ganze zusammenhängende posts zu liefern damit man wenigstens ansatzweise eine antwort geben kann. auch ist das absichtliche "verkomplizieren" mithilfe von scheinbaren "fachausdrücken" etwas was zumindest mir nicht wirklich hilft.

ich habe bis jetzt noch keinen post von dir entdeckt der nicht im nachhinein von kompetenten user entweder wiederlegt, verbessert oder um es in deiner sprache zu sagen, nullified wurde.

ich ziehe das jetzt ein wenig übertrieben auf, ich glaube auch nicht das du von allem keine ahnung hast, aber bitte lass uns zumindest ein wenig daran teilhaben

lg & nichts für ungut, herby

[mitsuhiko]

mittlerweile ist mir in einigen threads aufgefallen das es joost scheinbar für unnötig hält die anderen wissen zu lassen was er von sich geben möchte.
joost, ich möchte dich in zukunft bitten, ich denke ich spreche für ein paar weitere user hier, ganze zusammenhängende posts zu liefern damit man wenigstens ansatzweise eine antwort geben kann. auch ist das absichtliche "verkomplizieren" mithilfe von scheinbaren "fachausdrücken" etwas was zumindest mir nicht wirklich hilft.

Wow. das bringt es auf den Punkt. Da schließe ich mich gleich mal an