Z.b. gibt es Objekte, die sich mit anderen Objekten praktisch gar keine Gemeinsamkeiten teilen (z.b. primitive Datentypen oder die null-Referenz). Der Programmierer kann die gar nicht wie Objekte behandeln.
Ich seh primitive Datentypen als ein nettes Angebot, das man ja nicht zwangsweise wahrnehmen muss. Bei vielen Problemen ists ganz nett, wenn man mit sowas hantiert, z.B. wenn man dann ein Array von solchen ints in den Grafikspeicher schreiben will. Objekte reinschreiben ist keine gute Idee. Und von jedem Objekt da mit einem Methodenaufruf die Zahl rausholen und ins Array legen, kann recht lahm werden.
Ist natürlich immer eine Frage, wie weit man mit der Objektorientierung geht. Wenn ich ein Text-Edit-Feld hab, kann ich auch jedes Zeichen kapseln, z.B. mit Flyweight, ob ich das auch wirklich mach, grad wenns dann mit Unicode doch recht viele Zeichen gibt, ist die Frage.
Z.b. die Kapselung von Verantwortung: Sagen wir Du willst den Absolutwert der Zahl -5. Eigentlich solltest Du jetzt -5, einer Instanz von einer Klasse Zahl, eine Nachricht schicken und sie nach ihrem Absolutwert fragen. Stattdessen holst Du dir von irgendwo eine Funktionssammlung System.Math und uebergibst der dann ein "Ding" namens -5 als Parameter.
Stimmt. Dass es dadurch für Anfänger schwieriger wird, bezweifel ich aber. Es besteht höchstens die Gefahr, dass er es für ein Naturgesetz hält, das so zu handhaben, und gar nicht auf die Idee kommt, dass es anders sein könnte.
Und wenn shuffle nicht existiert, dann tut man es halt da hinein. In C# geht das aber nur dann, wenn Du den Code der Collection zur Verfügung hast. In C# 3.0 gibt es die Möglichkeit, die Methode dahin zu stecken wo sie gehoert. Aber auch in C# 3.0 ist das wieder ein spezielles, stark eingeschraenktes Konstrukt. Ein komplizierter Sonderfall für etwas, was eigentlich ganz einfach sein sollte.
Ich seh kein großes Problem, eine neue Liste von der alten abzuleiten, und das Shuffle einzufügen. Dann verwend ich halt ab dem Zeitpunkt die neue Liste. Dass ich mir letztens die kleine Zehe anghaut hab, hat mich mehr gestört.
Ja, da geb ich dir auch 100% recht. Ich weiß aber nicht, ob du solche Erfolgserlebnisse durch eine IDE wirklich schneller bekommst, als mit einer möglichst einfachen, abstrakten Programmiersprache und (nach den ersten Schritten) guten Bibliotheken.
Sei mir net bös, aber wenn ein Anfänger fragt "Wie mach ich denn da jetzt ein Fenster und ein paar bunte Bilder drin", kommt der geek und zählt ihm die verschiedenen graphischen Toolkits mit ihren Vor- und Nachteilen auf, und der arme hat keine Ahnung, was er da machen soll. Bei der IDE nimmt er das, was ihm angeboten wird, und das ist meistens auch gut integriert, sodass er da schnell was hinbekommt, ohne für jeden mickrigen Button 5 Codezeilen zu schreiben, und dann nix zu sehen, weil er dem Layoutmanager was nicht richtig eingestellt hat.
Und was die Python-Einrückungen angeht: Es gibt halt öfters Funktionen, nach denen viele Leute einrücken, wie z.B. glBegin und glEnd. Das sind aber stinknormale Funktionen aus der Sicht der Programmiersprache. Ich möcht da nicht meine Sprache durcheinanderbringen. Ich find Python ansonsten auch ganz nett, und hab auch einige kleinere Sachen damit geschrieben. Aber halt nix buntes, das wär mir zu nervig.