letzter Beitrag von Tale-X am
einer der Schöpfer von einer der bekanntesten Einsteiger-Computersprachen der Welt
Naja, nun ist Basic trotz Einsteigerfreundlichkeit ja nicht unbedingt als ein Juwel unter den Computersprachen bekannt, daher würde ich seine Meinung nicht in purstem Gold aufwiegen 
Einer der Mit-Schöpfer des Ur-Microsoft-BASIC, Monte Davidoff, ... Also, wenn schon einer der Schöpfer von einer der bekanntesten Einsteiger-Computersprachen der Welt
Soll das heissen, dass BASIC von Microsoft erfunden wurde?
Nein, MS hatte höchstens paar Basicinterpreter entwickelt und war mit denen sehr erfolgreich. Naja, da damals fast jedes System sein eigenes Basic hatte, kann man sagen, MS hatte auch paar Basicvarianten entwickelt.
Sein sachbezogenes Hauptkriterium für die Überlegenheit von Python scheint die Objektorientierung zu sein.
Ja, im Vergleich zu Basic (da ist fast jede andere Sprache ein Vorteil), aber doch noch im Vergleich zu anderen objektorientierten Sprachen.
Und Basic als ideale Lehrsprache... 
@detlef zumindest war es anfangs soweit ich weiss ausschliesslich als Lehrsprache GEDACHT. Also gar nicht mal fuer den produktiven Einsatz vorgesehen. Und um Ablaeufe eines Computers zu erklaeren, ist BASIC tatsaechlich nicht schlecht. Zumal es 1964 entwickelt wurde, da sah die Welt einfach noch anders aus.
Aus heutiger Sicht verstehe ich zwar Deine Meinung, dass BASIC nicht unbedingt die ideale Lehrsprache ist, aber betrachtet man es mal historisch und nicht unbedingt unter dem Aspekt dass man mit dieser Sprache dann auch produktiv arbeiten koennen soll, dann ist nichts schlimmes dabei, die Worte "BASIC" und "Lehrsprache" im gleichen satz zu verwenden (ja, auch wenn kein "...ist keine gute..." dazwischen steht 
).
Und um Ablaeufe eines Computers zu erklaeren, ist BASIC tatsaechlich nicht schlecht. Zumal es 1964 entwickelt wurde, da sah die Welt einfach noch anders aus.
Aber Monte Davidoff hat die Meinung (Basic als ideale Lerhsprache) ja anscheinend 2001 noch vertreten. Und das kann ich nicht nachvollziehen.
Um Abläufe im Computer zu verstehen, ist eigentlich Assembler am besten geeignet. Aber stimmt schon, ich habe ja auch mit Basic angefangen, weil es damals nichts anderes gab für zuhause. Und habe mir deshalb mit dem Umstieg auf echte objektorientierte Programmierung sehr schwer getan. Besser man startet gleich objektorientiert.
Meine Kinder haben in der Schule Projekte mit "Scratch" programmiert. Das ist wenigstens objektorientiert - wenn auch rudiementär.
Naja aber es gehoert auch ziemlich viel dazu, Objektorientierung direkt zu begreifen. Ich glaube, da fehlt einem zum Teil schon das Vorwissen, um ueberhaupt dann zu begreifen, warum man eigentlich objektorientiert programmiert usw. Klar, ich kann es auch nur aus der Sicht eines jenigen betrachten, der ebenfalls mit BASIC angefangen hatte und sich beim Umstieg auf OOP schwer tat. Aber ob ich das von Anfang an begreifen wuerde, weiss ich trotzdem nicht. Manchmal muss man ja auch erst die Problematik verstehen, um mit der Loesung dann ueberhaupt etwas anfangen zu koennen.
Auch denke ich nicht, dass eine Sprache 100% objektorientiert sein muss, so wie bei Java. Das macht es fuer den Einstieg auch nur unnoetig kompliziert. Auch deshalb mag ich Python, weil man es so nutzen kann oder auch nicht. Das trifft natuerlich auch auf viele andere Sprachen zu, klar.
Was die Ablaeufe im Computer angeht. Natuerlich koennte man dann auch mit Assembler anfangen. Aber so weit weg ist das C64 BASIC auch nicht von Assembler, wenn man es sich mal genau ueberlegt. Man muss doch staendig per POKE was erledigen und es gibt GOTOs. Um generell zu zeigen, wie ein einfaches Programm aufgebaut ist und wie die Befehle der Reihe nach abgearbeitet werden, finde ich BASIC jetzt nicht komplett verkehrt. Das Problem liegt halt eher daran, wenn dann zu viel in BASIC gemacht wird und man irgendwann zu "hoeheren" BASICs a la Visual Basic (vor der .NET-Zeit) usw wechselt, und somit also wirklich das tut, was nie vorgesehen war, naemlich BASIC fuer den produktiven Einsatz zu verwenden. Denn dann gewoehnen sich die Einsteiger an diese Sprache und loesen auch komplexere Probleme damit, wofuer die Sprache dann halt eben doch nicht geschaffen ist. Bei einer Sprache wie "Scratch" hingegen ist klar, dass das eine reine Lernsprache ist, und dass man irgendwann auf was "richtiges" umsteigen wird.
Lässt sich sowas wie der Basic-Direktmodus überhaupt mit dem Sprachkonzept von Python vereinbaren?
Python hat einen Direktmodus schon eingebaut. Den benutze ich immer als Taschenrechner.
LOL das mache ich auch oft 
Aber Monte Davidoff hat die Meinung (Basic als ideale Lerhsprache) ja anscheinend 2001 noch vertreten. Und das kann ich nicht nachvollziehen.
Um Abläufe im Computer zu verstehen, ist eigentlich Assembler am besten geeignet. Aber stimmt schon, ich habe ja auch mit Basic angefangen, weil es damals nichts anderes gab für zuhause. Und habe mir deshalb mit dem Umstieg auf echte objektorientierte Programmierung sehr schwer getan. Besser man startet gleich objektorientiert.
Meine Kinder haben in der Schule Projekte mit "Scratch" programmiert. Das ist wenigstens objektorientiert - wenn auch rudiementär.
Wie bitte !?
Im Artikel von 2001 steht klar und deutlich, dass er Python für die ideale Lehrsprache hält.
Der sinngemäße Zusatz "als diese galt früher Basic" stammt von der Redaktion und war (für mich) erkennbar uneigentliches Sprechen, also Ironie oder Süffisanz.
Es steht da nach den Schließenden Anführungsstrichen
That used to be BASIC, of course.
Used to be == Das war einmal! (Vergangenheitsform)
Wie du darauf kommst, dies als Behauptung Herrn Davidoff in die Schuhe zu schieben, ist mir schleierhaft. 
Klar, ich kann es auch nur aus der Sicht eines jenigen betrachten, der ebenfalls mit BASIC angefangen hatte und sich beim Umstieg auf OOP schwer tat.
Nachdem ich bis jetzt keine Software-Projekte hatte, wo mehr als einer gleichzeitig daran arbeitete, war für mich OOP eigentlich immer Overkill.
Aber vermutlich habe ich es auch nie verstanden, wozu man etwas OO programmiert.
Für mich persönlich ist es dann sinnvoll, wenn
a) mehrere Leute daran arbeiten und der Code durch definierte Schnittstellen robuster wird oder
b) man ein umfangreiches Programm robust und sicher gestalten will.
Für kleine Programme und Problemlösungen oder Tools halte ich es für Overkill.
Aber wie gesagt, vielleicht habe ich den Ansatz in all seiner glorreichen Ganzheit einfach nicht verstanden.
Die Verkapselung, die man durch OOP erhält, ist m.E. vor allem für komplexere Programme nützlich, wo man auch als Einzelprogrammierer nicht mehr alles im Kopf hat. Auch das "Lesen" von unbekanntem (oder vergessenem eigenen) Quellcode wird dadurch einfacher. Und die klaren Schnittstellen erlauben einfacheres Testen und Refactoring, aber die kann man natürlich auch ohne OOP bekommen. Nicht zuletzt zwingt einen die Denkweise zu möglicherweise besserer Softwarearchitektur.
Ich schreibe aber kleine Tools auch konsequent in C statt Java, obwohl ich in beiden wohl etwa gleich fit bin 
.
Ein wesentlicher Vorteil ist natuerlich auch noch die Vererbung, denn damit lassen sich verschiedene Objekte gleich behandeln, z.B. kann ich in einem Spiel ein Objekt "Spieler" machen und ein Objekt "Gegner", die beide jedoch gleiche "Wurzeln" haben. Somit kann ich z.B. beide in die gleiche Liste werfen und beim Durchwandern der Liste diejenigen Methoden aufrufen, die beide Objekte besitzen, ohne dabei erst unterscheiden zu muessen, um welches Objekt es sich genau handelt.
Grundsaetzllich sollte man auch noch erwaehnen, dass man auch gewissermassen in jeder Sprache objektorientiert programmieren kann, da die Sprache dies nicht zwingend in Form von Keywords usw. unterstuetzen muss. Allerdings wuerde ich sagen, ist das dann meist mehr eine "Objektorientierung Light". Aber moeglich ist es, und sinnvoll in einigen Faellen ebenfalls.
Für kleine Programme und Problemlösungen oder Tools halte ich es für Overkill.
Aber wie gesagt, vielleicht habe ich den Ansatz in all seiner glorreichen Ganzheit einfach nicht verstanden.
Eine gewagte These für jemanden, der wie du selbst zugibt, OOP vermutlich gar nicht verstanden. 
OOP ist einfach ein ganz anderer Ansatz und wenn man es verstanden hat, verwendet man es unabhängig von der Komplexität des Projektes. Man will dann einfach nicht mehr prozedural programmieren.
OOP ist auch kein Overkill. OOP-Programme sind in der Regel sehr performant, weil Objekte (z.B. bei der Paramterübergabe) immer referenziert und nicht kopiert werden.
Aber das ist eben genau das Problem mit Basic. Es ist ganz schwer einem Basic-Programmierer im nachhinein OOP nahezubringen. Weil er sich gar nicht vorstellen kann, dass man auch anders als prozedural programmieren kann.
Grundsaetzllich sollte man auch noch erwaehnen, dass man auch gewissermassen in jeder Sprache objektorientiert programmieren kann, da die Sprache dies nicht zwingend in Form von Keywords usw. unterstuetzen muss.
Wie soll das gehen? Wie definiere ich Klassen mit Methoden und Eigenschaften? Wie instanziere ich die? Wie übergebe ich Objekt-Instanzen?
Alles was du ohne Instanzierung simulieren könntest, wären statische Klassen. Genau die versucht man in OOP aber eigentlich zu vermeiden. 
Wie du darauf kommst, dies als Behauptung Herrn Davidoff in die Schuhe zu schieben, ist mir schleierhaft.
Sorry, hatte ich falsch gelesen bzw. interpretiert. 
Wie soll das gehen? Wie definiere ich Objekte mit Methoden und Eigenschaften?
Beispielsweise mit Datenstrukturen und Funktionspointern/-referenzen
ZitatWie instanziere ich die?
Speicher anlegen und geeignet füllen
ZitatWie übergebe ich Objekt-Instanzen?
Pointer bzw. Referenzen
ZitatAlles was du ohne Instanzierung simulieren könntest, wären statische Klassen. Genau die versucht man in OOP aber eigentlich zu vermeiden.
Tip: Objektorientierter Code wird irgendwann auch mal ausgeführt und abgesehen von einigen gescheiterten Experimenten wie zB Intels 432 weiss die CPU meist nichts von OOP.
Aber ob ich das von Anfang an begreifen wuerde, weiss ich trotzdem nicht. Manchmal muss man ja auch erst die Problematik verstehen, um mit der Loesung dann ueberhaupt etwas anfangen zu koennen.
Dafür gibt es z.B. Scratch. Da hat man 2D-Grafikobjekte, mit Eigentschaften wie Richtung, Geschwindigkeit, Farbe usw. Und die die Grafikobjekte haben Methoden, weil jedes Grafikobjekt eine eigene Klasse ist. Und man kann Instazieren (also man kann mehrere Objekte der gleichen Klasse haben). Damit lernt die Kids das ganz spielerisch und völlg selbstverständlich.
Wie soll das gehen? Wie definiere ich Objekte mit Methoden und Eigenschaften? Wie instanziere ich die? Wie übergebe ich Objekt-Instanzen?
Schon mal was von 'C with classes' gehört?
Hint: Das ist der C++ Vorläufer, damals als Übersetzer von C++ nach C implementiert... Der hat tatsächlich aus einem objektorientierten Programm (C++ Vorläufer) ein reines C-Programm gemacht.
Leider ist jener Übersetzer unauffindbar - ich habe ihn jedenfalls nicht finden können.
Aber vom Prinzip kann man so etwas natürlich auch per Hand machen. Und schon hat man ein objektorientiertes Programm in C, also in einer nicht objektorientierten Sprache.
Objekt-Orientiert geht mit C genauso, wie C++ es unter der Hand macht: Man reicht in jede Funktion einen Pointer auf die Instanz rein:
Pseudo-Code:
FREEIMAGE* fr = frCreate();
IMAGE* img = frLoadImage( fr, "meinpfad.png" );
frCropImage( img, 640, 480 );
Wo du das mit dem "Werden immer referenziert" herhast, keine Ahnung. Ist Quatsch. Lässt sich in jeder besseren Sprache so oder so regeln (& vs. ref vs. direkt)
Und teilweise ist objekt-orientiert nicht optimal, den Prozessor-Cache trickst man dabei leider öfter mal aus, wenn man z.Bsp. über Container iteriert.
Wie immer: Das richtige Werkzeug für den richtigen Zweck. Objekt-Obsessiv hatten wir schon, siehe Java. Prächtiger Clusterfuck.
