Andere Programmiersprachen

[Brafil]

Ich gedenke eine andere progsprache dazu zu lernen (nur Python reicht nicht immer) Aber welche würde die beste sein? Meint ihr, Java wäre geeignet? Oder vielleicht auch die C-Familie? Perl? Falls jemand sich da auskennt, wäre es gut, aber alle vorschläge helfen.

[gerold]

alle vorschläge helfen.

Hallo Brafil!

Die Frage ist, was die Programmiersprache können soll. Willst du Mikrocontroller wie z.B. den ATmega8 programmieren? Willst du hardwarenahe Treiber programmieren? Willst du interaktive Websites programmieren? Willst du komplexe Berechnungen durchführen?

Denn für alles Andere ist Python meist die beste Wahl. Und für komplexe Berechnungen haben wir PyRex und andere Erweiterungen zur Verfügung, mit denen man Module erstellt die von Python importiert werden können.

http://www.99-bottles-of-beer.net/

mfg
Gerold

[Rebecca]

Das kommt ein wenig darauf an, warum du eine zweite Programmiersprache lernen willst. Meine persoenliche Meinung:

Java habe ich noch nie gemocht, und seitdem ich Python kann, finde ich es einfach nur noch umstaendlich. Ich sehe auch nichts, was Java kann, was mir in Python fehlen wuerde. Einziges Argument fuer Java finde ich, dass es momentan furchtbar in ist und man deswegen oft nicht drumherum kommt.

Perl mag ich ebenfalls nicht. Ok, Perl kann ich fast gar nicht, der Code ist mir einfach schon zu unleserlich. Aber hier denke ich ebenfalls, dass Perl einem nicht mehr geben kann als Python, es sei denn, man steht auf kurzen, kryptischen Code.

C hat da schon einen ganz anderen Anwendungsbereich, es ist maschinennaeher und bringt viel mehr Geschwindigkeit, dadurch ergaenzt es sich mit Python sehr gut. Es laesst sich auch sehr gut mit Python verbinden (Python-Module in C schreiben oder Python in C einbinden). Das ist praktisch, wenn man mit Python doch mal Geschwindigkeitsprobleme bekommt oder maschinennah programmieren will (z.B. Hardware ansprechen). Hier hat man auch mal die Gelegenheit, ein wenig mehr die Grundlagen von Computern, Betriebssystemen und Programmiersprachen kennenzulernen, muss dafuer aber auch sehr viel mehr programmieren, um einfache Dinge zu erreichen.

Wenn du mal eine ganz andere Denkweise kennelernen willst, waere eine funktionale Programmiersprache interessant.

[Brafil]

Also das ärgert mich ein bißchen weil ich nicht weiß ob und wie man runtimes mit python erzeugt. Ich weiß, dass Python super ist. aber meine nächste wahl wäre PHP oder Java, für Applications oder websites (Natürlich in verbindung mit Python)

[skypa]

Kann man denn auch C-Code assembliert in Python packen, wie es bei Perl der Fall is?
Bestes Beispiel Perl Exploits.
Oder muss man zwangsweise es in ein Modul packen?
Mir gefallen manche Syntax Sachen besser bei Perl als bei Python,
aber Python is widerum "ausgebauter".
Ich will z.b. ein Musikverwaltungsprogramm schreiben für nen Kollegen, der hatte riesige Datenmengen an Mucke, das ganze Pattern Matching mit dynamischen Suchen+Ersetzen Operationen is in Perl stilistischer als in Python, aber ne schicke GUI kriegt man anscheinend nur mit Python und den Module wie wxPython oder so hin.

So schauts aus...

[BlackJack]

@Brafil: Was meinst Du mit "runtimes erzeugen"?

Ansonsten bin ich auch der Meinung, dass C eine gute Wahl als ergänzende Sprache zu Python ist, wegen der Bindungsmöglichkeiten und weil's recht weit verbreitet ist.

Und wie Rebecca schon erwähnte etwas funktionales wenn man den Horizont erweitern möchte.

