Programmierung ...ein Bedauer

Computer: Software & Programmierung Programmierung allgemein
#1

Hallo.

Ich stelle diese nun folgende, mehrzeilige Frage an alle, die auf dem PC in Assembler oder in C programmieren.

Ich frage mich allen Ernstes, wie es auf dem PC Spass machen kann, ein Programm zu schreiben.
Hört sich etwas flach an, also anders ausgedrückt:

Zu C64 und AMIGA - Zeiten konnte man den Rechner anschalten, Cartridge in den Port stecken und direkt im Debugger loscoden.

Und jetzt das wichtigste:

BEI EINEM FEHLER DES PROGRAMMS, einem ABSTURZ oder ähnlichem, ‚ZACK‘!,

auf den RESET-Taster gedrückt, Debugger über HOTkeys aufrufen und weitermachen.
Dies war eine Sache von WENIGEN SEKUNDEN !

Irgendwann hatte man dann den Fehler gefunden UND sogar noch einen Grafik-EFFEKT entdeckt, der durch den ursprünglichen Fehler im Programm AUSGELÖST wurde !

SO.

Wie, bitte schön, geht diese Prozedur denn heute vonstatten ?

Wenn der PC hochgefahren ist und man einen Debugger
(zu Not den alten DEBUG von DOS)aufruft, gibt extra einige fehlerhafte Befehle ein und startet den Müll
…

ZACK…nichts geht mehr.

Wenn man bei jedem Fehler im Programm dann den Rechner immer wieder neu starten muss, wirft man wegens SPASSVERLUST am Programmieren das Handtuch spätestens beim 5. Absturz oder Hängenbleiben.

Gibt es denn keine Methode, den Rechner quasi Ruckzuck wieder zu resetten, damit man schön flüssig programmieren kann ?

Damit wir uns nicht falsch verstehen :

Es geht nicht um einen Absturz als solchen, sondern drum, aus diesem möglichst schnell wieder flüchten und ohne Code,- sowie Zeitverlust wieder zum Programm zurückzukehren.

Bei dieser ‚Programmierungs-Philosophie‘ geht doch der
EXPERIMENTIER-GEIST vollständig verloren.
Aus Angst, der Rechner stürzt ab und nimmt den Code mit.

Die Sache mit dem " Was passiert denn, wenn ich DIESES Register mit einem illegalen Wert beschreibe…’ macht doch erst den Geist spannender Programmierung aus.

Zu Asbach-C64 Zeiten möglich…und heute ?

Schreibt mal was dazu.

Bis dahin…

Have a nice Day.

Chris

#2

Hallo.

Ich stelle diese nun folgende, mehrzeilige Frage an alle, die
auf dem PC in Assembler oder in C programmieren.

Wenn man bei jedem Fehler im Programm dann den Rechner immer
wieder neu starten muss, wirft man wegens SPASSVERLUST am
Programmieren das Handtuch spätestens beim 5. Absturz oder
Hängenbleiben.
Gibt es denn keine Methode, den Rechner quasi Ruckzuck wieder
zu resetten, damit man schön flüssig programmieren kann ?

da es konkret um PC geht, ist es doch so, daß man da ein
Betriebssystem (OS-operating system) hat.
Da ist es dann aber schlechter Programmierstil mal eben in
irgend welchen Registern zu rühren, weil das am OS vorbei
geht und damit schneller inkompatibel ist als Du programmieren
kannst. Da muß man sich dann auch nicht wundern, daß das
OS meckert, wenn Du ihm unkontroliert dazwischen funkst.

Es sollten also die standartisierten Schnittstellen zum OS
benutzt werden und damit ist es kein Problem mehr, weil man
dann in Verbindung mit dem Debuger verhindern kann, daß das
OS einfach abstürzt.

Damit wir uns nicht falsch verstehen :
Es geht nicht um einen Absturz als solchen, sondern drum, aus
diesem möglichst schnell wieder flüchten und ohne Code,- sowie
Zeitverlust wieder zum Programm zurückzukehren.

Wie gesagt, bei vernüftiger Benutzung der OS-Routinen kann man
mit dem Debuger ein verlaufenes Programm wieder zurückholen.

Bei dieser ‚Programmierungs-Philosophie‘ geht doch der
EXPERIMENTIER-GEIST vollständig verloren.
Aus Angst, der Rechner stürzt ab und nimmt den Code mit.

Vor eine Testlauf speichern sollte man sich eh angewöhnen.

Die Sache mit dem " Was passiert denn, wenn ich DIESES
Register mit einem illegalen Wert beschreibe…’ macht doch
erst den Geist spannender Programmierung aus.

Naja, was soll das bringen?

Zu Asbach-C64 Zeiten möglich…und heute ?

