F64Summer -- neuer Checksummer zum Abtippen von BASIC Zeilen

Wer Bedenken hat, daß man Listings beim Abtippen verändert, kann sie ja mit selbstmodifizierenden Code schützen. Sobald ein REM nicht die richtige Länge hat, oder auch nur ein Doppelpunkt oder Leerzeichen fehlt, würde es dann abschmieren. Ein Checksummer, der diese Fälle ausklammert wäre dann allerdings nicht mehr für's Abtippen eines derartig geschützten Programms geeignet.

Zitat von LogicDeLuxe

Wer Bedenken hat, daß man Listings beim Abtippen verändert, kann sie ja mit selbstmodifizierenden Code schützen

Bei einem BASIC-Programm? Wer macht sowas?

Zitat von wizball6502

Zitat von LogicDeLuxe

Wer Bedenken hat, daß man Listings beim Abtippen verändert, kann sie ja mit selbstmodifizierenden Code schützen

Bei einem BASIC-Programm? Wer macht sowas?

Mir ist vor Urzeiten mal ein BASIC-Programm am C64 untergekommen, das hatte sich Daten aus den Kommentaren hinter dem REM-Befehl geholt (also eine Art "DATA-Ersatz"). Keine Ahnung, warum das der Autor damals so gemacht hat, aber auch hier wäre das Weglassen des REM-Kommentars ziemlich folgenreich gewesen.

Zitat von Snoopy

aber auch hier wäre das Weglassen des REM-Kommentars ziemlich folgenreich gewesen

Ja klar. Es gibt auch solche, die mit Hilfe des {Delete}-Charakters BASIC-Code verstecken, was sich auf die Checksumme auswirkt, aber man im Listing dann nicht mehr sieht.

Grundsätzlich geht es aber hier doch um klassische Abtipplistings für eine Zielgruppe, die ein BASIC-Programm erfolgreich abtippen können möchte. Da macht man solche verqueren Sachen nicht.

Meine Vorstellung von einem Checksummer ist, dass er genau eines macht und das möglichst gut:

Prüfen, ob eine Zeile auch genau so eingegeben worden ist, wie sie auf dem Papier vor einem liegt.

Alles andere geht für mich schon wieder in Richtung "wird unnötig kompliziert".

Snoopy Auch ohne Fettdruck und Unterstreichen, weiss ich, auf was ihr besteht: Ein Programm soll das machen, was von ihm erwartet wird. Punkt. Das hat zrs1 bereits erläutert mit dem Hinweis auf das "Principle of least surprise". Ich denke bei solchen Diskussionen immer ein wenig an Apple, die es schafft, die Endanwender-Sicht einzunehmen und nicht darauf beharrt, technisch logisch zu denken. Es geht ja darum, dass ein Mensch ein Listing Abtippen und am Schluss ein Hochgefühl seiner Abtipparbeit erleben möchte. Wie kann man es also schaffen, dass ein erwünschenswerter "Flow" also ein Glücksgefühl auch schon beim Abtippen eintritt? Entsteht der Flow dadurch, dass ich, wenn ich in einer Zeile ein Zeichen ändere und Return drücke, sich die Checksumme ändert? Oder eben die Checksumme möglichst schnell übereinstimmt und ich zur nächsten Zeile übergehen kann?

Prinzipien sind keine Gesetze und können je nach Anwendungsfall relativiert werden. Man könnte denn F64Summer mit diesem Zusatzfeature (REM-Kommentare haben keinen Einfluss auf Checksumme) auch genausogut gegenüber anderen Checksummern als "bessere Lösung" verkaufen, das auf die Bedürfnisse der 80%-Anwendungsfälle möglichst gut eingeht und nicht einfach versucht, logisch korrekt zu sein.

Zitat von wizball6502

Ich denke bei solchen Diskussionen immer ein wenig an Apple, die es schafft, die Endanwender-Sicht einzunehmen und nicht darauf beharrt, technisch logisch zu denken.

Bei Apple ist es meistens so, dass der Endanwender sich daran anpassen muss, wie Apple denkt, dass es Endanwender haben wollen.

Zitat von zrs1

Ich als Benutzer eines Checksummers wäre massiv verwirrt, wenn Änderungen in einem Kommentar sich nicht auf die Prüfsumme auswirken, das Weglassen aber schon -- daher ist das für mich keine Lösung.

Ich bin ja schon längst bei dir mit deinem Approach jetzt. Ich fände das auch total suboptimal, wenn man den Doppelpunkt oder das REM-Statement drin lassen müsste. Das war nur als - zugegebenermassen schlechten - Kompromiss gedacht, weil du das Programm ja möglichst kurz halten willst - was ich auch erstrebenswert finde.

Ok. Ich fasse abschliessend nochmals kurz Pro und Kontra für den Vorschlag zusammen, REM-Kommentare aus der Checksummenberechnung auszuschliessen:

PRO:

• Schreibfehler in REM-Kommentaren könnten von der Redaktion im letzten Moment noch korrigiert werden, ohne dass die Checksumme neu berechnet werden müsste. Andernfalls ist der Aufwand zu gross, etwas zu ändern. Schreibfehler machen aber keinen so guten Eindruck.
• REM-Kommentare könnten komplett ausgetauscht werden ohne Impact auf die Checksumme, z.B. Lokalisierung für ein anderes Sprachgebiet (das gilt dann aber nicht für Text in Strings)
• REM-Kommentare könnten vom Abtipper optional nur teilweise oder ganz weggelassen werden, ohne dass die Checksumme davon betroffen wäre. Durch das Weglassen wird Zeit beim Abtippen gespart und das Programm läuft dann auch etwas schneller
• Ein Hinweistext "REM-Statement hat keinen Einfluss auf die Checksumme und kann zugunsten der Performance weggelassen werden." könnte helfen, das unterschiedliche Verhalten des Checksummers zu erklären.
• Technisch vermutlich realisierbar.
• Das Checksummer-Tool würde mit diesem Feature um lediglich 23 Bytes bzw. Data-Werte länger (c64)