Perl, C#, Java bieten eigentlich nichts was man mit Python nicht auch machen könnte. Ausser statische Typisierung bei C# und Java, aber wer will das schon. Bzw. wenn man das will, finde ich "type inference" wie bei OCaml oder Haskell angenehmer. In Haskell würde ich aber keine grösseren Sachen programmieren wollen. Dafür ist mein Gehirn einfach nicht richtig verdrahtet.

Wobei sich D, für eine statisch typisierte Sprache ohne "type inference" IMHO ganz gut "anfühlt". Da bleibt abzuwarten ob sie sich durchsetzt. Verdient hätte sie es. IMHO.

Bei dem Begriff "C-Familie" möchte ich noch anmerken, dass C, C++, und C# drei grundverschiedene, eigenständige Sprachen sind. Die Syntax ist sehr ähnlich, aber die Philosiphie und die idiomatische Verwendung unterscheiden sich stark.

@skypa: Mir ist kein Hack bekannt "nativen Binärcode" in Python-Quelltext ein zu betten. Wobei ich das jetzt auch nicht unbedingt als Nachteil sehe. Mit einem extra Modul oder einer "shared library" dürfte der Umgang jedenfalls einfacher sein, wenn man das ganze für verschiedene Plattformen übersetzt.

[gerold]

ob und wie man runtimes mit python erzeugt
[...]
PHP oder Java, für Applications oder websites

Hallo Brafil!

Mit Runtimes -- meinst du damit ausführbare Programme? Mein bevorzugter Weg (nur unter Windows) ist der, dass ich mit *cx_freeze* alles was zur Ausführung des Programmes benötigt wird, in einen Ordner packe. Und diesen Ordner packe ich mit einem Installer, wie z.B. InnoSetup, in ein ausführbares Setupprogramm. Siehe: http://www.python-forum.de/topic-5726.html

Dieses Setup kann dann von den Kunden ausgeführt werden. Dieses kopiert die Dateien in einen Programmordner unterhalb des Ordners "C:\Programme*, erstellt einen Startmenüeintrag und kann auch Einstellungen in INI-Dateien oder der Registry vornehmen. So kann man das Programm auch wieder über die Systemsteuerung deinstallieren.

Alles in Allem ist der Aufwand nicht größer als bei meinen Visual Basic Programmen.

Was die Webanwendungen betrifft, bist du mit Python nicht schlecht beraten. PHP ist auf den Webservern viel häufiger vertreten, weil es sich so einfach installieren lässt. Aber mit Python hast du ein universelles Werkzeug in der Hand. Je größer deine Webanwendung wird, desto mehr wird es dich freuen, auf Python gesetzt zu haben.

Django, CherryPy, Werkzeug, Cheetah-Template -- um nur einige Hilfsmittel für die Webentwicklung zu nennen.

Jeder hat hier seine eigenen Vorlieben. Meine sind CherryPy und Cheetah. Was man hier http://halvar.at/python/cherrypy_cheetah/ ganz gut herauslesen kann. Einen kleinen Überblick bekommst du vielleicht hier: http://xivilization.net/pydocs/2.6/howt ... rvers.html
Das HowTo ist aber laut Autor noch nicht ganz fertig. Im Wiki findest du auch ein paar Seiten darüber: [wiki]Python im Web[/wiki]

Was die Entwicklung von GUI-Anwendungen betrifft: Da bist du bei Python komplett richtig. Mit wxPython erstellst du plattformübergreifende, gut aussehende GUI-Anwendungen, die sich mit cx_freeze für Windows gut in einen Ordner packen lassen. Für Linux brauchst du das nicht, da ich keine Distribution kenne, bei der Python nicht installiert ist. Und wxPython lässt sich meist mit einem kurzen Befehl installieren. Du kannst mit cx_freeze dein Programm aber auch für Linux packen. Damit bist du dann auch von der installierten Python- und wxPython-Version unabhängig.

mfg
Gerold