Nicht mehr möglich und auch kaum sinnvoll.
Schon auf einem anderen Board oder auf dem gleichen Board mit
einem anderen Prozessor oder einer anderen Konfiguration
hättest Du wohl Probleme mit einem so hardwarenahen Programm.
Gruß Uwi

#3

Hallo.

Wie, bitte schön, geht diese Prozedur denn heute vonstatten ?

Ich habe ein Dos 6.22 mit installiertem
Windows 3.1 in einer VM-Ware-Session.

Nach 5 Sek bin ich im DOS-Prompt.

Dann hab ich noch ein Win98SE in
einer VM, das braucht 13 sek bis
zum Desktop.

In der DOS 6.22-VM hab ich alles
mögliche ‚von früher‘ drin:

  • Borland C++ 3.1
  • Turbo Pascal 7
  • Power Basic 3
  • Turbo Assembler/Turbo Debugger
  • Norton Commander
  • Norton Guide (für Assembler)
  • TechHelp 3.3a (alle DOS/Bios/ASM-Funktionen)

Was will man mehr :wink:

Grüße

CMБ

#4

Hallo Christoph,

was du beschreibst ist der sogenannte Bastelansatz. So bezeichnet man das übelste, was man an Programmiertechnik auf dieser schlechten Welt finden kann.

Software wird heute ganz anders entwickelt. Sonst wäre es überhaupt nicht möglich wirklich große Programme zu schreiben.

Selbst zum kleinsten Programm gehört eine Spezifikation, die die Anforderungen enthält. Daraus erstellt man ein Analysemodell, das die fachlichen Abläufe richtig beschreibt. Daraus entsteht dann das Designmodell, das die technische Realisierung darstellt.

Und jetzt musst du stark sein:

Die Programmierung macht der Computer. Oder der Inder oder Chinese oder Russe. Jedenfalls der, der am wenigsten dafür verlangt.

Danach wird getestet.

Es gibt Laufzeitumgebungen, in denen du auch Assembler und C und was weiss ich noch alles in einer Sandbox ablaufen lassen kannst. Da raucht nix ab. Und für Funktionalitäten nutzt man Bibliotheken und nicht Zufallsfunde in der Compileroptimierung.

Gruß

Peter

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#5

Bei dieser ‚Programmierungs-Philosophie‘ geht doch der
EXPERIMENTIER-GEIST vollständig verloren.
Aus Angst, der Rechner stürzt ab und nimmt den Code mit.

Die Sache mit dem " Was passiert denn, wenn ich DIESES
Register mit einem illegalen Wert beschreibe…’ macht doch
erst den Geist spannender Programmierung aus.

Zu Asbach-C64 Zeiten möglich…und heute ?

Heute macht man sowas mit Ahnung. Schau dir mal die Demo-Szene an. Ein sehr prominentes Beispiel ist zB .theprodukkt, hauptsächlich bekannt durch einen First Person Shooter in 96kbyte:
http://www.theprodukkt.com/

Andere Leute bringen ein Pokemon-Taschenspiel dazu, 3D-Grafik zu produzieren:
http://pokeme.shizzle.it/

Es ging nie darum, einfach stupide Werte irgendwohin zu schreiben um dabei zufällig den Bildschirm zum flackern zu bringen. Natürlich ist das hin und wieder passiert. Die wirklich guten und kreativen Entwicklungen sind ein Resultat von einer Idee und einer guten Kenntnis des Systems.

#6

Hi Semjon,

Windows 3.1 in einer VM-Ware-Session.

was heißt VM, ist damit Virtual machine gemeint, was issen das überhaupt, beim Kauf meines Computers von einem bekannten Discounter war da eine CD mit Virtuell Machine dabei, für was brauch ich die?

In der DOS 6.22-VM hab ich alles
mögliche ‚von früher‘ drin:

  • Norton Commander

Jepp, ich benutze nicht den Windows Explorer sondern den Norton Commander 2.0 und bin hochzufrieden damit.

Wenn du den auch kennst kennst du vielleicht noch Pcshell bzw Pctools, da gab es eine Option eine Datei zu formatieren, d.h. die Daten der Datei wurden gelesen, an der Stelle wo sie standen wurde formatiert wi e bei format c:, dann wurden die Dateidaten wieder hingeschrieben.
So konnte man zu Win3.1-Zeiten oftmals unlesbare Dateien wieder hinkriegen. (Übrigens, es gibt auch einen Webbrowser für Win3.1)
Gibt es so ein Programm heute noch, kennst du Namen der Programme die das können?
Danke ^ Gruß
Reinhard

#7

Hallo Peter

Software wird heute ganz anders entwickelt. Sonst wäre es
überhaupt nicht möglich wirklich große Programme zu schreiben.

