mal grundsaetzlich: python vs. php...etc

[Leonidas]

Dier fand ich ganz nett zum Verstehen von LCs: http://www.secnetix.de/~olli/Python/lis ... sions.hawk

[CM]

Hi

tolle Diskussion (die im Ruby-Forum ist auch nicht schlecht) . Bei meinem ersten Antwortversuch zur eigentlichen Frage ist bei uns leider das Netz zusammengebrochen , aber die Diskussion hat sich ja doll entwickelt.

Ich verstehe bloß den Trubel um Pythons spezielle Klassenmethoden (à la __len__ ) nicht: __len__ zu definieren ist doch u. U. semantisch notwendig in einer Klasse. Das dürfte doch allen klar sein (scheint ja auch allen klar zu sein). Wo ist denn das Problem, wenn man zum Aufruf mehrere Optionen hat? Vermisst jemand syntaktische Eindeutigkeit? Warum? Klärt mich doch bitte mal auf.

Im Übrigen habe ich - durch diese Diskussion angeregt - entdeckt, daß auf meiner Obstkiste Ruby schon vorinstalliert war. Kurzes Reinschnuppern war sehr interessant, aber mir geht es wie Dir, murphy, ich bleibe lieber, bei dem was ich kenne und schätze.

Gruß und schönes Wochenende,
Christian

[Malte aus dem Ruby-Forum]

__len__ zu definieren ist doch u. U. semantisch notwendig in einer Klasse. Das dürfte doch allen klar sein (scheint ja auch allen klar zu sein). Wo ist denn das Problem, wenn man zum Aufruf mehrere Optionen hat? Vermisst jemand syntaktische Eindeutigkeit?

Da ich Python kaum kenne, kann ich hier natürlich schlecht mitreden, trotzdem versuch ich es mal. Wenn ich in Python programmieren müsste und len(str) statt str.length schreiben müsste, wäre das erste Gegenargument natürlich, dass es nicht so wie in Ruby ist . An zweiter Stelle geht es hier um das "OO-feeling" (gibt es so was?), da der Ruby-Code mir zeigt, das length eine Methode von String ist, während der Python-Code vor mit versteckt, dass __len__ eine Methode von String ist.

Grüße

[mawe]

Hi!

Ruby ist ja u.a. mit dem Ziel entwickelt worden, "objektorientierter" zu sein als Python. Das zeigt sich auch in der Syntax. Welche man bevorzugt, ist meiner Meinung nach Geschmackssache. Es würde mich nicht wirklich stören, wenn man in Python auch "hello".length() schreiben könnte, es ärgert mich allerdings auch nicht sonderlich daß man es nicht tut . (Um ehlich zu sein hab ich mich noch nicht dafür interessiert, wie Python z.B. len intern behandelt).
Es gibt allerdings etwas, das mich bei Python nervt: join

Code: Alles auswählen

x = "h.e.l.l.o".split(".")   # -> ['h','e','l','l','o']
".".join(x)   # warum nicht x.join(".")

Gibt's da eine Erklärung?

Gruß, mawe

[Milan]

HI. Ja mawe, die gibts: ich fänd es nämlich sehr dumm, wenn eine Liste eine Methode beherrschen würde, bei der ein String rauskommt, also eigentlich eine Stringoperation. Da seh ich das schon sinnvoller so zu schreiben: verbinde mit "." die Liste x. Da join eine Methode von str ist, weiß ich auch, dass ein str rauskommt .

[mawe]

Hi!

... ich fänd es nämlich sehr dumm, wenn eine Liste eine Methode beherrschen würde, bei der ein String rauskommt ...

Versteh' ich nicht. split ist ja auch ein Stringmethode und es entsteht eine Liste. Ist es dadurch eine Listenmethode?

... verbinde mit "." die Liste x ...

Ich fände es so einleuchtender: Verbinde die Elemente der Liste x mit einem "." Sieht so aus als wäre das wieder mal Geschmackssache

Gruß, mawe

[Milan]

Versteh' ich nicht. split ist ja auch ein Stringmethode und es entsteht eine Liste. Ist es dadurch eine Listenmethode?

Hi. Gutes Argument... dann lags halt an der Faulheit der Programmierer, die den Kompromiss in Kauf nehmen um nicht mehr schreiben zu müssen, bzw einfach am praktischem Nutzen. Denn dann hätte man join für alle iterables definieren müssen und das wäre dumm gewesen wenn du mal selber eine solchen schreibst, oder einfach nur Generatorfunktionen durchlaufen lässt. Es würde sich auch negativ auf die Performance auswirken .

[Leonidas]

Ich seh das len() Problem auch nicht wirklich, wenn man jetzt unbedingt so OO wie möglich programmieren will, dann kann man ruhig auch __len__() aufrufen. Wenn man es noch weiter treiben will kann man auch die Operatoren auslassen und direkt mit __mul__ und co arbeiten.

[oenone]

du kannst join() ja nicht nur auf Listen, sondern auch auf Tupel, Dictionaries und allen anderen sequenzierbaren objekten benutzen, sofern sie strings zurueckliefern.