PS: Um einen Überblick über die Möglichkeiten von Python zu bekommen, sollte man sich einfach mal die eingebauten Module von Python http://docs.python.org/modindex.html durchsehen. Und was nicht eingebaut ist, gibt es über den Package Index: http://docs.python.org/modindex.html

.

[gerold]

Kann man denn auch C-Code assembliert in Python packen

Hallo Skypa!

Das nicht, aber eine C-Library ist ja nur eine Datei. Und diese Library kann im gleichen Ordner wie das Hauptprogramm liegen. Du kannst mit C oder einer anderen Sprache Libraries schreiben, die du in einem Python-Modul verwenden kannst. Mit *ctypes* kannst du z.B. direkt auf C-Libraries zugreifen. Auf Posix oder die Windows-API oder sogar direkt auf die libc.

Und mit PyRex http://www.cosc.canterbury.ac.nz/greg.e ... hon/Pyrex/ kannst du in einer Python-ähnlichen Sprache C-Libraries schreiben, die in Python-Modulen importiert werden können. Wenn du auf Performance stehst, dann würde ich mir das mal ansehen und ausprobieren.

mfg
Gerold

[skypa]

Klingt gut, danke für die Info, ich schaus mir später mal an, wenn ich wieder zu Hause bin

[Leonidas]

Einen kleinen Überblick bekommst du vielleicht hier: http://xivilization.net/pydocs/2.6/howt ... rvers.html
Das HowTo ist aber laut Autor noch nicht ganz fertig.

Ganz recht und so sehr es mich auf freut, dass darauf verwiesen wird - bitte nicht darauf linken. Denn das sind nur meine lokal gebauten Sourcen. Wird aber hoffentlich bald hier landen.

Und nun ja, zu weiteren Sprachen neben Python nehme ich eine ganz ähnliche Stellung ein wie die anderen: es hängt eben ab, was du willst.

Wenn du eine andere Sichtweise auf Scripting haben willst, dann kannst du dir mal Ruby (die Sprache, nicht Rails das Framework) ansehen. Es verfolgt eine andere Philosophie als Python und geht daher andere Wege, aber es gibt Leute die mögen das.

Dann die "klassischen" Programmiersprachen: C wäre eine Wahl, wenn man performancekritische Sachen machen will oder mal gucken will wie es "eine Ebene tiefer" abläuft. Außerdem ist es sehr portabel. Für größere Sachen würde ich es jetzt aber nicht einsetzen.

C++, Java und C# sehe ich weniger positiv. Java ist sehr viel Boilerplate und für C# gibt es vergleichsweise wenige Implementierungen - wenn dann würde ich wohl Mono nutzen, aber das hängt leider meist hinterher.

Was recht nett ist, ist JavaScript. Für so kleine Sachen in Webseiten, oftmals mit Hilfe einer guten Library ist es eigentlich optimal.

Für persönliche Entwicklung würde ich eine funktionale Programiersprache vorschlagen. Scheme wäre eine Idee, OCaml ebenso - sind beides Hybriden, mit denen du sowohl funktional als auch imperativ schreiben kannst.

[BlackVivi]

Wobei sich D, für eine statisch typisierte Sprache ohne "type inference" IMHO ganz gut "anfühlt". Da bleibt abzuwarten ob sie sich durchsetzt. Verdient hätte sie es. IMHO.

Das wollte ich nochmal unterschreiben --> D ist eine tolle Sprache. Sie ist recht Maschinennah, in mancher Hinsicht sogar schneller als C++*, sie besitzt eine sinnvolle Philosophie und ist sehr gut kombatibel mit C und C++. Ich kann es bei weitem nicht perfekt --> Aber ich lerne es gerne.

*Damit meine ich die Implementation von C im GCC im Gegensatz zur Digital Mars Implementierung von D.

[gerold]

Hallo!

Ergänzend zu diesem Beitrag http://www.python-forum.de/post-85540.html#85540 möchte ich auch noch auf GUI2Exe http://xoomer.alice.it/infinity77/main/GUI2Exe.html von Andrea Gavana hinweisen.