Hast Du hier nicht etwas in die falsche Kehle
bekommen? Christoph fragt, wie man heute den
„Bastelansatz“ realisiert - und Du hebst den
gehobenen Zeigefinger und beschimpfst ihn
wegen „Bastelansatz“? Hehe!

Selbst zum kleinsten Programm gehört eine Spezifikation,
die die Anforderungen enthält. Daraus erstellt man ein
Analysemodell, das die fachlichen Abläufe richtig be-
schreibt. Daraus entsteht dann das Designmodell, das
die technische Realisierung darstellt.

LOL. Jetzt ist mir beinahe die Kaffeetase runterge-
plumpst :wink:

Und jetzt musst du stark sein:
Die Programmierung macht der Computer. Oder der Inder oder
Chinese oder Russe. Jedenfalls der, der am wenigsten dafür
verlangt.

Nein, C. frug nach einer ganz anderen Art
von „Programmierung“, nämlich der, bei der der
am schnellsten aus seinen Fehlern lernt, der pro
Zeiteinheit am meisten Fehler machen kann.

Es gibt Laufzeitumgebungen, in denen du auch Assembler und C
und was weiss ich noch alles in einer Sandbox ablaufen lassen
kannst. Da raucht nix ab.

Du hättest in ja mal zu so einer (vernünftigen)
„Sandbox“ hinführen können :wink:

Und für Funktionalitäten nutzt man
Bibliotheken und nicht Zufallsfunde
in der Compileroptimierung.

Wie hast Du denn angefangen, damals? Hast Du ein
‚Analysemodell, das die fachlichen Abläufe
richtig beschreibt‘ erstellt?

Hat das Spass gemacht ? :wink:

Grüße & nix für ungut

CMБ

2 Like
#8

Hallo.

Ich stelle diese nun folgende, mehrzeilige Frage an alle, die
auf dem PC in Assembler oder in C programmieren.

Ich frage mich allen Ernstes, wie es auf dem PC Spass machen
kann, ein Programm zu schreiben.

Hallo auch.
Die Frage ist eindeutig und ich kann folgendes dazu sagen: Der Spass kommt mit der Ahnung und mit den besseren Werkzeugen und der besseren Vorstellung davon, was überhaupt passieren soll.

Hört sich etwas flach an, also anders ausgedrückt:

Zu C64 und AMIGA - Zeiten konnte man den Rechner anschalten,
Cartridge in den Port stecken und direkt im Debugger loscoden.

Und jetzt das wichtigste:

BEI EINEM FEHLER DES PROGRAMMS, einem ABSTURZ oder ähnlichem,
‚ZACK‘!,

auf den RESET-Taster gedrückt, Debugger über HOTkeys aufrufen
und weitermachen.
Dies war eine Sache von WENIGEN SEKUNDEN !

Irgendwann hatte man dann den Fehler gefunden UND sogar noch
einen Grafik-EFFEKT entdeckt, der durch den ursprünglichen
Fehler im Programm AUSGELÖST wurde !

SO.

Wie, bitte schön, geht diese Prozedur denn heute vonstatten ?

Wenn der PC hochgefahren ist und man einen Debugger
(zu Not den alten DEBUG von DOS)aufruft, gibt extra einige
fehlerhafte Befehle ein und startet den Müll
…

ZACK…nichts geht mehr.

Dazu habe ich den Hinweis, das bei Windows NT, XP und Konsorten ein besserer protected mode ist.
Der Schutz ist besser als wie bei Windows 95,98,Me.
Beendet wird in den meisten Fällen nur die betreffende Anwendung.
Meistens führt der kleinste Fehler sofort zur Beendigung des Programms, nicht aber von Windows.
Ein Programm unter Windows hat einige Ansprüche zu erfüllen, bevor es überhaupt ungestört und unstörend funktioniert.

Wenn man bei jedem Fehler im Programm dann den Rechner immer
wieder neu starten muss, wirft man wegens SPASSVERLUST am
Programmieren das Handtuch spätestens beim 5. Absturz oder
Hängenbleiben.

siehe oben.
Man schreibe Batch Files um das Program zu compilieren bzw. zu linken und zu starten. Dann dauert es nur wenige Sekunden, bis 1 mal getestet.
Bei Kenntnissen zu Visual C kann man bequem die ganze Windows-choose grafisch programmieren, um sich voll auf den Code zu konzentrieren. Ich kenne aber nur VB, und schreib ich Assembler in eine DLL.

Gibt es denn keine Methode, den Rechner quasi Ruckzuck wieder
zu resetten, damit man schön flüssig programmieren kann ?

Rechner resetten ist Käse. Ein PC ist was anderes als ein C64.

Damit wir uns nicht falsch verstehen :

Es geht nicht um einen Absturz als solchen, sondern drum, aus
diesem möglichst schnell wieder flüchten und ohne Code,- sowie
Zeitverlust wieder zum Programm zurückzukehren.

