mal grundsaetzlich: python vs. php...etc
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
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
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.CM hat geschrieben:__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?
Grüße
-
- Python-Forum Veteran
- Beiträge: 1209
- Registriert: Montag 29. September 2003, 17:18
- Wohnort: Purkersdorf (bei Wien [Austria])
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
Gibt's da eine Erklärung?
Gruß, mawe
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(".")
Gruß, mawe
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 .
-
- Python-Forum Veteran
- Beiträge: 1209
- Registriert: Montag 29. September 2003, 17:18
- Wohnort: Purkersdorf (bei Wien [Austria])
Hi!
Gruß, mawe
Versteh' ich nicht. split ist ja auch ein Stringmethode und es entsteht eine Liste. Ist es dadurch eine Listenmethode?Milan hat geschrieben: ... ich fänd es nämlich sehr dumm, wenn eine Liste eine Methode beherrschen würde, bei der ein String rauskommt ...
Ich fände es so einleuchtender: Verbinde die Elemente der Liste x mit einem "." Sieht so aus als wäre das wieder mal GeschmackssacheMilan hat geschrieben: ... verbinde mit "." die Liste x ...
Gruß, mawe
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 .mawe hat geschrieben:Versteh' ich nicht. split ist ja auch ein Stringmethode und es entsteht eine Liste. Ist es dadurch eine Listenmethode?
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
- User
- Beiträge: 75
- Registriert: Mittwoch 27. August 2003, 14:39
- Wohnort: 49°17'28N, 8°15'57E
- Kontaktdaten:
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
auf bald
oenone
if you don't remember something, it never happened.
if you aren't remembered, you never existed.
i don't quite understand what love is like... but if there was someone who liked me, i'd be happy.
if you aren't remembered, you never existed.
i don't quite understand what love is like... but if there was someone who liked me, i'd be happy.
ich kenne sie von Haskell. aber anstatt for und if eine zweite bedeutung zu geben, hat man in Ruby eben ein allgemeineres konzept benutzt.mawe hat geschrieben:Mittlerweile nehme ich nur noch LC. Findest Du die nicht auch ... wie soll ich sagen ... intuitiver
in codeblöcke kann man auch mal größere mengen code hineinschreiben.
Code: Alles auswählen
if x not in noprimes
Code: Alles auswählen
not noprimes.include?(x)
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 } }
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
könnte jemand bitte codeblöcke in Python simulieren
-
- Python-Forum Veteran
- Beiträge: 1209
- Registriert: Montag 29. September 2003, 17:18
- Wohnort: Purkersdorf (bei Wien [Austria])
Hi!
Gruß, mawe
Ü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.murphy hat geschrieben: es ist ein wenig länger als die PYthon-variante, aber brauchbar
Wozu? Um auch so hässliche Konstrukte zu fabrizieren? (kleiner Scherz)murphy hat geschrieben: könnte jemand bitte codeblöcke in Python simulieren
Gruß, mawe
Hi. Dein Code gibt bei mir das hier aus:
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)
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
Statt Codeblöcken nimmt man hier for-Schleifen in Kombination mit LC/besser GE, denn nix anderes sind sie in meinen Augen (bloß einzeilig)
-
- Python-Forum Veteran
- Beiträge: 1209
- Registriert: Montag 29. September 2003, 17:18
- Wohnort: Purkersdorf (bei Wien [Austria])
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
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
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Bei ruby müsste man halt ein EOF anhängen.mawe hat geschrieben:Bei mir funktionierts. Wenn Du interaktiv mit Ruby arbeiten willst, verwende irb (statt wie Du ruby).
Und das Topic müsste man auch gleich noch ändern, das PHP Mist ist haben wir alle schon auf der ersten Seite festgestellt.mawe hat geschrieben:Verschieben find ich gut, aber vielleicht gleich den ganzen Thread (war ja von Anfang an eine "welche Programmiersprache" Frage).
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
es stimmt, dass die LC mit keywords statt klammern viel simpler aussieht. und meist braucht man wohl auch nur for und if.mawe hat geschrieben:Ü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.
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)]
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 } } }
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.
du hast ein altes Ruby. früher hätte man i*2.step(50, i) schreiben müssen. ich mag Range#step lieber.Milan hat geschrieben:Hi. Dein Code gibt bei mir das hier aus:Code: Alles auswählen
-:2: undefined method `step' for #<Range:0x401407fc> (NameError)
LOL!Leonidas hat geschrieben:Wenn man es noch weiter treiben will kann man auch die Operatoren auslassen und direkt mit __mul__ und co arbeiten.
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
-
- Python-Forum Veteran
- Beiträge: 1209
- Registriert: Montag 29. September 2003, 17:18
- Wohnort: Purkersdorf (bei Wien [Austria])
Hi!
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
Syntax-Zucker?CM hat geschrieben: syntactic sugar (wie heißt das auf Deutsch?)
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
das glaube ich nicht. es gibt zB ri (eine art man), pickaxe 1 und das deutsche rubybuch im web.mawe hat geschrieben:Das mit der Doku sehe ich etwas radikaler (:D): hier hinkt Ruby meilenweit hinterher.
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
-
- Python-Forum Veteran
- Beiträge: 1209
- Registriert: Montag 29. September 2003, 17:18
- Wohnort: Purkersdorf (bei Wien [Austria])
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
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
http://httpd.chello.nl/k.vangelder/ruby ... index.htmlmawe hat geschrieben:GUI-Programmierung.
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.