mfg
Gerold

[Leonidas]

*Damit meine ich die Implementation von C im GCC im Gegensatz zur Digital Mars Implementierung von D.

Die aber nicht so portabel (Windows, vermutlich 32-Bit und Linux auf x86 ist keine große Auswahl) und nicht so frei ist. Insofern hat GDC da einige Vorteile.

[BlackVivi]

*Damit meine ich die Implementation von C im GCC im Gegensatz zur Digital Mars Implementierung von D.

Die aber nicht so portabel (Windows, vermutlich 32-Bit und Linux auf x86 ist keine große Auswahl) und nicht so frei ist. Insofern hat GDC da einige Vorteile.

GDC wiederum hängt in einigen Teilen dem DMD hinterher, aber ich denke das einmal geschriebener Code von beidem übersetzt werden kann. Falls es nicht klappt, gibt's ja immernoch die Möglichkeit nachzuschauen, welche Funktion nicht implementiert ist.

[sma]

Brafil, du sagst nicht, wofür du die neue Programmiersprache einsetzen willst. Daher gehe ich davon aus, du willst sie einfach lernen, um deinen Horizont zu erweitern.

An Java kommst du wahrscheinlich nicht vorbei, wenn du als Software-Entwickler im "Enterprise"-Umfeld arbeiten willst und dort Server-Anwendungen oder Web-Anwendungen bauen sollst. Technisch interessant ist diese Sprache aber eigentlich nicht. In einem "Windows Shop" ist es vielleicht alternativ C#, aber außer dass diese Sprache noch ein bisschen größer und damit auwendiger zu lernen ist, gibt es kaum Unterschiede.

Aus dem gleichen Grund - laaangweilig - würde ich auch von C(++), Pascal oder (Visual)Basic abraten. Alles die selbe Soße: Imperative Programmiersprachen aus den frühen 70er Jahren - manchmal garniert mit etwas automatischer Speicherverwaltung und begleitet von gewaltigen Klassen-Bibliotheken. Praktisch, doch fade, was interessante neue Konzepte angeht.

Da jeder hier seine Lieblingssprache (evtl. nach Python ;) nennt, möchte auch ich die Gelegenheit nutzen: Du willst Smalltalk lernen.

Smalltalk ist der Urvater der Objektorientierung. Der Begriff selbst wurde von Alan Kay, dem Erfinder der Sprache, erfunden. Simula aus den späten 60ern hatte zwar auch schon ähnliche Konzepte, doch haben dessen Väter nur ein angepasstes Algol bauen wollen und kein neues Programmierparadigma schaffen wollen. Somit ist Smalltalk neben Lisp (und Scheme) ein Meilenstein in der (immer noch kurzen) Geschichte der Informatik und Wert, gekannt zu werden. Außerdem macht die Sprache Spaß, sie ist natürlich dynamisch getypt, hat eine automatische Speicherverwaltung und ausdrucksstark bei sehr kleinem Sprachkern - Python ist daneben fett und schwerfällig.

Inklusive Python haben die meisten Sprachen Kays Idee der Objektorientierung nicht verstanden und/oder unvollständig umgesetzt. IMHO trifft Erlang noch am besten, was sich Kay überlegt hat: Unabhängige Objekte (Prozesse, Akteure), die ("turtels all the way down") immer wieder aus kleinen Objekten zusammengesetzt sind, kommunizieren dynamisch durch den Austausch von Nachrichten. Klassen, Vererbung, usw. kamen erst später als Implementationsdetail dazu, nicht jedoch als paradigmenstiftendes Konzept.