Also wenn Du in einer Endlosschleife feststeckst, hilft beim PC tatsächlich nur noch neu starten/Reset. Hier kann man z.B. Haltepunkte zum debuggen setzen.
Programm speichern, dann testen, ist doch klar.
Das Debug ist heute doch stark unzufriedenstellend. Mit Debug verschwendest Du nur kostbare Zeit.

Die Sache mit dem " Was passiert denn, wenn ich DIESES
Register mit einem illegalen Wert beschreibe…’ macht doch
erst den Geist spannender Programmierung aus.

Das ist Unsinn. Alles Bestandteil des Protected Mode, bzw. hat nichts mit Programmieren zu tun, mehr mit Spielen.

Zu Asbach-C64 Zeiten möglich…und heute ?

Du must halt Deinen Bedürfnissen entsprechend improvisieren, bzw. dazu lernen.

Chris

MfG
Matthias

#9

Hallo an dieser Stelle.

Hi Semjon,

Windows 3.1 in einer VM-Ware-Session.

…schon interessant, dass jemand dieses OS heute noch verwendet ^^

was heißt VM, ist damit Virtual machine gemeint, was issen das

Ja.

überhaupt, beim Kauf meines Computers von einem bekannten
Discounter war da eine CD mit Virtuell Machine dabei, für was
brauch ich die?

Damit wird ein fremdes Betriebssystem unter einem Gastsystem ausgeführt.
Wenn diese abstürzt, kann man die VM einfach beenden. Es sei denn, die hat was mit Java zu tun :wink:

mfg M.L. (mit modernerer Ausstattung gesegnet: ältestes OS ist Win2K, neustes Suse Linux 9.3 & XP+SP2.9)

#10

Hallo Chris,

für die meisten ist es überhaupt keine Frage des Spasses, ein Programm zu schreiben, sondern Arbeit, und an die sollte man verantwortungsbewusst herangehen (gilt für alle, Maurer wie Programmierer). Der von dir beschriebene Programmierstil ist gottseidank inzwischen fast ausgestorben, in der Urzeit der IT kannte ich auch solche Chaoten, die ein Programm sozusagen rückwärts entwickelten: schreibe NOP und starte den Debugger - tut das Programm, was es soll? Natürlich nicht, also ändere einen Befehl und gehe zurück auf Start. Dass auf diese Weise zuverlässige Software entsteht, ist aus einer ganzen Reihe von Gründen ausgeschlossen.

Ich plane meine Software möglichst so, dass sie beim Codieren keine Fehler mehr enthält - dann muss ich auch keine Debuggen. Ein Programm, das sich aufhängt, ist schon Folge eines Planungsfehlers, wahrscheinlich habe ich irgendwelche Unterlagen nicht richtig gelesen oder interpretiert. In dem Fall sage ich dann unter Delphi „Programm zurücksetzen“ und das wars - geht sogar schneller als einen C64 neu zu starten. Trotzdem - einen Aufhänger oder fatalen Programmabbruch betrachte ich als persönliche Niederlage.

Also hör auf, der Vergangenheit hinterherzujammern und beschäftige dich mit heutiger Programmiertechnik - oder setz dich an deinen Nierentisch, schalte die Tütenlampe ein und höre eine Schellackplatte mit Caruso, während du deinen C64 startest.

Gruss Reinhard

PS du kennst ja noch nicht einmal die Vergangenheit richtig: einen Lochkartenstapel mit ALGOL im Rechenzentrum abzugeben, um dann 2 Tage später zu erfahren, dass du dich im Feld 38 der 135. Lochkarte vertippt hast - das macht keinen Spass.

#11

Hallo,

Ich stelle diese nun folgende, mehrzeilige Frage an alle, die
auf dem PC in Assembler oder in C programmieren.

gehen ‚ehemalige‘ Assemblerprogrammierer auch? :smile:

Ich frage mich allen Ernstes, wie es auf dem PC Spass machen
kann, ein Programm zu schreiben.

Was macht am Schachspielen Spaß? Erst denken, dann handeln und sich danach über den Erfolg freuen.

Irgendwann hatte man dann den Fehler gefunden UND sogar noch
einen Grafik-EFFEKT entdeckt, der durch den ursprünglichen
Fehler im Programm AUSGELÖST wurde !

Ja,? Da habe ich auch schon erst im kommentierten Romlisting gelesen, und dann gezielt den Grafikspeicher beschrieben. Die Grafik-effekte waren nicht zufällig sondern ich habe bewußt Teile des BS für meine Zwecke verwendet um Platz für Code zu sparen. Hätte ich mich dabei auf den Zufall verlassen, wären die Programme heute noch nicht fertig.

Es geht nicht um einen Absturz als solchen, sondern drum, aus
diesem möglichst schnell wieder flüchten und ohne Code,- sowie
Zeitverlust wieder zum Programm zurückzukehren.

