letzter Beitrag von Mike am
Weil kein Programm mit Benutzer-Interaktion heute noch so funktioniert.
Linear ablaufende Programme gibt es eigentlich nur noch bei automatisch ablaufenden Scripten.
(Hobby-)Programmierung im Laufe der Jahrzehnte (u. a. Schwierigkeiten beim Umstieg auf Event-gesteuerte Fenstersysteme ab Minute 17):
In der Basic-Ecke sollte man eigentlich nicht diskutieren, ob man Basic programmiert oder nicht, das ist complett OT.
Das hat nartürlich was für sich. 
Um wieviel kb wäre das BASIC ROM im 64er größer wenn man kein GOTO/GOSUB sondern andere Techniken zur Programmsteuerung verwendet hätte?
Und um wieviel wäre ein Rechner teurer geworden? Ein BASIC für 8-Bit Rechner ohne GOTO/GOSUB, wäre es langsamer, gleich schnell oder schneller
gewesen?
Ich vermute einmal, nicht so wesentlich langsamer, denn die FOR-Schleife ist ja schon recht komplex, und beinhaltet kein GOTO. Warum ist sie trotzdem schneller als wenn man sie in BASIC emuliert? Weil sie eben auf Maschinensprache-Ebene implementiert ist. OK, das ist jetzt vielleicht ein Schuss in den Ofen, denn man müsste erst einmal untersuchen, was schneller ist, aber ich tippe auf die FOR-Schleife.
Nehmen wir an, man will in BASIC sowas wie structs und unions und pointer nachbilden. Die könnte man in V2-BASIC auf zwei Arten nachbilden:
Beides würde einen Overhead erzeugen. Lösung 2 wäre wohl schneller, aber von der Speicherverwaltung unpraktischer, Lösung 1 wäre dafür entsetzlich langsam. In beiden Fällen wäre eine Erweiterungs-Lösung wesentlich schneller.
Oder Flusskontroll-Mechanismen: Neben der FOR-Schleife eine WHILE-Schleife oder DO-WHILE-Schleife, oder so eine FOR-Schleife wie in C. Wären die schneller? Kommt drauf an, wie man sie implementiert. GOTO sucht nach der Zeilennummer, das ist recht langsam. Andererseits müssten schnelle, statische Lösungen zumindest teilcompiliert werden, damit Sprünge nicht in Suchen nach Labels oder Zeilennummern ausarten. Oder man ändert den BASIC-Interpreter so, dass er das Programm in einem gewichteten binären Baum enthält, dann wäre der Aufwand nur mehr logarithmisch. Aber alles das würde natürlich nicht nur den Editor selbst verlangsamen (das wäre noch aushaltbar), sondern zusätzlichen Speicher brauchen, und da haben wir über den Bedarf für den Interpreter selbst noch gar nicht geredet.
Ähnliches gilt für parametrisierte Unterprogramme (Prozeduren oder Funktionen, wie man sie halt nennen will). Da könnte man allerdings zu einem Trick greifen, und einfach einen zusätzlichen Software-Stack definieren, auf dem man Parameter übergeben kann. Das wäre dann natürlich ein Zusatz-Aufwand, und langsamer, aber langsamer als was? Langsamer als die üblichen BASIC-Variablen natürlich, aber will man in einem BASIC-Programm heute einen Stack einbauen, muss man sowieso ein Array dafür definieren, und dann hat das noch dazu nur einen festgelegten Typ, und das wäre noch viel langsamer und braucht mehr Programm-Code.
Ich liebe es ja, in solchen was-wäre-wenns zu schwelgen, aber obs so stimmt? Hmja ich denke, das wäre teurer gewesen. Wobei .. OK, FORTH wäre wohl billiger geworden, aber für Anfänger extrem schwer zu lernen.
Weil kein Programm mit Benutzer-Interaktion heute noch so funktioniert.
Linear ablaufende Programme gibt es eigentlich nur noch bei automatisch ablaufenden Scripten.
(Hobby-)Programmierung im Laufe der Jahrzehnte (u. a. Schwierigkeiten beim Umstieg auf Event-gesteuerte Fenstersysteme ab Minute 17):
Der Typ ist etwas anstrengend. Ich kann dem nicht über einen längeren Zeitraum zuhören. 
Aber ab Minute 17, das ist genau das, was ich meinte. Und es wird ja auch in dem Video gesagt, dass das die Programmierung komplett verändert hat.
Seit dem spaltet sich die Welt in Script-Programmierer und UI-Programmierer.
Ich liebe es ja, in solchen was-wäre-wenns zu schwelgen, aber obs so stimmt? Hmja ich denke, das wäre teurer gewesen. Wobei ..
Ja, das wäre alles schön gewesen. Nur macht das auf 8 Bit Systeme mit dem eingeschränkten Speicher alles keinen Spaß.
Denn das nimmt mir Platz weg, den ich eigentlich für mein Programm benötige. Und es spart in meinem Programm nicht sowie Platz ein, dass sich das wieder ausgleicht. Denn eine WHILE-Schleider braucht im Basic-Programm nicht weniger Platz als ein IF/GOTO oder eine FOR-Schleife.
Später gab es ja von Microsoft die Basic-Versionen, die das alles konnen (von GWBASIC bis QuickBasic). Auf dem 16-Bit-Systemen, wo es ausreichend Speicher gab.
Ich glaube, ich habe ein Deja Vu....
Ich liebe es ja, in solchen was-wäre-wenns zu schwelgen, aber obs so stimmt? Hmja ich denke, das wäre teurer gewesen. Wobei ..
Ja, das wäre alles schön gewesen. Nur macht das auf 8 Bit Systeme mit dem eingeschränkten Speicher alles keinen Spaß.
Denn das nimmt mir Platz weg, den ich eigentlich für mein Programm benötige. Und es spart in meinem Programm nicht sowie Platz ein, dass sich das wieder ausgleicht. Denn eine WHILE-Schleider braucht im Basic-Programm nicht weniger Platz als ein IF/GOTO oder eine FOR-Schleife.
Später gab es ja von Microsoft die Basic-Versionen, die das alles konnen (von GWBASIC bis QuickBasic). Auf dem 16-Bit-Systemen, wo es ausreichend Speicher gab.
Ja, das scheint mir auf jeden Fall plausibel. Zumindest, soweit es BASIC betrifft.
Weils die Debatte eine gefühlte Million Mal schon gegeben hat? Vermutlich. Macht aber Spaß!
Ich glaube, ich habe ein Deja Vu....
Weils die Debatte eine gefühlte Million Mal schon gegeben hat? Vermutlich. Macht aber Spaß!
Natürlich macht das Spaß, sonst würde man es nicht tun. Genau wie viele andere Themen, die sich regelmässig wiederholen. Mindest einmal pro Jahr braucht es so eine Diskussion. 
Später gab es ja von Microsoft die Basic-Versionen, die das alles konnen (von GWBASIC bis QuickBasic). Auf dem 16-Bit-Systemen, wo es ausreichend Speicher gab.
Kann der C128 aber auch...
Später gab es ja von Microsoft die Basic-Versionen, die das alles konnen (von GWBASIC bis QuickBasic). Auf dem 16-Bit-Systemen, wo es ausreichend Speicher gab.
Kann der C128 aber auch...
Ja, stimmt. Der hat aber eben auch schon 128K RAM. Und alleine das Basic 7 ist 32K groß. Ohne System und Editor.
Wenn ich mir überlege, könnte man sich viele Diskussionen ersparen, wenn man BASIC einfach zu den Scriptsprachen zählen würde (oder tut man das bereits?) und nicht zu den Programmiersprachen.
Scriptsprachen sind für kleinere Sachen gedacht und deshalb ist Geschwindigkeit auch nicht so relevant. Wer ein Spiel mit einer Scriptsprache entwickeln will, der hat dann halt einfach die falsche Sprache gewählt. Stattdessen hätte man eine Programmiersprache, die nicht interpretiert werden muss, verwenden sollen.
Wer sich also fragt, warum das C64 BASIC langsam ist, hat vielleicht eine falsche Vorstellung für was BASIC bzw. Eine Scriptsprache eigentlich gedacht ist.
Und ich finde nach wie vor, dass auch mit BASIC V2 das Verhalten einer Scriptsprache gut nachvollzogen werden kann.
Ja, stimmt. Der hat aber eben auch schon 128K RAM. Und alleine das Basic 7 ist 32K groß. Ohne System und Editor.
Klar ist da mehr ROM. Das ist aber nicht der Punkt. Hat nicht Simons Basic auch Elemente zur strukturierten Programmierung? Oder TSB?
Es ist also nicht der Speicher und nicht die 8-Bit Architektur und darauf bezog sich mein Kommentar eigentlich:
[...] Auf dem 16-Bit-Systemen...
Es braucht keine 16 Bit. 
Wenn ich mir überlege, könnte man sich viele Diskussionen ersparen, wenn man BASIC einfach zu den Scriptsprachen zählen würde (oder tut man das bereits?) und nicht zu den Programmiersprachen.
Vielleicht sollte man einfach nicht (alte) Interpreter-Sprachen mit (neuen) Compiler-Sprachen in einen Topf schmeißen. 
Alles anzeigen
Mir brauchst du das nicht erzählen, ich arbeite in der Branche und gebe auch Nachhilfe für Leute die von Null anfangen und weiß was die verwirrt und was eher nicht. Wäre heute noch BASIC aktuell in der Form von früher würde ich denen dringend davon abraten auch nur eine Zeile Code damit zu schreiben. Der Schaden ist größer als der Nutzen.
Was verwendest du denn, um den Leuten programmieren beizubringen? Ich tue mich schwer damit, da heute was zu finden, das einerseits einfach zugänglich aber andererseits nicht völlig runtergedummt ist. Viele moderne Sprachen haben Komplexitätsebene auf Komplexitätsebene gestapelt und sind daher für den Einstieg meiner Ansicht nach nicht geeignet (I'm looking at you, Javascript...). Meine Kinder machen in der Schule Scratch (und sowas ähnliches, wovon ich den Namen vergessen habe), privat etwas Python (das finde ich noch am Besten für den Anfang) und etwas Java (wegen Minecraft). Zumindest der Große kann aber auch etwas BASIC auf dem 64er, das ließ sich nicht vermeiden...
Die Frage ist doch, welche Erwartungshaltung die Person hat, die programmieren lernen möchte. Möchte sie nur mal reinschnuppern, dann tut vielleicht ein einfaches Java-Programm oder zu Not auch Basic. Ob so jemand sich dann jemals wieder mit Programmieren beschäftigt, halte ich für fraglich.
Meine Tochter (11 Klasse Oberstufe) wollte Windows-Programme schreiben. Als erstes ein Programm zu Verwaltung ihrer Bücher.
Da kann ich nicht mit Konsolenprogrammierung anfangen und ihr erklären, dass sie dann vielleicht in ein paar Monaten soweit ist, wenn sie die Grundlagen begriffen hat.
Also sind wir direkt mit C# in die UI-Programmierung eingestiegen. Und natürlich zwangsläufig auch geich in die objektorientierte Programmierung.
Bei jedem anderen Vorgehen wäre die Motivation nach ein paar Tagen weg gewesen. Aber so gab es jeden Tag neue Erfolgserlebnisse. Textfelder, die sich auf Mausklicks hin füllen oder Fenster die sich öffnen. Und alles was man erklärt, hat sofort einen praktischen Bezug, weil man genau das erklärt, was gerade gebraucht wird. Also nicht "Wir lernen heute die for-Schleife" sondern "Wir programmieren heute die Suchfunktion".
Man darf den Motivationsfaktor nicht außer acht lassen. Ein paar Konsolenausgaben motivieren nicht jeden.
Die Programmiersprache selbst ist übrigens ziemlich nebensächlich. Ob Java oder Python oder C# oder Visual Basic. Entscheidend sind die Programmierkonzepte.
Meine Nachhilfe richtet sich an Umschüler die Fachinformatiker werden. Dort machen wir dann Python und Java. Python ist leider auch so ein zweischneidiges Schwert, auf er einen Seite unheimlich beliebt, auf der anderen Seite von Syntax doch sehr fremd zu den anderen C-ähnlichen Sprachen. Und ich mag eigentlich keine schwache Typisierung bei Datentypen.
Klar ist da mehr ROM. Das ist aber nicht der Punkt. Hat nicht Simons Basic auch Elemente zur strukturierten Programmierung? Oder TSB?
Es ist also nicht der Speicher und nicht die 8-Bit Architektur und darauf bezog sich mein Kommentar eigentlich:
[...] Auf dem 16-Bit-Systemen...
Es braucht keine 16 Bit.
Ja, korrekt. Es ging mir auch gar nicht um die 8 oder 16 Bit sondern einfach um die üblichen Limitierungen, die 8 Bit Systeme mit sich bringen.
Natürlich kann ich auch ein 8 Bit System auch mehrere Megabyte aufrüsten. Macht aber keinen Sinn.
Meine Nachhilfe richtet sich an Umschüler die Fachinformatiker werden. Dort machen wir dann Python und Java. Python ist leider auch so ein zweischneidiges Schwert, auf er einen Seite unheimlich beliebt, auf der anderen Seite von Syntax doch sehr fremd zu den anderen C-ähnlichen Sprachen. Und ich mag eigentlich keine schwache Typisierung bei Datentypen.
Ok, die haben natürlich auch eine ganz andere Motivation (oder eben auch keine). Da muss man wohl ganz anders rangehen, als wenn meine Tochter vor mir steht und sagt, sie will das jetzt gerne machen. Ausserdem hast du ja als Nachhilfelehrer keinen Einfluss auf den Lernstoff.
Ich persönlich mag Python überhaupt nicht, weil da die Formatierung Teil der Syntax ist. Ich dachte eigentlich, dass ich mich von sowas beim Wechsel von Basic 2 auf C und Pascal befreit hätte. Aber das ist wieder ein eigenes Thema und dazu gab es auch schon mal einen eigenen Thread.
Ich bin kein offizieller Lehrer, sondern habe das nur die letzten Monate nebenher gemacht für lau um selbst mal Erfahrung zu sammeln. Um eben mal vor Menschen zu sprechen, mit Beamer + PC dran und einer Tafel und denen dann versuchen die eigene Leidenschaft näher zu bringen.
Ja, die erzwungenen Einrückungen bei Python mag ich auch nicht oder wie dort Klassen rangeflanscht wurden usw. Aber die Sprache ist leider immer beliebter in den letzten Jahren geworden, wenn es mal schnell ums Scripten gehen soll.
Ich gehe hingegen beruflich gerade in die C++ Richtung, bin aber weit davon entfernt da ein Experte zu sein. Die Sprache ist soo umfangreich und ich habe schon Jahre gebraucht um überhaupt damit klar zu kommen.
Wenn ich mir überlege, könnte man sich viele Diskussionen ersparen, wenn man BASIC einfach zu den Scriptsprachen zählen würde (oder tut man das bereits?) und nicht zu den Programmiersprachen.
Der Gedanke ist ein ziemlich guter, aus meiner Sicht, und er stimmt auch insofern völlig, als man auf diesen Systemen eben auch eine Scriptsprache gebraucht hat, und da zunächst (in den 70ern bei fast nur unter 16k-Systemen) nur eine Platz gehabt hat, hat BASIC gut in diese Rolle gepasst.
Ja, korrekt. Es ging mir auch gar nicht um die 8 oder 16 Bit sondern einfach um die üblichen Limitierungen, die 8 Bit Systeme mit sich bringen.
Natürlich kann ich auch ein 8 Bit System auch mehrere Megabyte aufrüsten. Macht aber keinen Sinn.
Ja, eben die frühen Home-Computer. Auf dem C64 gabs schon ziemlich gute Pascal-Implementierungen (Oxford, Profi) und C und weiteres, aber auf einem Apple II oder einem VC20 ist daran nicht zu denken gewesen. Ich denke, die Sprachtauglichkeit wächst wirklich mit dem Speicher, nicht so sehr mit der CPU.
Ich persönlich mag Python überhaupt nicht, weil da die Formatierung Teil der Syntax ist. Ich dachte eigentlich, dass ich mich von sowas beim Wechsel von Basic 2 auf C und Pascal befreit hätte. Aber das ist wieder ein eigenes Thema und dazu gab es auch schon mal einen eigenen Thread.
Entweder man liebt es, oder man hasst es. Guido van Rossum hat das und vieles mehr von ABC abgeschaut.
Ich gehe hingegen beruflich gerade in die C++ Richtung, bin aber weit davon entfernt da ein Experte zu sein. Die Sprache ist soo umfangreich und ich habe schon Jahre gebraucht um überhaupt damit klar zu kommen.
Ich halt mich nicht gerade für einen ausgesprochenen Trottel, aber das tu ich mir nicht mehr an, weil ich mir diese Details alle nicht mehr merke. Ist mir einfach zuviel.
Wenn ich mir überlege, könnte man sich viele Diskussionen ersparen, wenn man BASIC einfach zu den Scriptsprachen zählen würde (oder tut man das bereits?) und nicht zu den Programmiersprachen.
Inwiefern unterscheidet sich eine Scriptsprache von einer Programmiersprache?
Hat nicht Simons Basic auch Elemente zur strukturierten Programmierung? Oder TSB?
TSB: Nur scheinbar. Zwar arbeiten CALL und EXEC mit Labels (definiert bei PROC), aber es gibt keine Kapselung der Prozeduren, keine Parameterübergabe und keine Ergebnisrückgabe, alles weiterhin global. Praktisch GOTO und GOSUB unter anderem Namen. Immerhin sind Zeilennummern da nur noch "Ordnungshilfen". 
Arndt
