Kennt jemand eine Aussage, ob und wenn ja welche Programmiersprache Python's Objektorientierung beeinflusst hat?
Wikipedia listet ABC,[1] ALGOL 68,[2] C,[3] C++,[4] Haskell, Icon, Java, Lisp, Modula-3, Perl. ABC ist klar, Algol 68, nun ja, Urvater und so. C und C++ meinetwegen, wobei C++ höchstens das Objektsystem beigesteuert haben könnte und das wiederum sehe ich eigentlich nicht. Klar gab es Mehrfachvererbung von Tag 1, aber z.B. die Vererbung war eine andere. Später hat Python dann ja die Vererbungsstrategie von Dylan übernommen. Und wo war Perl ein Vorbild für Python? Java ist neuer als Python, das kann kein Vorbild für die ursprüngliche Version gewesen sein. Dito Haskell, was ungefähr zeitgleich aufkam. Icon ist eine von diesen Sprachen (wie z.B. CLU) die man gerne als Referenz zitiert, die ich aber zu wenig kenne, um da den Finger auf bestimmte Features zu legen.
PS: Wo hat Ruby eigentlich die Blöcke her? Ich dachte, dass war Sather, doch Wikipedia zitiert da wieder nur CLU. Dafür aber Dylan, was ich bei Python, nicht aber Ruby vermutet hätte. So richtig stimmen kann das alles nicht. Insbesondere, wie soll Ruby Sather beeinflusst haben, wo Sather 5 Jahre vor Ruby erschien? Und wurde Ruby wirklich so stark von Python beeinflusst? Wo denn bitte? Das "def" für Funktionen/Methoden?
Stefan
Pythons Inspirationsquellen
- cofi
- Python-Forum Veteran
- Beiträge: 4432
- Registriert: Sonntag 30. März 2008, 04:16
- Wohnort: RGFybXN0YWR0
Das Tutorial selbst nennt nur C++ und Modula-3: http://docs.python.org/tutorial/classes.html#classes
Bei Java und Haskell hab ich die gleichen Probleme wie du, die Perl Beeinflussung seh ich in der Sprache gar nicht (dafuer aber in der Infrastruktur).
Evtl findest du bei Guidos Blog ein paar Antworten: http://neopythonic.blogspot.com/
Bei den Ruby-Bloecken komm ich eigtl nur auf Factor und Konsorten. Allenfalls noch Lisp wenn man die Bloecke als anonyme Funktionen ansieht.
Bei Java und Haskell hab ich die gleichen Probleme wie du, die Perl Beeinflussung seh ich in der Sprache gar nicht (dafuer aber in der Infrastruktur).
Evtl findest du bei Guidos Blog ein paar Antworten: http://neopythonic.blogspot.com/
Bei den Ruby-Bloecken komm ich eigtl nur auf Factor und Konsorten. Allenfalls noch Lisp wenn man die Bloecke als anonyme Funktionen ansieht.
Michael Markert ❖ PEP 8 Übersetzung ❖ Tutorial Übersetzung (3.x) ⇒ Online-Version (Python 3.3) ❖ Deutscher Python-Insider ❖ Projekte
OK, C sehe ich ein und Lisp würde ich auch glauben. Modula-3 kenne ich wieder zu wenig, ist aber wohl stark von Wirths Modula-2 abgewichen. Wird auch bei Java als Referenz genanntcofi hat geschrieben:Das Tutorial selbst nennt nur C++ und Modula-3: http://docs.python.org/tutorial/classes.html#classes
Factor ist VIEL neuer. Blöcke - schon der Name - kommen von Smalltalk, aber die Idee, das man das hinter dem Methodenaufruf so syntaktisch schreiben kann stammt glaube ich aus Sather. Ein "ary.each do |x| x.foo end" bzw. "ary.each {|x| x.foo}" wäre in Smalltalk "ary do: [:each | x foo]" gewesen.cofi hat geschrieben:Bei den Ruby-Bloecken komm ich eigtl nur auf Factor und Konsorten. Allenfalls noch Lisp wenn man die Bloecke als anonyme Funktionen ansieht.
Ich versuche ja gerade für einen Vortrag ein bisschen die Programmiersprachen einzuordnen.
Kann jemand noch was zu der Icon-Referenz von Python sagen?
Stefan
Haskell sieht man IMHO ziemlich deutlich in den "list comprehensions". Ansonsten mal die Ausbeute einer kleinen Recherche im Netz. Die Sachen ohne Quellenangabe sind meine Vermutungen.
ABC [1]
„This is the origin of many Python features, including the use of indentation for statement grouping and the inclusion of very-high-level data types (although the details are all different in Python).“
-- http://docs.python.org/faq/general#why- ... irst-place
ALGOL 68 [2]
„String slicing came from Algol-68 and Icon.“
-- http://www.amk.ca/python/writing/gvr-interview
C [3]
„C is another influence, second only to ABC in importance. Most of Python's keywords, such as break, continue and others, are identical to C's, as are operator priorities. C also affected early extension modules; many of them, such as the socket and POSIX modules, are simply the corresponding Unix C functions translated into Python, with some modifications to make programming more comfortable.“
-- http://www.amk.ca/python/writing/gvr-interview
C++ [4]
„[Class mechanisms] It is a mixture of the class mechanisms found in C++ and Modula-3.“
-- http://docs.python.org/tutorial/classes.html
Haskell
List comprehension. `map()`, `filter()`, `reduce()`, `itertools`.
Icon
„String slicing came from Algol-68 and Icon.“
-- http://www.amk.ca/python/writing/gvr-interview
Java
`logging`, `threading`, `unittest`. Decorator-Syntax (nicht Semantik!)?
Lisp
``lambda``?
Modula-3
„Modula-3 is the origin of the syntax and semantics used for exceptions, and some other Python features.“
-- http://docs.python.org/faq/general#why- ... irst-place
„What I learned there later showed up in Python's exception handling, modules, and the fact that methods explicitly contain 'self' in their parameter list.“
-- http://www.amk.ca/python/writing/gvr-interview
„[Class mechanisms] It is a mixture of the class mechanisms found in C++ and Modula-3.“
-- http://docs.python.org/tutorial/classes.html
„[…] I had some experience with Modula-2 and Modula-3, so I decided the module would be one of Python's major programming units.“
-- http://www.artima.com/intv/python.html
ABC [1]
„This is the origin of many Python features, including the use of indentation for statement grouping and the inclusion of very-high-level data types (although the details are all different in Python).“
-- http://docs.python.org/faq/general#why- ... irst-place
ALGOL 68 [2]
„String slicing came from Algol-68 and Icon.“
-- http://www.amk.ca/python/writing/gvr-interview
C [3]
„C is another influence, second only to ABC in importance. Most of Python's keywords, such as break, continue and others, are identical to C's, as are operator priorities. C also affected early extension modules; many of them, such as the socket and POSIX modules, are simply the corresponding Unix C functions translated into Python, with some modifications to make programming more comfortable.“
-- http://www.amk.ca/python/writing/gvr-interview
C++ [4]
„[Class mechanisms] It is a mixture of the class mechanisms found in C++ and Modula-3.“
-- http://docs.python.org/tutorial/classes.html
Haskell
List comprehension. `map()`, `filter()`, `reduce()`, `itertools`.
Icon
„String slicing came from Algol-68 and Icon.“
-- http://www.amk.ca/python/writing/gvr-interview
Java
`logging`, `threading`, `unittest`. Decorator-Syntax (nicht Semantik!)?
Lisp
``lambda``?
Modula-3
„Modula-3 is the origin of the syntax and semantics used for exceptions, and some other Python features.“
-- http://docs.python.org/faq/general#why- ... irst-place
„What I learned there later showed up in Python's exception handling, modules, and the fact that methods explicitly contain 'self' in their parameter list.“
-- http://www.amk.ca/python/writing/gvr-interview
„[Class mechanisms] It is a mixture of the class mechanisms found in C++ and Modula-3.“
-- http://docs.python.org/tutorial/classes.html
„[…] I had some experience with Modula-2 and Modula-3, so I decided the module would be one of Python's major programming units.“
-- http://www.artima.com/intv/python.html
Du musst bedenken dass die Syntax die erst später hinzugekommen ist wahrscheinlich mit einbeziehen. Dadurch passen dann Dylan(mro, super) und Haskell (LC/GenExp).
Bei Perl kann man die "kulturellen" Unterschiede nennen, in wie weit dies aber eine Antwort auf Perl oder einfach Zufall ist kann man natürlich schwer beurteilen.
Bei Rubys Blöcken würde ich mal davon ausgehen dass die hauptsächlich von Smalltalk inspiriert wurden.
Bei Perl kann man die "kulturellen" Unterschiede nennen, in wie weit dies aber eine Antwort auf Perl oder einfach Zufall ist kann man natürlich schwer beurteilen.
Bei Rubys Blöcken würde ich mal davon ausgehen dass die hauptsächlich von Smalltalk inspiriert wurden.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
sma, eine Sprache muss nicht älter sein um als Inspiration zu dienen, denn selbst seit Python 1.5 hat sich noch einiges geändert, wie eben LCs und GEs. Der neue ternäre Operator kann vielleicht aus Perl kommen, er erinnert mich immer an das nachgestellte ``if`` was es in Ruby etwa vorkommt. Ich schätze das kommt aus Perl, aber dafür kann ich Perl zu wenig. Ähnlich auch CoffeeScript <-> CoCo, die sich gegenseitig inspirieren.
Achja, und vielleicht lexikalisches Scoping
Ich denke auch ``filter``, ``map`` und ``reduce``. Ich meine ein Zitat gelesen zu haben dass es Lisper waren die es mitgebracht haben, aber das einzige was ich gerade finden kann ist dies.BlackJack hat geschrieben:Lisp
``lambda``?
Achja, und vielleicht lexikalisches Scoping
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Igitt, Perl doch nicht.proofy hat geschrieben:Perl: RegEx, globale variablen wie _ , hashes also dict
Reguläre Ausdrücke sind in Perl stark integriert, aber sie beschränken sich nicht auf Perl. _ ist einfach ein Variablenname und nicht zwangsweise global. Assoziative Arrays gab es auch schon vor den Hashes von Perl.
Für mich ist Perl die Antithese von Python.
Perl hat Python wohl vor allem dahingehend beeinflusst, dass Python eben nicht Perl ist, sprich die Schwächen von Perl eben genau nicht übernommen hat. Ansonsten hatte Python wohl vor allem am Anfang dieselbe Zielgruppe wie Perl.
Habe es erst mal nur zeitgeschichtlich beantwortet. Gute Quellen:
http://www.heise.de/ix/artikel/Entwickl ... 06466.html
http://www.oreilly.de/artikel/prog_sprachen_poster.pdf
Über Vor/Nachteile, Schwächen und Stärken soll es hier wohl eben nicht gehen.
Ich meine die RegExp Engine in Python ist so wie in Perl und das muss ja nicht zwangsweise so sein, oder gibt es da doch Unterschiede?
Ich habe es erst mal so gelernt, dass _ zwangsweise global ist und das kam mir sehr perlmäßig bzw. shellmäßig vor
Welche Programmiersprache hatte denn vorher typenlose assoziative Arrays, die kompatibel zu normalen Arrays sind?
http://www.heise.de/ix/artikel/Entwickl ... 06466.html
http://www.oreilly.de/artikel/prog_sprachen_poster.pdf
Über Vor/Nachteile, Schwächen und Stärken soll es hier wohl eben nicht gehen.
Ich meine die RegExp Engine in Python ist so wie in Perl und das muss ja nicht zwangsweise so sein, oder gibt es da doch Unterschiede?
Ich habe es erst mal so gelernt, dass _ zwangsweise global ist und das kam mir sehr perlmäßig bzw. shellmäßig vor
Code: Alles auswählen
>>> 4 + 4
8
>>> _
8
>>> _ = 3
>>> 5 * 5
25
>>> _
3
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Die Regex-Engine von python ist nur insofern Perl-ähnlich, das sie Erweiterte Reguläre Ausdrücke versteht. Die Regex-Engine die Perl jedoch am ähnlichsten ist, ist wohl PCRE (Perl Compatible Regular Expressions), die von einiger Software verwendet wird, nicht jedoch von Python. Ansonsten könnte man ja argumentieren dass jeder Sprache die Reguläre Ausdrücke in der Stdlib hat, von perl inspiriert ist, aber spätestens bei Java fällt einem das dann doch schwer zu glaubenproofy hat geschrieben:Ich meine die RegExp Engine in Python ist so wie in Perl und das muss ja nicht zwangsweise so sein, oder gibt es da doch Unterschiede?
Das ist nur im interaktiven Interpreter so, wenn du versuchst ein Programm zu schreiben, dass ``_`` so verwendet wird es scheitern, da ``_`` nicht definiert ist. Genauso wie IPython nicht nur den letzten Wert unter ``_`` abspeichert sondern sogar noch weitere, bereits berechnete Werte in nummerierten Variablen abspeichert.proofy hat geschrieben:Ich habe es erst mal so gelernt, dass _ zwangsweise global ist und das kam mir sehr perlmäßig bzw. shellmäßig vor
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
@proofy: Was meinst Du mit der „ Kompatibilität zwischen Arrays und assoziativen Arrays“? Es ist übrigens im Kontext von Python besser, von „Listen“ und „Wörterbüchern“ zu sprechen, um Verwechselungen mit dem Modul "array" aus der Standardbibliothek zu vermeiden. Die Typen aus diesem Modul haben mit den Arrays aus Perl nichts zu tun.
Von Perl inspiriert waren vielleicht die "backticks" anstelle von `repr()`. Seht her wir haben auch unleserliche Syntax…
@proofy: Es gibt Unterschiede bei den `re`s, aber Python ist da eindeutig von Perl's re-Syntax inspiriert.
`_` ist in der Python-Shell immer an das letzte Ergebnis gebunden, das nicht `None` war. Aber auch nur im Namensraum der Python-Shell -- nicht global. In Programmen/Modulen ist das ein Name wie jeder andere.
Vor Perl gab es schon AWK und parallel dazu Tcl. Die haben zwar für die allgemeine Abbildung und die spezielle Abbildung bei der die Schlüssel zusammenhängende Bereiche von ganzen Zahlen sind, letztendlich die gleiche Datenstruktur verwenden, aber dadurch war der Zugriff syntaktisch auch gleich.
Und natürlich der Klassiker Smalltalk. Die Schnittstelle für den Elementzugriff ist da bei beiden Typ(unter)arten identisch.
@proofy: Es gibt Unterschiede bei den `re`s, aber Python ist da eindeutig von Perl's re-Syntax inspiriert.
`_` ist in der Python-Shell immer an das letzte Ergebnis gebunden, das nicht `None` war. Aber auch nur im Namensraum der Python-Shell -- nicht global. In Programmen/Modulen ist das ein Name wie jeder andere.
Vor Perl gab es schon AWK und parallel dazu Tcl. Die haben zwar für die allgemeine Abbildung und die spezielle Abbildung bei der die Schlüssel zusammenhängende Bereiche von ganzen Zahlen sind, letztendlich die gleiche Datenstruktur verwenden, aber dadurch war der Zugriff syntaktisch auch gleich.
Und natürlich der Klassiker Smalltalk. Die Schnittstelle für den Elementzugriff ist da bei beiden Typ(unter)arten identisch.
Bei RegExen ist Perl der dominante Orientierungspunkt für die meisten Programmiersprachen. Siehe dazu auch Friedls Buch. Zum Vergleich, Versucht mal mit dem Emacs (klassische) Regexe zu schreiben und wundert euch.
Das Design der OOP ist allerdings der wichtigste Einflussfaktor den Python auf Perl hatte, und nicht umgekehrt. Perl4 kannte IIRC gar kein OOP!
Frühe Versionen von Python hatten m.E. bereits OOP aber bei weitem nicht den Funktionsumfang Perls, da musste nachgerüstet werden um den Markt zu bedienen. (Perl und TCL waren mal die dominierenden Scriptsprachen)
Von Übernehmen würde ich aber nicht sprechen, da erstens Perl selbst vieles übernommen hat (C, LISP, sed, awk, sh) und zwotens Guido viel Wert auf ein eigenständiges orthogonales Design und restriktive Philosophie gelegt hat.
Z.B. Lamdas bewusst auf nur ein Statement zu beschränken ist eine Entscheidung die Larry Wall nie einfallen würde. Das sind diametrale Standpunkte in der gleichen Nische.
Ruby und PHP hingegen sind de facto hauptsächlich durch Perl beeinflusste Redesigns. Auch Javascript zeigt sehr deutliche Anleihen.
Das sind schlichtweg damalige Markterfordernisse, heutzutage sieht man wie neuere Javascript Extensions von Python inspiriert werden.
Ich würde aber auch davor warnen in den Sprachdesignern die ultimativen Visionäre zu sehen, es spielen viele Umweltfaktoren eine Rolle die manch genialeres Projekt früh sterben ließ.
Das Design der OOP ist allerdings der wichtigste Einflussfaktor den Python auf Perl hatte, und nicht umgekehrt. Perl4 kannte IIRC gar kein OOP!
Frühe Versionen von Python hatten m.E. bereits OOP aber bei weitem nicht den Funktionsumfang Perls, da musste nachgerüstet werden um den Markt zu bedienen. (Perl und TCL waren mal die dominierenden Scriptsprachen)
Von Übernehmen würde ich aber nicht sprechen, da erstens Perl selbst vieles übernommen hat (C, LISP, sed, awk, sh) und zwotens Guido viel Wert auf ein eigenständiges orthogonales Design und restriktive Philosophie gelegt hat.
Z.B. Lamdas bewusst auf nur ein Statement zu beschränken ist eine Entscheidung die Larry Wall nie einfallen würde. Das sind diametrale Standpunkte in der gleichen Nische.
Ruby und PHP hingegen sind de facto hauptsächlich durch Perl beeinflusste Redesigns. Auch Javascript zeigt sehr deutliche Anleihen.
Das sind schlichtweg damalige Markterfordernisse, heutzutage sieht man wie neuere Javascript Extensions von Python inspiriert werden.
Ich würde aber auch davor warnen in den Sprachdesignern die ultimativen Visionäre zu sehen, es spielen viele Umweltfaktoren eine Rolle die manch genialeres Projekt früh sterben ließ.
siehe http://www.python-forum.de/viewtopic.ph ... 98#p162319sma hat geschrieben: Und wurde Ruby wirklich so stark von Python beeinflusst? Wo denn bitte? Das "def" für Funktionen/Methoden?