Kein Windows verwenden, das brauchst Du für solchen Code nicht. Dann stört auch das Multitasking nicht so und Du darfst wieder die Hardware beschreiben.

Bei dieser ‚Programmierungs-Philosophie‘ geht doch der
EXPERIMENTIER-GEIST vollständig verloren.

Ja, geht er. Wenn Du weißt, was Du tust, mußt Du nicht ‚probieren‘.

Die Sache mit dem " Was passiert denn, wenn ich DIESES
Register mit einem illegalen Wert beschreibe…’ macht doch
erst den Geist spannender Programmierung aus.

Nö. Das Ziel, den einzigen undokumentierten Befehl zu finden, habe ich noch nie verstanden. Ich habe immer lieber in der Zeit ein Spiel geschrieben und wenn ich dabei auf ein Problem gestoßen bin, bei der Lösung etwas dazu gelernt.

Gruß, Rainer

#12

Wie hast Du denn angefangen, damals? Hast Du ein
‚Analysemodell, das die fachlichen Abläufe
richtig beschreibt‘ erstellt?

Hat das Spass gemacht ? :wink:

Grüße & nix für ungut

CMБ

Hallo,

war echt nicht bös gemeint.

Recht hast Du. Ich erinnere mich noch sehr gut an mein Gebastel von früher. Grauenhaft, aber es hat Spaß gemacht. Weit ist man nicht gekommen, aber immerhin es hat für die kleinen Programme, die man gebraucht hat, funktioniert.

Gruß

Peter

#13

Hallo Reinhard

für die meisten ist es überhaupt keine Frage des Spasses, ein
Programm zu schreiben, sondern Arbeit, und an die sollte man
verantwortungsbewusst herangehen …

Das ist, wenn es denn stimmt, mit Sicherheit
ein Grund für die „Krise der Softwareindustrie“ :wink:

Ich plane meine Software möglichst so, dass sie beim Codieren
keine Fehler mehr enthält - dann muss ich auch keine Debuggen.
Ein Programm, das sich aufhängt, ist schon Folge eines
Planungsfehlers, wahrscheinlich habe ich irgendwelche
Unterlagen nicht richtig gelesen oder interpretiert.

Das trifft sicher auf bestimmte Arten von
Programierarbeiten zu (Software-Architektur), diese
ist aber (imho) an ganz andere Voraussetzungen gebunden.

Trotzdem - einen Aufhänger oder fatalen Programmabbruch
betrachte ich als persönliche Niederlage.

Das Problem kommt dann, wenn Du (‚als ewig Lernender‘)
den ausgetretenen Pfad erstmals verlässt und Dich in
Komplexitäten hineinwagst, welche Du nicht voll überschaust,
während Du sie angehst. Dort gibt es nur den ‚iterativen
Weg‘ der Programmierung, welcher sogar ein modernes
Programmierparadigma darstellt.

Also hör auf, der Vergangenheit hinterherzujammern und
beschäftige dich mit heutiger Programmiertechnik - oder setz
dich an deinen Nierentisch, schalte die Tütenlampe ein und
höre eine Schellackplatte mit Caruso, während du deinen C64
startest.

Ich habe mal überlegt, warum ich, so ich eine
Softwarebude hätte, instinktiv zögern würde, Leute
über 35 oder gar über 40 als Programmierer einzustellen -
aber das hängt vielleicht mit solchen Dingen bzw. ein-
stellungen zusammen. Software-Architektur ist ein
wichtiger (grundlegender) Aspekt, aber man muss auch
bereit und in der Lage sein, seine Segel wieder zu
setzen und sich auf unerforschte Meere vorzuwagen :wink:

PS du kennst ja noch nicht einmal die Vergangenheit richtig:
einen Lochkartenstapel mit ALGOL im Rechenzentrum abzugeben,
um dann 2 Tage später zu erfahren, dass du dich im Feld 38 der
135. Lochkarte vertippt hast - das macht keinen Spass.

Es geht, wenn ich es richtig verstanden habe, einfach um
einen effektiven Lernprozess, um ein tiefes „sich vertraut“
machen durch das Experiment, welches Spass macht.

Grüße

CMБ

#14

Hallo Nicos,

Natürlich ist das hin und wieder passiert. Die
wirklich guten und kreativen Entwicklungen sind ein Resultat
von einer Idee und einer guten Kenntnis des Systems.

Paul Graham spricht:

 For example, I was taught in college that one ought to 
 figure out a program completely on paper before even 
 going near a computer. I found that I did not program 
 this way. I found that I liked to program sitting in 
 front of a computer, not a piece of paper. Worse still, 
 instead of patiently writing out a complete program and 
 assuring myself it was correct, <u>I tended to just spew out </u>
