Diskussion:Programmierung
Programmierung ist mehr als das Eingeben von Computerbefehlen. Da gehören auch das Erfassen des Problems, das Zerlegen des Problems in kleinere Teilprobleme, die Implementierung, Testen, Fehlersuche, und Refaktorisieren dazu.
Der eventuell notwendige Übersetzungsschritt zum Beispiel bei Assembler oder Pascal ist auch mehr als Befehle ins RAM zu schreiben.
Das Beispielprogramm ist umständlich und IMHO teilweise falsch.
- Warum wird die Farbe zwischen Hintergrund und Rahmen umständlich mittels PEEK übertragen, wo sie doch in F steht?
- Die Zuweisung I=TI ist überflüssig weil bei positivem Argument bei RND der Wert egal ist, man hätte also überall RND(1) statt RND(I) verwenden können.
- Nach drucken des Sterns müsste das CHR$(19) überflüssig sein.
- Die Sprungentscheidung in Zeile 60 wäre vielleicht kürzer und leichter verständlich als
IF RND(1) < 2/50 THEN 30
.
--BlackJack 11:43, 27. Dez. 2008 (CET)
- Grundlagenartikel, sollten meiner Meinung immer so verfaßt werden, daß Sie jeder (auch Laie) versteht. Natürlich kannst Du gerne ergänzend o.g. Sachen in den Artikel einbringen, vielleicht unter dem Absatz "Gute oder Zielorientierte Programmierung" bzw. "Systematische Programmierung", aber bitte so daß sie nicht zu sehr nach Universitäts- oder Wikipedia-Sprache klingen.
- Zum Listing: Ich schreibe gerne auf die schnelle ergänzende Beispiellistings, die es noch nicht in der C64-Wiki gibt bzw. die es bisher so icht gegeben hat. Allerdings versuche ich die Listings dem Artikel anzupassen, so paßt z.B. bei einem Artikel zur "Programmierung" als BASIC-Programm-Beispiel sicherlich ein nicht zu langes Programm mit möglichst viele BASIC-Befehle einzubringen oder zu demonstrieren wie Variablen übergeben werden. Dabei legen ich keinen Wert auf das "Zerlegen des Problems bzw. der Idee" nach o.g. Aspekten. Hauptsache es funktioniert und man kann es nachvollziehen, auch wenn es umständlich ist.
- Es gibt sichere interessantere Beispiele, aber auf die schnelle viel mir kein anderes ein. --Jodigi 23:11, 27. Dez. 2008 (CET)
- Artikel und Listing passen zusammen, wenn man Programmierung als "quick&dirty" reinhacken eines Programms unter dem Motto "Hauptsache es funktioniert irgendwie." sieht. Sorry aber das ist IMHO nicht nur falsch, sondern auch schädlich. Und was heisst hier nachvollziehen können? Gerade Laien werden mit Speicherstelle 646 und dem SYS zum Positionieren der Ausgabe ohne einen erklärenden Kommentar nichts anfangen können. Was das mit
I=TI
soll kann ich als "Experte" nicht nachvollziehen, was soll dann ein Laie davon halten? Gerade für Laien sollte man sich bemühen saubere Beispiele zu zeigen, die strukturiert sind und nicht unnötig kompliziert. Die machen dass dann nämlich nach! Vorschlag:
- Artikel und Listing passen zusammen, wenn man Programmierung als "quick&dirty" reinhacken eines Programms unter dem Motto "Hauptsache es funktioniert irgendwie." sieht. Sorry aber das ist IMHO nicht nur falsch, sondern auch schädlich. Und was heisst hier nachvollziehen können? Gerade Laien werden mit Speicherstelle 646 und dem SYS zum Positionieren der Ausgabe ohne einen erklärenden Kommentar nichts anfangen können. Was das mit
10 rem *** c64-wiki sterne demo *** 20 rem abbruch nur mit run/stop-taste 30 print rnd(-ti);chr$(147);"!!! das c64-wiki sterne demo !!!" 40 poke 53280,0:poke 53281,0 50 rem zufaellige textfarbe 60 f=int(rnd(1)*16):poke 646,f 70 rem ausgabe zufaellig platzieren 80 poke 211,int(rnd(1)*40):poke 214,int(rnd(1)*24):sys 58640 90 print "*"; 100 rem 1/25 chance, dass hintergrundfarbe geaendert wird 110 if rnd(1) < 1/25 then poke 53280,f:poke 53281,f 120 goto 50
- Als C-Programm für cc65:
#include <stdlib.h> #include <conio.h> void main(void) { unsigned char breite, hoehe; unsigned char hintergrund_alt, rahmen_alt, text_alt; unsigned char farbe = COLOR_BLACK; _randomize(); screensize(&breite, &hoehe); clrscr(); hintergrund_alt = bgcolor(farbe); rahmen_alt = bordercolor(farbe); text_alt = textcolor(COLOR_YELLOW); cputs("!!! Das C64-Wiki Sterne Demo !!!"); while (! kbhit()) { farbe = rand() % 16; textcolor(farbe); cputcxy(rand() % breite, rand() % hoehe, '*'); if (rand() % 100 <= 1) { bgcolor(farbe); bordercolor(farbe); } } cgetc(); bgcolor(hintergrund_alt); bordercolor(rahmen_alt); textcolor(text_alt); clrscr(); }
- --BlackJack 12:05, 28. Dez. 2008 (CET)
- Meiner Meinung muss programmieren Spass machen und das macht sie mir nur dann, wenn ich nach dem Try&Error-Prinzip selber herumexperimentieren kann. Leider gehöre ich wohl zu den Leuten, die einfach so losprogrammieren...
- Weiterhin möchte ich immer verschiedene Sachen zeigen, in aller kürze wie man was mache könnte. Die REM-Zeilen habe ich schon hinzugefügt.
- Ich habe mal die Absätze "Systematische P." und "Speicherplatzsparende P." hinzugefügt. Du kannst gerne auch hierzu etwas schreiben oder ergänzen.--Jodigi 01:12, 29. Dez. 2008 (CET)
- Formaler weise, muß bei Variablenzuweisungen im Musterprogramm die Anweisung LET drin stehen bleiben, auch wenn diese überflüssig wäre.
- Interessant wäre dieses Beispiel auch in Assembler. --Jodigi 06:38, 30. Dez. 2008 (CET)
- LET war im "Original" (Dartmouth BASIC) vorgeschrieben, weil dann alle Anweisungen mit einem Schlüsselwort beginnen, was es wahrscheinlich für den Compiler (geringfügig) leichter macht. Soweit ich weiss ist es im ANSI-Standard "Minimal BASIC" von 1978 schon optional, formal gesehen ist das Weglassen also erlaubt. Ich habe kein BASIC erlebt, in dem es nicht optional wäre. Im C64 Benutzerhandbuch wird es bei der Einführung in die Programmierung (Kapitel 2, Abschnitt "Variable") nicht einmal erwähnt, da wird ausschliesslich die Zuweisung ohne LET gezeigt. Das dürfte der Grund sein, warum es ziemlich untypisch für BASIC-Programme auf/für den C64 ist.
- Das END am Ende ist auch ziemlich sinnlos. Beim Dartmouth BASIC war es zwingend als letzte Zeile vorgeschrieben, selbst wenn der Programmfluss die Zeile nie erreicht, und es durfte auch nur einmal im Programm vorkommen. Damit der Compiler erkennen konnte, wann das Program zuende ist, insbesondere wenn es über Lochkarten eingegeben wurde, weil da ja noch mehr im Eingabeschacht liegen konnten und einmal eingelesene Karten vom Rechner nicht wieder zurückgelegt werden konnten. Das ist bei "modernen" Mikrorechnern wie dem C64 aber nicht mehr relevant, darum ist das END am Ende auch nicht obligatorisch.
- Bei einer Assemblerversion wäre die Erzeugung von Zufallszahlen in einem bestimmten Bereich, dessen Obergrenze keine 2er-Potenz ist, interessant. Problem dabei: Man kommt dafür wohl nicht ohne Division oder Modulo-Rechnung, oder zumindest Multiplikation aus, was beim 6510 ja etwas unangenehmer ist, als in Hochsprachen mal eben ein
*
,%
odermod
hinzuschreiben. --BlackJack 11:09, 30. Dez. 2008 (CET)
- Bei einer Assemblerversion wäre die Erzeugung von Zufallszahlen in einem bestimmten Bereich, dessen Obergrenze keine 2er-Potenz ist, interessant. Problem dabei: Man kommt dafür wohl nicht ohne Division oder Modulo-Rechnung, oder zumindest Multiplikation aus, was beim 6510 ja etwas unangenehmer ist, als in Hochsprachen mal eben ein
"Spaghetti-Code"[Quelltext bearbeiten]
Im Abschnitt „Speicherplatzsparende Programmierung“ steht die Anmerkung „(sogenannter "Spaghetti-Code")“, aber die ganzen Beispiele die dort davor aufgelistet sind, haben nichts mit diesem Begriff zu tun. Und Spaghetti-Code wiederum hat nicht zwingend mit speicherplatzsparender Programmierung zu tun. Den kann man auch bekommen wenn man sein Programm nicht strukturiert, im Sinne von strukturierter Programmierung, oder nachträglich irgendwelchen Code rein bastelt und die vorhandenen Zeilennummern nicht anpassen oder neu nummerieren will oder kann. Ich würde das gerne entfernen, aber vielleicht möchte ja auch jemand tatsächlichen Spaghetti-Code im Artikel beschreiben‽ --BlackJack (Diskussion) 16:29, 27. Mai 2016 (CEST)
- Sollte entsprechend angepasst werden, aber nicht entfernt werden...--Jodigi (Diskussion) 23:16, 1. Jun. 2016 (CEST)