...
Min første computer var en PET 2001, til min personlige lykke var det Hegelsbergschule i Kassel dengang en topmoderne modelskole med mange meget ambitiøse lærere. Og i 1982 med et af Tysklands allerførste computerrum! På det tidspunkt var Commodore Basic (faktisk allerede et licensprodukt fra Microsoft) et af de mest udbredte programmeringssprog.
På denne skole var der faktisk også en læringcomputer, formentlig fra firmaet Phywe (lignende billede). På denne kunne man stadig føle Assembler og forstå, hvordan hukommelse, ALU, styringsenhed arbejder sammen – og hvorfor der er enkle (fra processorens synspunkt) og svære kommandoer.
I modsætning til alle lagringsemner (sortering, nøgler, felter, sætstørrelser) har dette i dag næsten ingen betydning.
Først på en ZX81, senere en ZX Spectrum, blev pladsbesparende programmering og „lynende hurtige“ assembler værktøjer i hverdagen.
Efter CP/M kom Turbo Pascal, startende med version 3.3, som er grundlaget for alle procedurelle sprog den dag i dag... og også en vigtig byggesten til den første „Navision“, DOS-versionen 3.52, som fra Thomas Hejlsberg, blev udviklet af broderen til den geniale Turbo Pascal-udvikler Anders Hejlsberg. Fun-fact: Navision havde også en integreret „lommeregner“ i sin DOS-version, ligesom Turbo Pascal.
Med de disketteopererede IBM’s (DOS = Disk Operating System) opstod der en stærk følelse af at holde behandlingsdata i hukommelsen så meget som muligt, for ikke at skulle tilgå den langsomme diskette. En vigtig grundlag for dette er, at RAM i sidste ende altid er værdifuldt, og SWAP-hukommelse ikke er et alternativ. I en tid, hvor „hukommelse intet koster“, mangler denne forståelse desværre mange nye programmører… og kan, efter min erfaring, heller ikke formidles.
Hvem vil, kan Her er lidt „grundlæggende“ læsning.
IBM... mine nye rødder
Snart med DOS kom i 1986 også dBase og Clipper i spil.
Med dBase/Clipper på den første IBM-klon blev den grundlæggende forståelse af records (dataposter) skabt ... og hvorfor sortering af records er hårdt arbejde for en computer. Værdifuld basisviden, som også er svær at formidle til nye programmører. Og: en utrolig forøgelse af produktiviteten! INSERT/DELETE/SORT, transaktioner, masker, lister ... Alt dette var pludselig ikke længere programmørens job ... fordi andre programmører allerede havde gjort arbejdet for ham før. Ikke desto mindre skulle man stadig kende til nøgler. Ligesom i dag er sorteringsnøgler både en forbandelse og en velsignelse ... Dosen gør giften.
Turbo Pascal blev det foretrukne værktøj til al udvikling af højniveausprog på universitetet. Garbage collection, strengmanipulation og menuer blev stadig flikket sammen i hånden „dengang“. Men alle, der har udviklet deres egen strengstyring, vil udmærket forstå, hvorfor Navision RTC har sine problemer med strengændringer. Mikrocontroller-programmering var en undtagelse. Assembler var et utroligt enkelt og logisk programmerings“sprog“ ... men alligevel aldrig min ven. Tak til Intel for at introducere 8052AH, med hvilken jeg endda var i stand til at udføre komplekse kontrolopgaver på en mikrocontroller i Basic. Så hvis du tror, at Raspberry pi som en kompakt mikrocomputer, der er nem at programmere, er en helt ny og hip opdagelse i det 21. århundrede ... Beklager, det er gammel vin på nye flasker 🙂 Og vi havde allerede LED'er!
Under mit studie kom jeg også i tæt kontakt med Siemens Nixdorf/Comet TOP-varestyring med Business Basic. Også en fascinerende løsning, og på det tidspunkt med rette markedsleder. Også her var det en selvfølge for programmøren at tage sig af sine opgaver... og ikke datalagringen. Denne erfaring hjalp mig senere meget med at erstatte Comet-applikationer med Navision. Det vidste jeg selvfølgelig ikke i 1990. Men den selvsikre håndtering af F3 til indsættelse og F4 til sletning fjernede en lille forhindring for senere Navision 🙂
Hold øje med menulinjen: Brødrene Heijsenberg sender hilsner 🙂
Navision… Den første kontakt fandt sted i november 1993. En demonstration fra en tidligere medarbejder hos min læreplads. Og jeg stillede mig dengang det spørgsmål, der stadig holder mig til Navision i dag: Hvorfor skulle man programmere på nogen anden måde?
Ja, Navision… Selvfølgelig laver jeg nu også AL i Visual Studio Code med Business Central. Men tilbageskridtene i produktivitet gør ondt.
Og så kom der selvfølgelig efterhånden alle efterfølgerversionerne af Navision. Fra den super stabile og dengang lynhurtige og banebrydende 2.01-version til 3.70-versionen med en stabil automatisationsintegration (velkommen, Excel, Word og den første stabile scheduler!).
Jeg indrømmer... Med RDLC og det generelle design i RTC kæmpede jeg i starten meget. Den helt nye måde at programmere rapporter på var... besværlig! Hvis man til den oprindelige Navision (som den nu hedder, versioner op til 2009R2) stadig kunne give farver i rapporten (f.eks. for at vise debetværdier med rødt): Jeg ville aldrig have behøvet mere for at gøre mine kunder glade. Nu ved jeg naturligvis også værdien af RDLC.
Da blev jeg – efter ED Post – til Quiche-spiser… og elsker denne måde at programmere på den dag i dag! Jeg har aldrig savnet at være en rigtig programmør. Når jeg stadig kan koncentrere mig om at løse opgaven med Navision, ligesom jeg kunne med dBase og Clipper, sammenligneligt med Cobol. Og ikke længere behøver at bekymre mig om hukommelseslækager, garbage collection, arv, overbelastning, lazy read og alt det andet, som en ikke-Navision-programmør skal tage hensyn til. Og det mætter mig og min dejlige kone mere end godt den dag i dag.