<u>code that was hopelessly broken, and gradually beat it into shape</u>. 
 Debugging, I was taught, was a kind of final pass where you 
 caught typos and oversights. The way I worked, it seemed 
 like programming consisted of debugging.

(qute from: http://www.onlamp.com/pub/a/onlamp/2005/06/30/artofp…)

So people, „get real“ :wink:

Grüße

CMБ

#15

Hallo CMБ

für die meisten ist es überhaupt keine Frage des Spasses, ein
Programm zu schreiben, sondern Arbeit, und an die sollte man
verantwortungsbewusst herangehen …

Das ist, wenn es denn stimmt, mit Sicherheit
ein Grund für die „Krise der Softwareindustrie“ :wink:

Trotz :wink: verstehe ich das jetzt nicht.

Ich plane meine Software möglichst so, dass sie beim Codieren
keine Fehler mehr enthält - dann muss ich auch keine Debuggen.
Ein Programm, das sich aufhängt, ist schon Folge eines
Planungsfehlers, wahrscheinlich habe ich irgendwelche
Unterlagen nicht richtig gelesen oder interpretiert.

Das trifft sicher auf bestimmte Arten von
Programierarbeiten zu (Software-Architektur), diese
ist aber (imho) an ganz andere Voraussetzungen gebunden.

Das trifft auf alle Programmierarbeiten zu.
Oder setzt du dich hin, denkst „ich programmiere jetzt mal“ und fängst ohne Planung an?

Trotzdem - einen Aufhänger oder fatalen Programmabbruch
betrachte ich als persönliche Niederlage.

Das Problem kommt dann, wenn Du (‚als ewig Lernender‘)
den ausgetretenen Pfad erstmals verlässt und Dich in
Komplexitäten hineinwagst, welche Du nicht voll überschaust,
während Du sie angehst. Dort gibt es nur den ‚iterativen
Weg‘ der Programmierung, welcher sogar ein modernes
Programmierparadigma darstellt.

Den ‚iterativen Weg‘ der Programmierungs umgehst du, wenn du vorher vernünftig planst. Bei komplexen Problemen ist das besonders wichtig. Erst die Probleme analysieren, ‚Überschauen‘ und dann programmieren. Die Planung benötigt 25% bis 50% der Arbeitszeit. Das sparst du beim eigentlichen Programmieren locker wieder ein. Dann kannst du auch problemlos ‚ausgetretene Pfade‘ verlassen (siehe oben).

Also hör auf, der Vergangenheit hinterherzujammern und
beschäftige dich mit heutiger Programmiertechnik - oder setz
dich an deinen Nierentisch, schalte die Tütenlampe ein und
höre eine Schellackplatte mit Caruso, während du deinen C64
startest.

Ich habe mal überlegt, warum ich, so ich eine
Softwarebude hätte, instinktiv zögern würde, Leute
über 35 oder gar über 40 als Programmierer einzustellen -
aber das hängt vielleicht mit solchen Dingen bzw. ein-
stellungen zusammen. Software-Architektur ist ein
wichtiger (grundlegender) Aspekt, aber man muss auch
bereit und in der Lage sein, seine Segel wieder zu
setzen und sich auf unerforschte Meere vorzuwagen :wink:

Ähhh, ich bin über 50, arbeite, wie ich oben beschrieben habe, programmiere seit 10 Jahren beruflich (da war ich ja schon über 40) erfolgreich, muss ich jetzt umdenken?
Ich wage mich erfolgreich oft auf ‚unerforschte Meere‘ vor, aber auf die oben beschriebene Art.

PS du kennst ja noch nicht einmal die Vergangenheit richtig:
einen Lochkartenstapel mit ALGOL im Rechenzentrum abzugeben,
um dann 2 Tage später zu erfahren, dass du dich im Feld 38 der
135. Lochkarte vertippt hast - das macht keinen Spass.

Ja, ja, Siemens 3000, PET 2001, CBM64 … seufz… hat Spaß gebracht.

Gruß
Manfred

#16

Hallo Manfred,

Das ist, wenn es denn stimmt, mit Sicherheit
ein Grund für die „Krise der Softwareindustrie“ :wink:

Trotz :wink: verstehe ich das jetzt nicht.

Ja, stell Dir vor - genervte Leute, die versuchen,
trotz pflichtbewusster Anwendung ihrer „Designprinzipen
aus der Studentenzeit“ Software fertigzubekommen :wink:

[Pre-design by Paper]

Das trifft auf alle Programmierarbeiten zu.
Oder setzt du dich hin, denkst „ich programmiere jetzt mal“
und fängst ohne Planung an?

OK, dann machen wir das unterschiedlich. Das, was
ich von einem Problem weiss, kann ich auch direkt
in „Programmstruktur“ umsetzen. Ich „zeichne“
praktisch in der Enwicklungsumgebung.

Den ‚iterativen Weg‘ der Programmierungs umgehst du, wenn du
vorher vernünftig planst. Bei komplexen Problemen ist das
besonders wichtig. Erst die Probleme analysieren,
‚Überschauen‘ und dann programmieren. Die Planung benötigt 25%
bis 50% der Arbeitszeit. Das sparst du beim eigentlichen
Programmieren locker wieder ein. Dann kannst du auch
problemlos ‚ausgetretene Pfade‘ verlassen (siehe oben).

Aha, jetzt verstehe ich die Diskrepanz.

Die „Planung“, das „Aufzeichnen“, mache ich
bereits „in Code“, den Zwischenschritt, den
Du „Planung“ nennst, spare ich mir üblicherweise.

Das „zeichne“ ich ggf. hinterher mal
auf papier, wenn ich weiss, das es funktioniert -
um mit anderen zu kommunizieren.

Ich habe mal überlegt, warum ich, so ich eine
Softwarebude hätte, instinktiv zögern würde, Leute
über 35 oder gar über 40 als Programmierer einzustellen -

Ähhh, ich bin über 50, arbeite, wie ich oben beschrieben habe,
programmiere seit 10 Jahren beruflich (da war ich ja schon
über 40) erfolgreich, muss ich jetzt umdenken?
Ich wage mich erfolgreich oft auf ‚unerforschte Meere‘ vor,
aber auf die oben beschriebene Art.

Vielleicht bist Du doch viel weniger
so ein beschriebener „theoretischer Planer“

  • als Du hier verrätst? :wink: Wer weiss?

Grüße

CMБ

#17

Ich habe mal überlegt, warum ich, so ich eine
Softwarebude hätte, instinktiv zögern würde, Leute
über 35 oder gar über 40 als Programmierer einzustellen -
aber das hängt vielleicht mit solchen Dingen bzw. ein-
stellungen zusammen. …

Hallo Semjon,

hast du da nicht was durcheinandergebracht? Christoph könnte mein Sohn sein - nicht umgekehrt.

Gruss Reinhard

#18

Hallo Chris,

Hallo Reinhard

Sorry, bin ein wenig in Eile, deshalb eine Antwort in Kürze…

für die meisten ist es überhaupt keine Frage des Spasses, ein
Programm zu schreiben, sondern Arbeit, und an die sollte man
verantwortungsbewusst herangehen (gilt für alle, Maurer wie
Programmierer).

Die meisten GUTEN Coder coden aus Spass.
Und dies oft um ein vielfaches schneller, als es ein ausgebildeter Programmierer tut.

Der von dir beschriebene Programmierstil ist

gottseidank inzwischen fast ausgestorben, in der Urzeit der IT
kannte ich auch solche Chaoten, die ein Programm sozusagen
rückwärts entwickelten: schreibe NOP und starte den Debugger -
tut das Programm, was es soll?

Und dies ist der Grund, warum der schnellere PC den VIEL langsameren
Homecomputern hinterherhinkte.

Aber genau dies ist die Philosophie, Registern auf die Spur zu kommen, die LAUT HERSTELLER(!) GAR NICHT EXISTIEREN.
Die somit auch von keinem Compiler und Betriebssystem unterstützt werden KÖNNEN.

Natürlich nicht, also ändere

einen Befehl und gehe zurück auf Start.

NATÜRLICH nicht ???
Ja von wegen.

Das Urproblem funktioniert dann (Natürlich!) nicht.
Deshalb weiss man aber plötzlich, wie man den Bildschirm verschiebt, OHNE den Bildschirm tatsächlich zu verschieben…
…Dinge, die in KEINER Dokumentation stehen KÖNNEN…

Dass auf diese Weise

zuverlässige Software entsteht, ist aus einer ganzen Reihe von
Gründen ausgeschlossen.

Dies wage ich ganz schwer zu bezweifeln, denn die WINDOWS-SAGA von 95 angefangen bis…? lässt dann nur den Schluss zu, total GEPLANT und
DURCHKONZEPTIONIERT worden zu sein.

Ich plane meine Software möglichst so, dass sie beim Codieren
keine Fehler mehr enthält - dann muss ich auch keine Debuggen.
Ein Programm, das sich aufhängt, ist schon Folge eines
Planungsfehlers, wahrscheinlich habe ich irgendwelche
Unterlagen nicht richtig gelesen oder interpretiert.

Dies mag bei riesigen Projekten teilweise so sein.

Stell Dir die Frage, wie man einen TREIBER für eine Graphikkarte programmieren soll…
Also ALLERUNTERSTE ASSEMBLER bzw. MASCHIENENSPRACHE-Ebene.
Die schönste Ebene überhaupt…:wink:

In dem

Fall sage ich dann unter Delphi „Programm zurücksetzen“ und
das wars - geht sogar schneller als einen C64 neu zu starten.

Ja. Button drücken geht tatsächlich schneller.
Was ist, wenn die BUTTON-Routine einen Fehler hat ?

Trotzdem - einen Aufhänger oder fatalen Programmabbruch
betrachte ich als persönliche Niederlage.

Ich betrachte sie als Inspiration, einen Code wirklich an Gott approximieren zu können…

Also hör auf, der Vergangenheit hinterherzujammern und
beschäftige dich mit heutiger Programmiertechnik - oder setz
dich an deinen Nierentisch, schalte die Tütenlampe ein und
höre eine Schellackplatte mit Caruso, während du deinen C64
startest.

Och manno…lass mich doch jammern…
Der Geist aller genialen Programmierung geht flöten und ich soll net jammern.

Gruss Reinhard

PS du kennst ja noch nicht einmal die Vergangenheit richtig:
einen Lochkartenstapel mit ALGOL im Rechenzentrum abzugeben,
um dann 2 Tage später zu erfahren, dass du dich im Feld 38 der
135. Lochkarte vertippt hast - das macht keinen Spass.

DAS glaube ich Dir sogar.

Ich muss gleich weg, aber noch eines:

Der grösste Vorteil, im Debugger zu coden oder zumindest zu werkeln ist der, dass man im Programm herumfummeln kann, WÄHREND ES ABLÄUFT !!!

Das kann kein Compiler, kein Interpreter usw.

Man programmiert also an den CPU Befehlen herum, während diese den Code ausführt.

Nur wer es schon gemacht hat, begreift die Bit-Power.

Trotzdem danke und

Have a nice Day

Chris

#19

Hallo Rainer,

Nö. Das Ziel, den einzigen undokumentierten Befehl zu finden,
habe ich noch nie verstanden. Ich habe immer lieber in der
Zeit ein Spiel geschrieben und wenn ich dabei auf ein Problem
gestoßen bin, bei der Lösung etwas dazu gelernt.

Undokumentierte Befehle findet man recht schnell, wenn man das Codierungs-Schema der CPU versteht, z.B. wenn man einen Assembler oder Disassembler schreibt.

Aber heutzutage macht das keinen Sinn mehr, da sich die CPU-Modelle zu schnell ablösen und somit kein praktischer Wert daraus entsteht, zumindest was den PC-Bereich angeht.

Bei Mico-Controllern sieht das manchmal noch anders aus.

MfG Peter(TOO)

#20

Hallo Chris,

ok, wir sind gegensätzlicher Auffassung (wobei mir Programmieren durchaus Spass macht, aber das ist nebensächlich): ich denke, heute ist die Herstellung von Software ein industrieller Prozess wie andere auch, und unterliegt daher auch den einschlägigen Anforderungen an Qualitätssicherungen usw. Solange du keinen Arbeitsplatz bei mir haben möchtest, stört mich deine Auffassung von Spassprogrammierung auch nicht, sonst würde sich aber die Frage stellen, ob du an einem solchen Projekt zur Produktion von z.B. einer Office-Software mitarbeiten kannst oder ob du eine Gefahr für das Projekt darstellen würdest. Nach meiner Erfahrung neigen Spassprogrammierer u.A. dazu, Code mit Absicht (und auch aus Überheblichkeit) so zu formulieren, dass ihn niemand sonst versteht - dass steht im krassen Gegensatz zur Anforderung der Wartbarkeit. Solche Lösungen sind nicht „elegant“, sondern einfach nur schlecht. Was immer ein Mitarbeiter A erstellt hat, muss von B fortgeführt werden können, ein Grundsatz industrieller Produktion.

Sollte jemand auf die Idee kommen, in ein von mir verantwortetes Programm undokumentierte Befehle einzubauen, wäre das ein Grund zur Abmahnung/fristlosen Entlassung - so etwas ist für professionelle Software absolut tabu und gehört ins Hacker-Miljöh. Ich sehe mich da auch völlig einig mit allen ernstzunehmenden Herstellern von Software.

Ehrlich gesagt sehe ich auch keinerlei Verdienst darin, undokumentierte Befehle zu entdecken - man braucht ja bloss eine Tabelle der möglichen Codierungen zu erstellen und die entsprechenden Befehle einzutragen, dann bleiben einige leer - das war schon immer so, seitdem es Prozessoren gibt. Ist eigentlich viel zu trivial für eine ernsthafte Beschäftigung, ausser eine Fachzeitschrift hat mal wieder nichts zu schreiben und braucht eine Schlagzeile wie „Intels grosses Geheimnis: wir haben sensationelle neue Befehle entdeckt“. Vielleicht ein netter Spass, aber professioneller Müll.

Gruss Reinhard

2 Like