Woher wissen Programmierer, was sie programmieren müssen, bevor sie Code schreiben?
Woher weiß ein Schriftsteller, was er schreiben muss noch bevor er die erste Seite nieder geschrieben hat? Es ist doch alles eine Stilfrage. Z.B. in einem Roman musst du unter den handelnden Figuren eine bestimmte Hierarchie einführen. Du musst spannend schreiben, sonst schlafen dir die Leser ein. In welcher zeitlichen Reihenfolge sollen die Ereignisse präsentiert werden?
Z.B. ganz wichtig ist, dass du nie Spaghetticode schreibst. Von Anfang an musst du bestimmte Unterroutinen auslagern, die die Arbeit dann modular erledigen.
Ich war ja nun berüchtigt in unserer Abteilung. Z:B. wurde die gesamte Textverarbeitung über Integervektoren abgewickelt; d.h. ein Wort dieses Vektors entspricht zwei Byte, also zwei Buchstaben ASCII .
Und dann kam der Datentyp " Character " heraus, der auch durch tools unterstützt wurde. Da habe ich dann etliche bereits existierende Programme umgemodelt.
Nein; Programmieren ist genau keine zentrale Planungswirtschaft; oft weißt du erst hinterher, was du von Anfang an hättest besser machen sollen. wieder genau wie ein romancier, der im Laufe seiner Arbeit fest stellt, dass er das halbe Manuskript entsorgen muss ( was ja im Zeitalter des PC nicht mehr weh tut ) weil er eine zusätzliche Figur in seinen Roman einführen will.
Der ideale Arbeitsstil - und da spreche ich aus Erfahrung - ist immer der runde Tisch. Du kriegst gesagt, welchen Teil von einem Job du zu übernehmen hast; welche Variablen kriegst du übergeben; und welche Ergebnisse erwartet man von dir, die du zurück gibst?
Keine Fabrik beauftragt ihre Mitarbeiter mit der Fertigung von ganzen KFZ. Sondern die Arbeiter stehen am Fließband, und jeder führt nur ganz wenige idiotische Handgriffe aus. So meinte etwa Kollege " Ingo " in seiner charmanten Art
" Stell dir vor; der Alfons is soo doof, der kann noch nichtmal einen Plotter ansteuern. "
" Haa - haa - haa. Was glaubst du wohl, warum ich diese Aufgabe dir übertrage? "
Unser Chef sagte immer, achten Sie auf Transparenz. If_Abfragen und Schleifen; das versteht jeder. Aber stell dir vor, da steht Print = 47 11 ; der Mitarbeiter kündigt oder stirbt ( was wir ihm natürlich nicht wünschen )
( Obwohl. Bei uns outete sich ein Alkoholiker, um den Chef zu ärgern. Schon am nächsten Tag hieß es, das habe der nie gesagt. Dann beging der Sohn eines Bereichsleiters Selbstmord. Daraus haben sie einen eigenen Festakt gemacht; der HAL meinte in seiner ansprache, wer des Lebens überdrüssig sei, solle es ihm rechtzeitig vorher ankündigen … )
Also der Nachfolger kann natürlich nicht wissen, dass 47 11 die Gerätenummer eines Druckers ist.
Hier wer kennt noch jenen Sprungbefehl go to 47 11 , der heute total verpönt ist?
In Fortran konntest du in Unterprogramm up1 sagen assign 47 11 to k . D.h. der merkte sich jetzt diese Sprungadresse. Und wenn du irgendwo in einem völlig anderen Up2 sagst Go to k , dann springt der nach dem Label 47 11 in Up1. In einem Job aus 10 000 Zeilen ist sowas aber alles andere als transparent. Du fragst dich, was ist k?
Noch als Antwort auf deine Frage; mein Chef meinte auch anfangs, er sei der Meister aller Klassen. Und während die Listings seiner Programme wuchsen, sich entwickelten und gediehen, merkte er, dass diese den Standards immer ähnlicher wurden, wie du sie beispielsweise bei IBM findest. D.h. du hast Inputvektoren, Outputvektoren so wie Errorflags. Ja und da fragte er sich, warum mach ich ' s nicht auch so?
Was mir also gar nicht behagt. Es scheint sich ja allgemein durchgesetzt zu haben, auch sagen wir mal eine 47 X 11 Matrix ( mit zwei Indizes ) als linearen Vektor ( mit einem Index ) abzulegen; d.h. du mutest dem User die ganze Adressrechnerei zu.
Warum ich übrigens der Programmiersprache Fortran nachtrauere. Fortran ist die einzige Sprache, die den Datentyp komplex versteht, und zwar Generic. d.h. wenn du beispielsweise schreibst a + b und auch nur a ist komplex, dann rechnet der komplex. Z.B. in Pascal ist das gar nicht möglich, weil du dir zwar privat beliebige Datentypen schnitzen kannst, solche Rechenzeichen aber vom Compiler nicht mehr verstanden werden. Statt dessen sollte man genau in der umgekehrten Richtung denken und den Datentyp " Quaternion " generisch implementieren; das ist von Bedeutung für Drehmatrizen.
Die Idee hinter Pascal et al ist übrigens total Keese. Dort kannst du dir einen Datentyp " Einszehn " schitzen, der nur die Integers von 1 - 10 umfassen darf. Was passiert nun, wenn deine Variable außerhalb des Defbereichs liegt? Dann stürzt der Rechner kalt ab; das darf nie passieren. Deine Fehlerabfragen hast du selber so zu verwalten, dass so bald ein Fehler erkannt ist, eine Usermitteilung heraus geht.
So entwickelte bei uns ein " Neuer " ein Plotterprogramm, welches Lötaugen ( Polygone ) zu zeichnen hatte. dieses gab als erste die Frage aus
Input , " Wie viel Ecken hat Ihr Polygon? _ " , n_eck
Meint mein Chef, na sag ich mal Minus 4 711.
" Das dürfen Sie nicht. "
" Wieso nicht? Was passiert denn dann? "
" keine Ahnung … "
" Schauen Sie. Fehler machen wir ja alle. Aber was absolut tödlich ist , Hr. Meyer. Wenn Sie nicht mehr überblicken, was passiert, so bald eine bestimmte Fehlersituation eintritt wie z.B. meine negative Eckenzahl. Sie müssen alles im Griff haben auf dem sinkenden Schiff … "