Leider sind die existierenden Smalltalk-Systeme grenzwertig ungewohnt (Squeak hat ein ausgesucht hässliches UI, VisualWorks wirkt alt - ist aber das schnellste und mächtigste Smalltalk-System, und Dolphin-Smalltalk (ein nettes kleines System speziell für Windows) ist vor kurzem gestorben, weitere Systeme trauen sich kaum aus ihrer Nische heraus) und der Einstieg ist nicht daher nicht einfach. James Robertson müht sich jedoch redlich, mit podcast und videoblog Tutorials einen Einstieg in VisualWorks zu bieten.

Ruby ist übrigens ein Smalltalk mit anderer Syntax - das Objektmodell bis hin zu vielen Methodennamen wurde übernommen (daher hängen jetzt viele ehemalige Smalltalker in der Ruby-Community ab, Martin Fowler etwa oder der Kerl, der RSpec gemacht hat). Objective-C, die Systemsprache von Mac OS/X, ist ebenfalls ein Smalltalk mit anderer Syntax. Brad Cox hatte 1986 behauptet, Smalltalk auch in C machen zu können und als einer der wenigen wirklich eine Sprache geschaffen, die Smalltalks "message passing" korrekt umgesetzt hat. Nix C-with-classes aka C++, was direkt von Simula erbt und Smalltalk nie als Vorbild hatte.

Wenn die Historie kein Grund ist, dann ist Seaside einer, sich mit Smalltalk zu beschäftigen. Dies ist ein Webrahmenwerk, welches auf continuations basiert - ziemlich cool. Scheme (genauer PLT-Scheme hat ebenfalls so ein Rahmenwerk, doch das scheint mir schlechter dokumentiert und damit weniger zugänglich). Seaside ist einfach anders als übliche Rahmenwerke und damit interessant. Avi Bryant, der Erfinder von Seaside, hat übrigens zuerst in Ruby versucht, die Idee umsetzten und ist dann zu Smalltalk gewechselt...

Oh, wenn's einfach um "mal anders" geht, wäre neben Haskell, das die meisten auch "anders" finden, noch ein Blick auf Factor empfehlenswert. Dies ist ein funktionales Forth, ebenfalls eine ungewöhnliche und interessante Sprache aus den 70ern. Factor ist jedoch moderner. Wenn dich mehr die Theorie hinter Factor interessiert, kann man sich auch Joy angucken.

Weiter oben wollte ich noch erwähnen, dass Objektorientierung als Problemlösungsansatz IMHO das beste Vorgehen ist und ansonsten (gemäßigte) funktionale Programmierung empfehlen. Habe aber kleine Lust, das alles nochmal umzuschreiben. Ist eh schon zu lang ;)

Will man jetzt noch für mehr als einen Prozessor programmieren (Stichwort "concurrent programming") dann ist Erlang die Sprache der Wahl. Das sei meine letzte Empfehlung.

Obwohl: Will man alles kombinieren, also Java, Smalltalk, Haskell, Erlang, funktionale und objektorientierte Programmierung, dann empfehle ich noch Scala, auch wenn mir die Sprache (konzeptbedingt durch das statischem Typsystem) zu viel Ballast mitschleppt und ich sie doch schwer zu beherrschen finde.

Stefan

[BlackJack]

Als Alternative zu SmallTalk könnte man sich auch Io anschauen, was ebenfalls "nur" aus Objekten und Nachrichten besteht. Auf der Seite gibt's einen Vergleich der "Einfachheit" des Sprachkerns anhand der Anzahl der Schlüsselworte. Da kommt Python mit 28 Schlüsselworten an Platz 4. Platz 1 ist Io mit 0, gefolgt von SmallTalk mit 5 Schlüsselworten. Zwischen SmallTalk und Python ist noch Lua.

Io ist allerdings noch sehr jung und noch in Bewegung, da kann sich auch mal die API von grundlegenden Objekten ändern.

@sma: Was fehlt Python denn zur eigentlichen Objektidee von Kay? Ich dachte immer den üblichen Verdächtigen fehlt nur die Möglichkeit auch auf Nachrichten zu reagieren, für die kein "Slot" vorgesehen ist. Das kann Python ja mit `__getattr__()` und `__setattr__()`. Oder müssen die Nachrichten zwingend asynchron sein? Sind sie dass denn automatisch bei SmallTalk? Ich kenne das nur von Rexx.