KONTRA:

• Nicht intuitives Verhalten. Es könnte den Eindruck erwecken, dass der Checksummer nicht richtig funktioniert
• Eine Funktion sollte sich erwartungsgemäß immer gleich Verhalten (Principle of least surprise)
• Unnötige Anforderung, weil REM-Statements in der selben Zeile wie Code nichts zu suchen haben. Sinnvoller ist es REM-Statements sparsam und in einer eigenen Zeile unterzubringen.
• Es scheint bisher niemand ein Problem damit zu haben, REM Statement eintippen zu müssen, um an die Checksumme zu gelangen. Auch waren in den bisherigen BASIC Weihnachten Listings eh nur ganz wenige REM-Statements vorhanden.
• Erforderliche Änderung nicht getestet, somit nicht bestätigt, dass es problemlos funktioniert und sich in allen Situationen richtig verhält. Nebeneffekte ungewiss.
• Selbstmodifizierender Code oder REM-Statements als DATA-Ersatz setzt eine exakte Abbildung des kompletten Listings voraus. Ohne korrekt erfassten REM-Statements würde das Programm nicht korrekt laufen.
• Das Checksummer-Tool würde mit diesem Feature um ganze 23 Bytes bzw. Data-Werte länger (c64)

Ich hoffe, ich habe da die wichtigsten Punkte berücksichtigt. Wie auch immer die Entscheidung schlussendlich ausfällt, danke ich für die faire Diskussion und Argumentationen. Und Danke an zrs1, dass du dir sogar die Mühe gemacht hast, die Logik probehalber einzubauen.

Ist es denn nicht so, das REM- Kommentare eher die Ausnahme sind und nicht in jeder Zeile vorkommen? Ist doch dann kein Problem, die befraglichen Zeilen mit fehlerhafter Summe (beim weglassen der Kommentare) noch mal zu überfliegen, FALLS das Programm dann nicht läuft? Wobei das ganze REM- Zeug wirklich in eigene Zeilen gehört, die man dann einfach weglassen kann.

Weil es hier immer um die Länge des Checksummers geht, warum eigentlich abtippen und nicht downloaden? Dann ist es egal wie gross er ist.

Zitat von zrs1

Zum "Retro-Feeling" gehört es IMHO auch, zuerst mal den Checksummer abzutippen.

Stimmt. Aber wolltest du beim F64Summer BASIC-Programm nicht noch zumindest ein Total über alle DATA-Werte (z.B. c=c+a+b) machen, damit man auch dort sicher sein kann, dass alle DATA-Zeilen korrekt eingegeben wurden?

Ich habe das hier (siehe folgendes F64Summer-Listing) mal so ergänzt, wobei die Rahmenfarbe noch auf rot gesetzt wird, wenn die Checksumme falsch ist bzw. grün, wenn die DATA-Zeilen korrekt eingegeben wurden. Damit erhält der User auch gleich ein visuelles Feedback, dass der Checksummer nun aktiv ist. Die Variable "a" habe ich bei der Berechnung der Checksumme noch dazu genommen, damit auch das versehentliche Weglassen von DATA-Einträgen mit Wert 0 in der Checksumme berücksichtigt werden.

Dies aber das nur als Idee/Vorschlag.

Zitat von zrs1

Was mich daran persönlich stört sind wirklich "nur" die 23 zusätzlichen Bytes

Ich verstehe das. Aber zusätzliche 23 DATA-Werte entsprechen nur etwa einer DATA-Zeile bei der C64-Version. Finde ich also schon zumutbar. Vor allem: Entweder ist jemand eh zu bequem die schon vorhandenen DATA-Zeilen abzutippen und lädt sich das Binary einfach runter oder er/sie sieht die zusätzliche Tipp-Vorarbeit als indirekte Wertschätzung und Teil des Abtipp-Flairs ein kleines Software-Tool einsetzbar zu machen - als Basis für das Haupt-Listing.

Zitat von zrs1

Ich werde vermutlich dem User (in der "Publisher" Rolle) die Entscheidung überlassen und eine Build-Option einbauen, so dass die Checksummer mit oder ohne dieses Feature gebaut werden können.

Würde das aber dann nicht darauf hinauslaufen, dass der Abtipper dann darauf achten müsste, ob er nun bei einem Listing mit 4-stelligen Checksummen den F64SummerWithREM oder F64SummerWithoutREM Checksummer verwenden soll? Am Einfachsten wäre es für mich als Publisher, wenn ich in meinem Listing lediglich ein kleiner Hinweis auf den F64Summer mit Versionsnummer und URL-Link auf den C64-Wiki-F64Summer-Eintrag angeben könnte.

Dazu noch eine Frage zur Version "Checksumme ohne REM": Gibt der Checksummer dann überhaupt noch eine Checksumme aus (somit nur für die Zeilennummer), wenn z.B. folgende Zeile eingeben und Return gedrückt wird?

10 rem **** alles klar, herr kommissar ****

Wenn eine Checksumme angezeigt wird, dann wäre das m.E. klar besser als gar keine Ausgabe, weil ansonsten die Checksumme von der Zeile davor noch auf dem Bildschirm steht, und DAS dann wirklich für Verwirrung sorgen würde.

Zitat von zrs1

Ob es eine simple Summe wird (ja, wahrscheinlich schon), mal sehen.

Ich empfehle faktor=faktor+1:summe=summe+faktor*DATAWERT, durch den hochzählenden Faktor fallen dann auch Zahlendreher auf.