auf bald
oenone

[murphy]

Mittlerweile nehme ich nur noch LC. Findest Du die nicht auch ... wie soll ich sagen ... intuitiver

ich kenne sie von Haskell. aber anstatt for und if eine zweite bedeutung zu geben, hat man in Ruby eben ein allgemeineres konzept benutzt.
in codeblöcke kann man auch mal größere mengen code hineinschreiben.

Code: Alles auswählen

if x not in noprimes

ist natürlich eine schöne fomulierung, die in Ruby zugunsten der OO nicht vorhanden ist. da wäre es

Code: Alles auswählen

not noprimes.include?(x)

die list comprehensions gibt es wohl auch nicht, weil es ein neues konzept für etwas wäre, was man auch mit codeblöcken lösen kann.
es gibt dinge, die man mit LC nicht lösen kann, aber offenbar auch andere, die sich damit nur schwer lösen lassen:

Code: Alles auswählen

#noprimes = [j for i in range(2, 8) for j in range(i*2, 50, i)]
noprimes = []
(2..8).each { |i| (i*2..50).step(i) { |x| noprimes << x } }

ich habe mal ein wenig herumexperimentiert, und ein simples LC-interface für Ruby geschrieben:

Code: Alles auswählen

class LC
	attr :values
	def initialize
		@values = []
	end
	
	def add x
		@values << x if x
	end
	alias :add= add
end

def list &block
	lc = LC.new
	lc.instance_eval &block
	lc.values
end

#noprimes = [j for i in range(2, 8) for j in range(i*2, 50, i)]
noprimes = list { (2..8).each { |i| (i*2..50).step(i) { |j| add j } } }
p noprimes.uniq.sort
p (2..50).to_a - noprimes

es ist ein wenig länger als die PYthon-variante, aber brauchbar. das ärgerliche sind natürlich die vielen { klammern }.
könnte jemand bitte codeblöcke in Python simulieren

[mawe]

Hi!

es ist ein wenig länger als die PYthon-variante, aber brauchbar

Überhaupt nicht! Ich meine, ja, es ist länger, aber ausserdem auch fürchterlich unlesbar . Das ist ja meiner Meinung nach das Schöne an den LC im Python: die Einfachheit und Lesbarkeit.

könnte jemand bitte codeblöcke in Python simulieren

Wozu? Um auch so hässliche Konstrukte zu fabrizieren? (kleiner Scherz)

Gruß, mawe

[Milan]

Hi. Dein Code gibt bei mir das hier aus:

Code: Alles auswählen

[milanx@sc8-pr-shell1 milanx]$ ruby
noprimes = []
(2..8).each { |i| (i*2..50).step(i) { |x| noprimes << x } }
-:2: undefined method `step' for #<Range:0x401407fc> (NameError)
        from -:2:in `each'
        from -:2

Solangsam wirds Offtopic (hat nix mehr mit Allgemeinen Fragen zu tun), oder? Ich überlege ob ich die Diskussion splitte und den jetzigen Teil nach Offtopic verschiebe. Dort können wir dann beliebig weiterdieskutieren...

Statt Codeblöcken nimmt man hier for-Schleifen in Kombination mit LC/besser GE, denn nix anderes sind sie in meinen Augen (bloß einzeilig)

[mawe]

Hi Milan!

Bei mir funktionierts. Wenn Du interaktiv mit Ruby arbeiten willst, verwende irb (statt wie Du ruby).
Verschieben find ich gut, aber vielleicht gleich den ganzen Thread (war ja von Anfang an eine "welche Programmiersprache" Frage).

Gruß, mawe

[Leonidas]

Bei mir funktionierts. Wenn Du interaktiv mit Ruby arbeiten willst, verwende irb (statt wie Du ruby).

Bei ruby müsste man halt ein EOF anhängen.

Verschieben find ich gut, aber vielleicht gleich den ganzen Thread (war ja von Anfang an eine "welche Programmiersprache" Frage).

Und das Topic müsste man auch gleich noch ändern, das PHP Mist ist haben wir alle schon auf der ersten Seite festgestellt.

[murphy]

Überhaupt nicht! Ich meine, ja, es ist länger, aber ausserdem auch fürchterlich unlesbar . Das ist ja meiner Meinung nach das Schöne an den LC im Python: die Einfachheit und Lesbarkeit.

es stimmt, dass die LC mit keywords statt klammern viel simpler aussieht. und meist braucht man wohl auch nur for und if.

codeblöcke können mehr (eigentlich alles was als callback darstellbar ist - for ist da nur ein spezialfall. stellt euch vor, ihr könntet methoden definieren, die ihr dann wie if und for verwenden könnt!)
und es gibt diese "Domino-optik":

Code: Alles auswählen

noprimes = [j for i in range(2, 8) for j in range(i*2, 50, i)]