[Leonidas]

@sma: Was fehlt Python denn zur eigentlichen Objektidee von Kay? Ich dachte immer den üblichen Verdächtigen fehlt nur die Möglichkeit auch auf Nachrichten zu reagieren, für die kein "Slot" vorgesehen ist. Das kann Python ja mit `__getattr__()` und `__setattr__()`.

Ja, das dachte ich mir eben auch, dass es in Python ja auch so eine Art "Nachrichtenübertragung" gibt in die man mit den magischen Methoden eingreifen kann (und auch mit Properties). Allerdings muss ich sagen, dass ich in Smalltalk nichts gemacht habe, weil mich die Implementierungen immer abgeschreckt haben.

[sma]

Io ist eine nette kleine Sprache, war die letzten Jahre aber doch sehr im Fluss. Und ob man die Einfachheit nun wirklich nur an der Anzahl der Schlüsselworte zählen kann?

Bei Smalltalk und Io gibt es wie bei Scheme das Streben nach einer uniformen Syntax. Insbesondere lassen sich dadurch Kontrollstrukturen (Schleifen, bedingte Anweisungen) in der Sprache ausdrücken und auch erweitern. Das ist ein mächtiges Feature, doch es macht die Sprache nicht unbedingt einfacher. Die (operationelle) Semantik von Io lässt sich nicht so einfach beschreiben, man muss sie aber kennen, um das Programm zu verstehen. Ich finde sie - aber das ist wahrscheinlich Gewohnheit, bei Smalltalk und Scheme einfacher.

Am einfachsten ist vielleicht Scheme: Ein Atom ist ein Ausdruck ohne Klammern, z.B. eine Zahl, ein String oder ein Symbol. Bis auf Symbole, die als Variablen aufgefasst werden und durch durch den an sie gebundenen Wert ersetzt werden, sind die anderen Atome direkt Werte. In Listen der Art (e0 e1 e2 ... eN) werden die Unterausdrücke e0 bis eN rekursiv ausgewertet. Das Ergebnis von e0 muss ein Funktionswert sein, der dann mit den anderen Werten als Argumente aufgerufen wird.

Ausnahme für diese Regel sind bestimmte Symbole für e0, etwa "if" oder "quote" oder "lambda". Hier passiert trotz gleicher Syntax wie bei einem Funktionsaufruf etwa anderes.

Außerdem muss man bei Scheme noch wissen, wie die Gültigkeitsbereiche von Variablen sind und dass Endrekursion den Stack nicht wachsen lässt, damit man Schleifen mittels rekursiver Funktionen effizient implementieren kann. Das war's dann aber auch schon.

Bei Smalltalk ist es ähnlich. Es gibt Literale (Zahlen, Strings, Symbole), die zu sich selbst ausgewertet werden. Es gibt drei Arten von Nachrichtenausdrücken, unäre, wo dem Objekt ein Nachrichtenname ohne Argument folgt, binäre, wo dem Namen ein Argument folgt und Schlüsselwortnachrichten, wo sich der Name der Nachricht aus Schlüsselworten zusammensetzt, denen jeweils ein Argument folgt.

Code: Alles auswählen

anArray size
3 + 4
anArray at: 1 put: #cool

Das Prinzip ist immer Objekt-Nachricht. Alles ist ein Objekt und versteht Nachrichten, weil jedes Objekt ein Exemplar einer Klasse ist (auch Klassen sind Objekte, nämlich Exemplare von Metaklassen) und Nachrichten lösen die Ausführung von über die Klassenhierarchie zu suchenden und bei den Klassen gespeichertern Methoden aus. Ergebnis ist immer ein Objekt. Ein "super send" ist noch etwas spezieller als die normale Methodensuche, aber wenn man diese beiden Konzepte, Zuweisungen mittels ":=" und "^" als return-Anweisung verstanden hat, kennt man alles.

