Open Source
Posts 21-29 of 29
- Back
- Next
-
Post visible to registered members
-
Enrico Weigelt(not a XING member)Re^11: Kein Interesse an Python im deutschsprachigen Raum?
Christian Heimes schrieb:
Ich empfehle dazu das Video von Sean Kelly:
http://www.archive.org/details/SeanKellyRecoveryfromAddictio... und
Das einzig interessante ist vielleicht das Überschreiben von Operatoren.
Gibts in C++ schon lange, und es gibt gute Gründe, daß man es in Java
nicht übernommen hat. Okay, Templates hat man später auch noch
nachgeliefert - da könnte man mit den Operatoren auch noch nachziehen.
Meist reichen ja die Grund-Ops wie Vergleich und Zuweisung voll und ganz
aus - die restlichen sind in ihrer Bedeutung ohnehin zu uneinheitlich für
eine generische Definition. Ehrlichgesagt hab ich das noch nie vermißt.
Ob ich nun foo.equals(bar) oder foo == bar schreibe, ist mir persönlich
relativ egal. Außerdem birgt die erste Notation nicht das häßliche Boxing-
Problem (und: nein, ich vermeide Boxing) und zweiterer mangelt es an
Eindeutigkeit, sobald es nicht innerhalb des gleichen Typs bleibt.
Von mir aus kann man sowas zumindest teilweise durch eine kleine
Spracherweiterung lösen, die sich nur im Compiler abspielt. Man braucht
nur einen neuen Operator einzuführen und den auf die equals()-Methode
abbilden. Problem gelöst, Runtime-Kompatibilität gewahrt, und man muß
keine extra neue Sprache erfinden.
vielleicht noch sein Screen Cast über Web Applications
http://oodt.jpl.nasa.gov/better-web-app.mov Beide zeigen sehr schön, welche Schwächen Java im Vergleich zu Python hat.
Ah, hier hats mal etwas mehr Stoff:
#1: "all changes require recompiling".
Ja, natürlich ! Wie will man denn sonst vor der Laufzeit sicherstellen,
ob der Code auch wirklich paßt ?!
Ich habe in all den Jahren schon so einiges größeres Projekt in
verschiedensten Script-Sprachen realisiert. Ab einer gewissen
Komplexität lernt man da einen strengen Compiler wirklich zu schätzen.
Der hilft nämlich ungemein, um ganze Klassen von Fehlern schon lange
lange vor der Laufzeit auszuschließen. Wer das wirklich nicht haben will,
der ist sicher mit Perl oder PHP gut bedient. Kein Grund, eine komplett
neue Sprache zu erfinden.
#2 "ui changes require recompile"
Hat nichts, rein garnichts mit der Sprache zu tun, sondern allein dem
GUI toolkit. Und genau dort ist das Problem schon lang gelöst.
Der Rest hat mit der Sprache an sich rein garnichts mehr zu tun.
Anwendungen wie Zope könnte man auch genauso gut in Java oder
Oberon programmieren.
Also gibt es irgentwelche entscheidenden Vorteile der Sprache
Python, zB. gegenüber der Sprache Java ?
Gruß
- 19 Sep 2007, 9:43 pm
-
Enrico Weigelt(not a XING member)Re^11: Kein Interesse an Python im deutschsprachigen Raum?
Achim Domma schrieb:
Dazu kommt, daß ich die Syntax als äußerst unübersichtlich empfinde.
also das Argument hab' ich im Kontext von Python noch nie gehört!? Wenn überhaupt, haben die meisten Leute ein Problem damit, daß sie so übersichtlich programmieren MÜSSEN!? Kannst du das genauer erklären?
Tja, Übersichtlichkeit ist wohl auch subjektiv. Oh, wie verwunderlich ;-O
Kontrollstrukturen von Whitespaces abhängig zu machen, finde ich schon
ein wenig absonderlich, und alles andere als übersichtlich. Sowas mag ich
mir von einer Sprache nicht aufzwingen lassen.
auch C# ein totaler Griff ins Klo - im Vergleich zu Java nix sinnvolles neues, aber bewährte Konzepte in den Müll geworfen.
Welche bewährten Konzepte hat C# denn in den Müll geworfen?
hmm, wie wär's zB. mit den checked exceptions ?
Oder 1class <-> 1file ?
Ach ja, dann das lustige Spiel mit dem Methoden-Überschreiben: in C#
sind die auf einmal wieder "non-virtual", wenn man sie nicht extra als
virtual deklariert - traditionell eine äußerst beliebte Fehlerquelle. Zu allem
überfluß muß man das Überschreiben auch nochmal extra angeben,
Schaut nicht Java gerade sowas wie Attribute von C# ab?
Welche denn ?
Dank C# machen nun auch compilierte Sprachen wieder Spaß.
D kann das viel besser.
Ok, an der Stelle gestehe ich, daß ich vorwiegend in der MS Welt arbeite, aber Java war für mich auch noch nie wirklich Open Source.
Die Sprache Java war schon immer offen. Es gibt dutzende kommerzielle
(non-open) Compiler und Runtimes, aber das hat mit der Sprache rein
garnichts zu tun.
Irgentwo in diesem Thread habe ich aufgeschnappt, daß es in Python statische
Prüfung von Exceptions gibt. Das wäre für mich schon ein entscheidendes Ausschlußkriterium - da kann ich auch gleich bei PHP bleiben.
Sorry, kannst du mir das genauer erklären? Wie bringst du da PHP ins Spiel? Wo ist das Problem mit den Exceptions in Python?
Wenn ich das richtig mitbekommen habe (korrigiert mich, wenn ich falsch liege!)
müssen (normale) Exceptions nicht immer - wie in Java - innerhalb einer Methode
explizit abgefangen oder mittels "throws"-Statement im prototype nach außen
gereicht und damit die Exception-Kette lückenlos sichergestellt werden (einzige
Außname sind RuntimeException's, die man aber aus gutem Grund tunlichst
vermeiden sollte). Solche checked exceptions verhindern wieder eine ganze
Klasse von Programmierfehlern.
Ich könnte dir jetzt einfache Beispiele liefern, aber dann würdest du behaupten, es wäre nur syntaktischer Zucker. Und wenn du reiner Javaprogrammierer bist, wirst du die abgefahrenen Sachen auf die Schnelle nicht verstehen - ganz ohne dir zu nahe treten zu wollen.
Ach, wie ich solches Geblubber liebe ...
Sieh's mal so: Ich hab 'mich mehrfach mit reinen Javaleuten an den Rechner gesetzt und spontan Python gezeigt. Quasi alle hatten den Mund danach weit offen stehen, weil sie Sachen gesehen haben, von denen sie nicht mal geahnt haben, daß man sowas machen kann.
Konkrete Beispiele ?
Gruß
- 19 Sep 2007, 10:15 pm
-
Post visible to registered members
-
Post visible to registered members
-
Enrico Weigelt(not a XING member)Re^13: Kein Interesse an Python im deutschsprachigen Raum?
Achim Domma schrieb:
in PHP: (brauch hier keine Einrückungen ;-P)
def methodA(param1,param2):
print "methodA",param1,param2
function methodA($param1,$param2)
{
print "methodA".$param1.$param2;
}
def methodB(param1,param2,param3):
__print "methodB",param1,param2,param3
function methodB($param1,$param2,$param3)
{
print "methodB".$param1.$param2.$param3;
}
mapping = {
__'A' : methodA,
__'B' : methodB
}
$mapping = array (
'A' => 'methodA',
'B' => 'methodB'
);
# z.B. Eingabe aus einem Textfile
method = 'A'
params = (1,2)
mapping[method](*params)
Was soll das ein ? Aufruf über den Namen bzw. über das mapping ?
Dann vielleicht:
$method = $mapping['A'];
$method($params[0],$params[1]);
Es gab auch eine Möglichkeit, die Parameterliste direkt aus einem Array
zu ziehen - habs aber nicht mehr im Kopf, weil ich solche Schlampereien
generell nicht mache.
def number_gen_gen(step):
__def number_gen(start,end):
____while start < end:
______yield start
______start += step
__return number_gen
Was ist das denn ? Verschachtelte Funktionen ?!
IMHO gehen solche Schweinereien in PHP nicht, und das ist gut so.
(in Pascal geht sowas, aber auch dort hab ich es schon immer gemieden).
stepsize3 = number_gen_gen(3)
stepsize5 = number_gen_gen(5)
for x in stepsize3(10,30):
__print x
Was genau soll das bewirken ?
print [4*x for x in stepsize5(10,100)]
???
class TraitA(object):
__def doit(self,value):
____return "TraitA:"+value
class TraitA
{
function doit($value)
{
return "TraitA".$value;
}
}
class TraitB(object):
__def execute(self,value):
____print self.Label,"TraitB:", self.doit(value)
class TraitB
{
function execute($value)
{
print $this->$Label."TraitB".$this->doit($value);
}
}
class C(TraitA,TraitB):
__Label = 'Label:'
Mehrfach-Ableitung ?! Pfui ! Sowas gibt nur Knatsch.
Hat sich schon in C++ nicht bewährt und wurde fast nur zum
Ausbügeln der Fehlenden Interface-Konstrukte benutzt.
Keine Ahnung, ob PHP sowas kann, weil ich nichts von solchen
Suizid-Experimenten halte.
c = C()
c.execute('hallo')
$c = new C();
Gruß
- 19 Sep 2007, 11:25 pm
-
Post visible to registered members
-
Enrico Weigelt(not a XING member)Re^15: Kein Interesse an Python im deutschsprachigen Raum?
Achim Domma schrieb:
Es gab auch eine Möglichkeit, die Parameterliste direkt aus einem Array
zu ziehen - habs aber nicht mehr im Kopf,
Ich halte fest: Die Pythonsyntax ist so intuitiv, daß man sie im Kopf behalten kann. Für mich ist das beim Programmieren ein wichtiges Kriterium.
Mag in diesem Fall so sein. Aber wie oft braucht man sowas in der Praxis ?
Bei mir persönlich ist das weniger als 1x im Jahr, und da ich gern bereit,
auch mal call_user_func_array() hinzuschreiben. Ganz nebenbei ist das
damit auch für einen Nicht-PHP-Experten völlig offentsichtlich was hier passiert,
ohne daß er erst raten muß.
weil ich solche Schlampereien generell nicht mache.
Und was "Schlamperei" ist, entscheidest du?
In meinem Projekten: selbstverständlich.
Nach gut 15 Jahren Softwareentwicklung maße ich mir das einfach mal an ;-P
Stell' dir vor, ich lese den Namen aus einem Configfile und die Parameter ebenfalls. Daß die verschiedenen Methoden unterschiedlich viele Parameter haben ist wohl eine sehr legitime Anforderung. Wir würdest du es lösen?
Zu allererst würde ich mir ganz genau überlegen, ob ich solche Situationen
nicht umgehen kann, denn Metaprogramming birgt immer genügend Fallstricke
(Wobei es natürlich bei den lasch-typisierten Scriptsprachen nicht mehr so
viel zu versauen gibt). Wenn es nicht anders geht, dann heißt die passende
Funktion: call_user_func_array().
def number_gen_gen(step):
__def number_gen(start,end):
____while start < end:
______yield start
______start += step
__return number_gen
Was ist das denn ? Verschachtelte Funktionen ?!
IMHO gehen solche Schweinereien in PHP nicht, und das ist gut so.
(in Pascal geht sowas, aber auch dort hab ich es schon immer gemieden).
Kommt darauf an, wie eingeschränkt dein Blinkwinkel ist. Man könnte es auch als Funktionsgenerator bezeichnen. Schon mal funktional programmiert? Oder bist du ein Zwangs-OOler?
FP ist ein völlig anderes Paradigmum. Wir reden ja hier nicht über Haskell
oder LISP, sondern über objekt-orientierte imperative Sprachen.
Meine Ausgangsthese war, daß Python keinen entscheidenden
funktioniellen Fortschritt gegenüber (damals) bereits existierenden
Sprachen wie zB. Java, Perl oder PHP bringt, der es lohnt, mal wieder
eine neue Sprache zu lernen, ein komplett neues Laufzeitsystem zu
warten (ja, es gibt auch sowas wie Produktivsysteme, die man auch
über viele viele Jahre hinweg am Laufen halten und aktualisieren muß),
das man nicht durch kleine Spracherweiterungen realisieren könnte.
Bei PHP hätte man zB. obigen Operator für die Array-Parameterübergabe
durch eine kleine Anpassung im Parser einführen können.
stepsize3 = number_gen_gen(3)
stepsize5 = number_gen_gen(5)
for x in stepsize3(10,30):
__print x
Was genau soll das bewirken ?
number_gen_gen(3) erzeugt eine neue Funktion, die zwei Parameter - start und end - erwartet und mit der Schrittweite 3 von start bist end iteriert. Übrigens ohne die Liste vorzuberechen, d.h. der Endwert kann beliebig groß sein, ohne daß eine temporäre Liste erzeugt wird. Kann ich das auch in PHP oder noch besser Java sehen?
Siehe oben. Paradigmenvermischung.
Wenn man sowas haben möchte, doch bitte gleich eine funktionale
Sprache benutzen.
Aber wenn wir schon OOP betreiben, warum dann nicht einfach
eine Counter-Klasse bauen, der das Iterable interface exportiert ?
print [4*x for x in stepsize5(10,100)]
Zähle von 10 bis 100 mit Schrittweite 5, multipliziere jeden Wert mit 4 und gib' die neue Liste aus.
Sowas hatte ich befürchtet.
Ist ja schön und gut, daß man hier ein paar Zeilen Code sparen kann,
aber wie siehts denn mit der Übersichtlichkeit aus ?
Möglichst viel und möglichst komplexe Semantik mit möglichst wenig Zeichen
auszudrücken mag ja bei Mathematikern beliebt sein - dort gönnt man ja
Symbolen generell nur ein Zeichen und braucht dann 10 Schriftarten und
dutzende Indices um überhaupt zurecht zu kommen - aber meiner gut 15
jährigen Programmiererfahrung nach, trägt solcher Zeichen-Geiz nicht gerade
zur Übersichtlichkeit und Wartbarkeit bei. Insofern find ich die Lösung von
Oberon recht praktisch, bestimmte Operatoren wie AND und OR als Wort
zu schreiben.
Mehrfach-Ableitung ?! Pfui ! Sowas gibt nur Knatsch. Hat sich schon in C++ nicht bewährt und wurde fast nur zum Ausbügeln der Fehlenden Interface-Konstrukte benutzt.
Schlechter Scherz! Aber du hast ja oben schon angemerkt, daß Features, die dein Sprachen nicht können, auch nicht relevant sind.
C++ kann es. Aber ich meide es konsequent. Nur leider braucht man es dort,
um Interfaces abzubilden. Java hat dafür glücklicherweise seine eigenen
Strukturen, sodaß dieser Mißbrauch aufhört.
Dir ist schon klar, daß Interfaces keine Implementierungen mitvererben können
Richtig, genau wie es sein soll.
und daß es Anwendungsfälle, bei denen das 100% Sinn macht? Der Klassenname TraitA kam ja nicht von ungefähr!?
Vielleicht mal ein echtes Praxisbeispiel, das den durchschlagenden Nutzen
von Mehrfachvererbung demonstriert ?
Denke wir beenden die Diskussion hier. Im Prinzip freu' ich mich ja über Entwickler, die nur Pseudo-OO können! ;-)
Ach wie kindisch.
Gruß
- 20 Sep 2007, 01:27 am
-
Enrico Weigelt(not a XING member)Re^13: Kein Interesse an Python im deutschsprachigen Raum?
@Jens: wer nicht zitiert werden will, dem will ich auch nicht antworten ;-P
- 20 Sep 2007, 01:28 am