schau mal wie weit auseinander i und j jeweils stehen. die reihenfolge bzw. die verbindung der for's ist gar nicht erkennbar, einerseits arbeitet die LC von rechts nach links (rechts erzeugen, links berechnen) und dann wieder von links nach rechts (erst for i dann for j.)
mein workaround ist zwar hässlich, aber deutlicher:

Code: Alles auswählen

noprimes = list { (2..8).each { |i| (i*2..50).step(i) { |j| add j } } }

i zu i, j zu j (wie beim Domino.) nur eine richtung. klare klammerung.
trotzdem wäre es schön, LC in Ruby zu haben. aber so etwas wie in Python ist schwer vereinbar mit den bisherigen regeln. es müsste tatsächlich ein ganz neues konstrukt her.

Hi. Dein Code gibt bei mir das hier aus:

Code: Alles auswählen

-:2: undefined method `step' for #<Range:0x401407fc> (NameError)

du hast ein altes Ruby. früher hätte man i*2.step(50, i) schreiben müssen. ich mag Range#step lieber.

[CM]

Wenn man es noch weiter treiben will kann man auch die Operatoren auslassen und direkt mit __mul__ und co arbeiten.

LOL!

Aber ich habe schon etwas über Maltes Kommentar nachdenken müssen. Mir persönlich liegt die Pythonvariante mehr, aber letztlich kann ich verschiedene Argumente hier nicht ganz nachvollziehen: Kann es sein, daß sich der größte Teil der Diskussion nur um syntactic sugar (wie heißt das auf Deutsch?) dreht? (siehe syntactic sugar) Klar, den braucht es, sonst macht Programmieren keinen Spaß. Und ich selber habe ja im zweiten Satz hier genauso argumentiert. Aber das macht ja eine Sprache nicht besser oder schlechter als eine andere. Argumente wie fehlende LCs oder GEs stechen da schon besser . Diesen Absatz wollte ich mal in die Runde werfen, als kleinen Dämpfer .

Was aber nicht zuletzt die Wahl für eine Sprache bestimmt ist die Dokumentation, Verfügbarkeit von Libraries und Support. Ich habe mich am Wochenende etwas in Ruby eingelesen (hätte eigentlich an was Anderem arbeiten müssen ) und denke, Ruby liegt diesbezüglich vielleicht noch ein wenig hinter Python zurück - aber sehr groß ist dieser Unterschied nicht (mehr). Das ist mein erster Eindruck: Wie seht ihr das?

Gruß,
Christian

[mawe]

Hi!

syntactic sugar (wie heißt das auf Deutsch?)

Syntax-Zucker?
Es kommt mir (eben durch die Syntax) manchmal so vor, als wäre Ruby von Grund auf etwas besser durchdacht, jedenfalls logischer (ist ja auch leicht, die Sprache ist ja jünger ). Bei Python kommen dann eben Fragen wie "warum len(x) und nicht x.len()". (Ich muß nochmals zugeben, daß ich mich mit der internen Struktur von Python noch nicht wirklich befasst habe). Aber das ist, wie Du gesagt hast, für mich kein Entscheidungskriterium.

Das mit der Doku sehe ich etwas radikaler (:D): hier hinkt Ruby meilenweit hinterher. Naja, es gibt schon einiges, aber hauptsächlich auf japanisch (lernt man in Japan nicht Englisch?). Ich rede jetzt von weiterführender Literatur, z.B. kenne ich keine einzige Doku, die sich mit GUI-Programmierung beschägtigt.

Gruß, mawe

[murphy]

Das mit der Doku sehe ich etwas radikaler (:D): hier hinkt Ruby meilenweit hinterher.

das glaube ich nicht. es gibt zB ri (eine art man), pickaxe 1 und das deutsche rubybuch im web.
http://www.ruby-doc.org/stdlib/ ist auch oft hilfreich.
die Japaner können übrigends eher englisch als wir. aber es gibt dort eine starke Ruby-community, und bis vor ein paar jahren war Ruby außerhalb von Japan gar kein thema.
ich glaube aber langsam, dass Deutschland die zweite heimat von Ruby ist

[mawe]

Hi murphy!

Pickaxe und das Rubybuch kenne ich, die sind auch gut.
Aber wie gesagt, ich meine werterführende Literatur, z.B. die angesprochene GUI-Programmierung. Da gibt's nichts.
Und wenn die Japaner wirklich Englisch können, dann sollen sie verd@$%& nochmal auch englische Dokus produzieren . Schliesslich ist E. die Sprache der IT, oder?

Gruß, mawe

[murphy]

GUI-Programmierung.

http://httpd.chello.nl/k.vangelder/ruby ... index.html
http://www.ruby-doc.org/docs/Programmin ... xt_tk.html
http://www.approximity.com/rubybuch2/node156_main.html

aber es stimmt, Ruby/Tk oder -FX-bücher fehlen leider. es wird aber ständig literatur produziert, manchmal sogar über etwas anderes als Java sprachen haben es an sich, mit der zeit besser dokumentiert zu sein.

ich möchte mich vor allem auf argumente stützen, die der sprache innewohnen, und sich nicht mit der zeit verändern.