In Smalltalk muss man nicht lernen, dass "if" wie in Scheme etwas besonderes ist, sondern Kontrollstrukturen werden (jedenfalls augenscheinlich - die Maschine optimiert das in der Regel) direkt in Smalltalk realisiert:

Code: Alles auswählen

a < 10 ifTrue: [stmt1...] ifFalse: [stmt2...]

Dem Objekt in der Variable "a" (sagen wir, eine 5) wird die binäre Nachricht "<" mit dem Argument 10 geschickt. Ergebnis ist das Objekt true (Exemplar der Klasse True) oder false (Exemplar der Klasse False) - in meinem Fall natürlich true - und dem Objekt wird die Nachricht ifTrue:ifFalse: (ja, das ist eine Nachricht!) mit zwei Codeblöcken als Argumente geschickt. Hier sind die Definitionen:

Code: Alles auswählen

True ifTrue: aBlock ifFalse: anotherBlock
  ^aBlock value

False ifTrue: aBlock ifFalse: anotherBlock
  ^anotherBlock value

Auch der Block in [...] ist ein Objekt und versteht die Nachricht "value", wenn er sich auswerten soll.

Die Syntax von Io versucht noch uniformer zu sein als die von Smalltalk, da es nur eine Art von Nachrichtenausdruck gibt - ganz traditionell folgt dem Namen die Liste der Argumente in Klammern. Ohne Argumente kann man die Klammern auch weglassen. Außerdem sind auch Zuweisungen Nachrichten, ein Konzept, was Smalltalk wieder fallen gelassen hat.

Im Gegensatz zu Scheme, wo ("call by value") alle Argumente ausgewertet werden, bevor eine Funktion aufgerufen wird, funktioniert Io hier anders: Nur die ersten N Ausdrücke an Argument-Position werden ausgewertet, beim Rest wird ("call by name") die Nachricht selbst übergeben. Im Prinzip hat man dadurch wieder die Special-Forms von Scheme, kann sie aber meist in Io definieren, weil man über die pseudo-Variable "call" immer an den aktuellen Kontext herankommt (Smalltalk nennt dies "thisContext", eine Pseudovariable, die man dort fast nie braucht und die auch nicht alle Smalltalk-Dialekte zur Verfügung stellen). Die "=" und ":=" werden zudem als Makros aufgefasst und e1 symbol := e2 wird durch e1 setSlot("symbol", e2) und bei "=" durch updateSlot ersetzt. Das e1 kann fehlen, dann wird implizit das aktuelle "locals"-Objekt als Empfänger benutzt. Tatsächlich sagt die Doku, dass auch e symbol als Makro für e getSlot("symbol") aufzufassen ist, aber da beißt sich die Katze in den Schwanz, denn bitte was ist dann "e getSlot"?

Ich glaube, so könnte man das if von Io nachbauen (ist der selbe Trick wie bei Smalltalk, nur das ich ein spezielles "SkipFalse"-Objekt benutze statt einer einzelnen ifTrueIfFalse-Methode):

Code: Alles auswählen

if(a < 10, stmt1..., stmt2...)

if := method(cond,
  cond ifTrue(call evalArgAt(1)) ifFalse(call evalArgAt(2))
)
true ifTrue := method(SkipFalse clone value := call evalArgAt(0))
true ifFalse := method(false)
false ifFalse := method(call evalArg(0))
SkipFalse = object clone
SkipFalse ifFalse := method(self value)

Jetzt habe ich mich aber um eine Antwort gedrückt, warum Python nicht wirklich objektorientiert ist. Ich glaube, ich war zu pauschal in meiner Aussage. Man kann mit Python objektorientiert programmieren, doch Python ist vom Kern eine imperative Programmiersprache mit Anleihen aus der objektorientierten und funktionalen Programmierung. Vielleicht macht das den Erfolg aus (ich glaube ja, Multiparadigmen-Sprachen sind die mächtigsten, allerdings braucht es Entwickler die alle diese Paradigmen kennen) aber Python folgt nicht konsequent dieser Idee. Das print-Statement ist kein Objekt. Klassen wirken nachträglich aufgesetzt und die Implementierung von Methoden als Funktionen scheint komplett durch. Daher folgen die wenigsten Python-Programmierer und Python-Programme der ursprünglichen Idee sondern sind ein Konglomerat aus Konzepten. Gut für die Praxis, weniger gut für's Lernen.

Ansonsten hast du Recht, auf unbekannte Nachrichten reagieren zu können ist ein mächtiges Konzept, was nur wenige Sprachen (Ruby kann's übrigens auch) beherrschen. Nachrichten bei Smalltalk sind (im Gegensatz zu Io) übrigens immer synchron. Daher sagte ich ja, Erlang trifft die ursprüngliche Idee fast noch besser...

PS: Es heißt Smalltalk, nicht SmallTalk ;)

Stefan

[BlackJack]

Das die Sprache keine Schlüsselworte hat, man aber trotzdem die üblichen Kontrollstrukturen hat, diese also mit dem Kern ohne Schlüsselworte implementieren kann, ist schon *ein* Kriterium was man IMHO für die Einfachheit des Sprachkerns bei gleichzeitiger Mächtigkeit, heran ziehen kann.

Auch wenn ``if``/``ifTrue:ifFalse:`` bei Smalltalk und Io im Gegensatz zu Scheme nicht als besondere Syntax behandelt wird muss man trotzdem lernen, dass es etwas besonderes ist, weil die Argumente nicht unbedingt ausgewertet werden.

Bei der Syntax von Io gibt's mehr als eine Art von Nachrichten. Operatoren werden gesondert behandelt, damit ``a + b * c`` das aus der Mathematik bekannte Ergebnis liefert und nicht stur von links nach rechts als ``(a + b) * c`` interpretiert wird.

Eine Vereinfachung der Sprache von Io gegenüber Smalltalk hast Du nicht erwähnt: in Io gibt es vom Sprachkern her keine Klassen, sondern nur Objekte. Eine Sonderstellung von Objekten als "Klassen" gibt sich nur aus der Namenskonvention die "Vorlagen" mit "CamelCase"-Namen zu versehen.

Trotzdem verstehe ich den Einwand gegen Python nicht ganz. Für mich sind OO und imperativ/funktionial orthogonale Konzepte. Weil Python eher imperativ daherkommt, während sich Io sehr funktional anfühlt, sind beide trotzdem für mich sehr objektorientierte Sprachen. ``print`` ist halt ein syntaktischer Sonderfall, der aus genau dem Grund ja auch in Python 3.0 durch eine Funktion abgelöst wird. Und dann ist ``print('hallo')`` eben die Nachricht ``print``, die an das `__builtins__`-Objekt geschickt wird, was mit einem Funktionsobjekt antwortet, dem dann wiederum an den `__call__`-Slot eine Nachricht mit dem Argument 'hallo', einem Zeichenkettenobjekt, geschickt wird. Das Funktionsobjekt schickt dann dem `sys`-Modul-Objekt die Nachricht `stdout` und bekommt ein File-Objekt als Antwort dem dann… usw. Also letztendlich nichts anderes als `writeln()` in Io. Ein Haufen Objekte, die miteinander kommunizieren.

In Io folgen die Programmierer letzendlich auch nicht den ursprünglichen Konzepten sondern programmieren mit den entsprechenden Methoden ebenfalls in einer Mischung aus imperativ oder funktional. Eben weil das orthogonal zu OO ist.

PS: ``e getSlot`` ist natürlich ``e getSlot("getSlot")``.

[Leonidas]

Das print-Statement ist kein Objekt.

Das stimmt und nicht nur dir hat das nicht gefallen, sondern auch den Machern von Python. Daher ist ``print`` in den Python 3.0 alphas bereits eine Funktion und somit ein Objekt. Und Python hat ein Schlüsselwort weniger.