Torben Mogensen header

Et levn fra teletypens tidsalder

I computerens barndom brugte man teletypeterminaler, der ligesom skrivemaskiner havde fast tegnbredde. Endvidere brugtes hulkort, der havde plads til 80 tegn per kort.

Det har medført, at man generelt skriver programmer med et fastbredde skriftsnit (monospace font) og peger fingre af linjer, der er mere end 80 tegn bredde. Men moderne skærme og printere har slet ikke de begrænsninger, som teletype og hulkort lavede, så der er intet til hinder for, at programmer skrives med mere moderne (eller klassisk) typografi.

De fleste programmeringssprog definerer ikke et bestemt skriftsnit, så man skal som programmør passe på med at bruge f.eks. proportionale skriftsnit: Selv om det ser pænt ud på programmørens skærm, men når en anden hiver programmet ind i sin editor eller skriver det ud, kan layoutet helt ødelægges. Derfor er traditionen stadig brug af fastbredde skriftsnit, og selv skriftsnit, der er designet til programmering, har ensartet bredde på alle tegn. Diverse editorer og IDE'er kan lave syntax highlighting, hyperlinks og komprimeret visning af definitioner, men de bruger stort set altid fast bredde. Endvidere er syntax highligting normalt ikke standardiseret: En editor kan vise nøgleord med fed tekst, en anden med rød tekst, osv, og det vedrører ikke det egentlige layout af programmet. Det kan automatisk indrykning gøre, men det er normalt defineret som en transformation af teksten indenfor rammerne af 80 tegn med fast bredde.

Så mit forslag er: Hvis man ønsker at bruge mere avanceret layout end arven fra teletype og hulkort tillader, så bør det dels være defineret sammen med sproget, og i givet fald kan man lige så godt gå hele vejen til brug af kursiv, fed tekst, superscripts, subscripts, matematiske symboler, græske tegn, brøker, osv. Hvorfor skrive en brøk som 3/4, hvis man kan skrive den som en rigtig brøk med vandret brøkstreg? Hvorfor skrive x_1, hvis man kan skrive det med en rigtig subscript? Summationer med sumtegn? Og så videre.

Det lader så tilbage spørgsmålet om, hvordan man taster programteksten ind. Her er grundlæggende to måder: Man kan bruge en WYSIWYG editor i stil med Word og enkelte HTML editors, eller man kan bruge koder i stil med LaTeX, Markdown og HTML. Det mest naturlige er nok en WYSIWYG editor med passende mange tastaturgenveje til de forskellige elementer, men man kunne evt. samtidigt også definere en ASCII-repræsentation, som mere hardcore folk kunne redigere i Emacs, Vi eller lignende. En sådan vil også gøre det nemmere at skrive programmer, der genererer programmer. Allerbedst vil være tre repræsentationer defineret i sprogdefinitionen: Typografisk layout, ASCII-markup og en datastruktur i programmeringssproget. Der skal selvfølgelig være standardværktøjer til konvertering: Parsere, der parser typografisk tekst eller markup til en datastruktur, og "pretty printers", der udskriver datastrukturen som typografisk tekst eller markup.

Men vinder man egentlig noget særligt ved dette fremfor standard ASCII? Programmer bliver nok lettere at læse, men de bliver lidt mere bøvlede at skrive. Men så skal man tænke på, at man bruger meget mere tid på at læse programkode end på at skrive den. Debugging er f.eks. mere læsning end skrivning: Man kan bruge timevis på at studere sit program, og derefter blot rette x til x-1 et sted. Så efter min mening er læselighed vigtigere end skrivehastighed. Det er meget få (om nogen) programmører, der primært er hæmmet af deres skrivehastighed.

Kommentarer (29)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Sebastian Paaske Tørholm

Jeg ved ikke om du har kigget på Mathematica, men den har nogle af de idéer de beskriver.

Koden kan skrives i plaintekst hvis man lyster, men som standard skriver man i Wolframs egen IDE, som kan rendere matricer, sumtegn, billeder og så videre inline. Der er så genveje til at skrive de fancy renderede udgaver, eller man kan skrive plaintext-udgaven af kommandoen.

Det er en spøjs blanding af WYSIWYG og plaintekst-kode der opstår som resultat deraf. Her er et eksempel, som det skal siges er meget mere læselig inde i IDE'en, hvor formatteringsinformation renderes.

I praksis bruger jeg som oftest plaintekst-navnene til funktioner, men det er da ganske rart når man fx. laver en matrix, at se den som en matrix, snarere end dens fladgjorte liste-i-liste-form. De har valgt konventionen [escape]navn[escape] til mange af den slags genveje, hvor navnet fx er sum hvis man vil lave et sum-tegn, eller int hvis man vil lave et integral-tegn, så hvis man bruger sproget nok, burde det ikke være et problem at lære de mest almindelige genveje udenad.

  • 0
  • 0
Troels Henriksen

Programmer bliver nok lettere at læse

Jeg er bange for at de bliver sværere at læse i alt andet end den tilrettede editor. Det sker ret ofte at man deler programkode andre steder, f.eks. på IRC, elektropost, eller på en webside, og det sker også at man sender kode igennem tekstorienterede værktøjer som f.eks. diff. Det er ikke realistisk at erstatte alle generiske værktøjer med sprogspecifikke.

  • 5
  • 0
David Christensen

...at du da burde kende til APL?

APL brugte selvsamme teletyper, særligt af IBM-kuglevarianten, som du trådte dine barnesko (eller noget) på:

https://en.wikipedia.org/wiki/APL_(programming_language)

Brugte langt hen ad vejen matematisk symbolologi (fra sætteori m.fl.).

Din artikels pointe synes jeg imidlertid rammer lidt ved siden af—hvilket du burde være opmærksom på som studieleder for B.Sc. i Datalogi. Det er simpelthen maintainability.

Med mindre man er en Edsger Dijsktra eller Tony Hoare-in spe (og dermed trænger til at komme lidt ned fra elfenbenstårnet), så fylder langt de fleste programmer mere end blot et par matematiske udtryk. Man forestiller sig det helvede, det ville være at arbejde med formatteret kode, hvis man skal ændre sådan moderat i sagerne.

I min erfaring som (kommerciel) udvikler, bruger man ikke mest tid på debugging, men derimod på vedligehold, hvilket er en både-og-aktivitet hvad angår læsning og skrivning angår; jeg tror speed-up'et ville være minimalt.

Dit sidste forslag—intet mindre end TRE displaymodusser—er også problematisk på sin egen facon. Så får vi pludselig skoler af udviklere som er eksperter i den ene form, men ikke forstår den anden... og så fremdeles. Sic transit...

Slutteligt vil jeg blot konkludere, at "programmeringsmiljøer" (ikke som sådan, men alligevel...) med formatterede udtryk, fx Maple og TI's CAS-miljøer, altid absolut har drevet mig (og mange andre) til vanvid.

The Principle of Least Surprise ville være en god lektion for dig her, hr. Mogensen ;-) Fixed width fonts er brugbare netop fordi de udgør en fællesnævner, som alle kan anvende. Betydningen af kode er alene hvad der står, ikke også HVORDAN det står...

  • 4
  • 1
Jesper Louis Andersen

Jeg har gennem de sidste års tid mest programmeret i en editor hvor default-fonten er variabel bredde. Det sammen med at den ikke har nogen 80-tegns begrænsning gør egentlig softwareudvikling en del rarere.

De sprog jeg prorgrammerer i har det som regel fint med dette, så længe man ikke insisterer på at ting skal lines op altid. Fordelen er at du kan have meget mere tekst på en linie fordi ting pakker meget bedre. Men det er nok noget man lige skal vænne sig til.

Og ganske rigtigt, så er det en del sværere at få unicode indtastet, så det skal som regel bruges sparsomt. Men det er nu meget rart at hvis an nu sidder og implementerer matematik, så at kunne kalde ρ for ρ :)

  • 1
  • 0
Troels Henriksen

...at du da burde kende til APL?

APL brugte selvsamme teletyper, særligt af IBM-kuglevarianten, som du trådte dine barnesko (eller noget) på:

https://en.wikipedia.org/wiki/APL_(programming_language)

Brugte langt hen ad vejen matematisk symbolologi (fra sætteori m.fl.).

APL er sådan set ikke i nærheden af hvad Torben Mogensen efterspørger, andet end at det gør brug af nogle sjovere tegn. APL er stadigvæk et fuldstændigt tegnbaseret sprog, uden formler eller avanceret typografi. Faktisk har APL en langt enklere syntaks end de fleste moderne sprog (f.eks. ingen operatorprioritet), og derfor endnu længere fra Torbens vision.

  • 2
  • 0
Poul-Henning Kamp Blogger

Algol er formodentlig det ultimative sprog i denne sammenhæng, man understregede reserverede ord og sproget påvirkede direkte indholdet af ASCII tegnesættet: Grunden til at vi har back-slash er så man kan skrive \/ og /\ i Algol programmer.

  • 1
  • 0
Torben Mogensen Blogger

Dit sidste forslag—intet mindre end TRE displaymodusser—er også problematisk på sin egen facon. Så får vi pludselig skoler af udviklere som er eksperter i den ene form, men ikke forstår den anden... og så fremdeles. Sic transit...

Sålænge der er layoutbevarende standardværktøjer til at konvertere mellem formaterne, tror jeg ikke, at det er et problem: En programmør, der foretrækker format X, vælger at "åbne" programteksten i dette format. Det gælder f.eks. allerede i dag for flere "sprog": Man kan kode HTML direkte i markupsproget, eller man kan bruge WYSIWYG HTML-editors, og man kan kode LaTeX direkte i markupsproget eller bruge LyX, Overleaf eller andre helt eller delvis WYSIWYG LaTeX-editors. Hverken HTML eller LaTeX egner sig dog til ren WYSIWYG-redigering, da ikke al information er synlig i den typografiske rendering. Men hvis man for et sprog definerede en typografisk rendering, der ikke havde skjult metainformation, så ville dette ikke være et problem.

I øvrigt er der i mit forslag kun tale om to menneskelæsbare formater: Markup og typografi. Det tredje format er som datastruktur, og primært rettet mod brug i værktøjer, der laver transformation, generering og analyse af kode (refactoring, oversættelse, parsergenerering, specialisering, verifikation, osv.). Det svarer lidt til DOM som en repræsentation for HTML: Den er ikke specielt menneskelæsbar, men den er praktisk at arbejde med i programmer.

I det omfang, at datastrukturer kan vises og redigeres, kan man dog ikke udelukke, at nogle foretrækker at kode i dette format. Det så man i sin tid med LISP, hvor den parentestunge notation oprindeligt var tiltænkt som intern repræsentation, mens der var en mere traditionel (hvis man kan tale om dette i 1958) notation til mennesker. Men primært fordi der ikke blev lavet en parser for denne notation, vænnede programmørerne sig til parentesnotationen. Hvis der fra starten havde eksisteret en parser og en pretty-printer, havde situationen måske været anderledes.

  • 0
  • 0
Torben Mogensen Blogger

Ja, ALGOL 60 rapporten lod sig (modsat COBOL og FORTRAN) ikke begrænse af den forholdsvis lille fællesmængde mellem FIELDATA, Baudot, og andre dengang eksisterende tegnsæt. I det definerede sprog brugtes f.eks. ↑, ¬, ×, ≡, ⊃, ≤, ≠, ≥, samt et subscript 10, ingen af hvilke fandt plads i ASCII. I rapporten er flere af disse tegn tydeligvis håndskrevne.

Rapporten erkender, at hardwarebegrænsninger indskrænker mængden af tilgængelige tegn, og foreskriver, at en implementering af ALGOL kan angive repræsentationer af de manglende tegn som kombinationer af de tilgængelige tegn, men standardiserer ikke dette udover et krav om, at dokumentationen for en specifik implementering skal specificere relationen mellem referencetegnsættet og den brugte repræsentation af dette.

På trods af det store referencetegnsæt foreslog ALGOL 60 rapporten, at man brugte en udvidet notation til publikation af programmer i trykte medier. Her kunne man f.eks. bruge græske bogstaver, subscripts, eksponenter, og andre ting, som referencetegnsættet ikke tillod.

  • 1
  • 0
David Christensen

Så en slags IR-format? I see.

Og ja, du har helt ret i tilfældet S-expressions vs M-expressions. Men S-expr's var tilgængelige først. Af det kan vi lære at tilgængelighed (som i availability) trumfer "skønhed". Som jeg husker det, var M-expr's tiltænkt at skulle oversættes til S-expressions som så kunne fortolkes..

Jeg gyser når jeg tænker på hvordan det har været at kode LISP på en teletype (papir eller monokrom) uden matchende parentes-highlight eller farve...

  • 1
  • 0
Torben Mogensen Blogger

Jeg gyser når jeg tænker på hvordan det har været at kode LISP på en teletype (papir eller monokrom) uden matchende parentes-highlight eller farve...

Det har jeg gjort, og det er ganske rigtigt tidskrævende at tælle parenteser osv. Den bedste løsning var at bruge hyppige linjeskift med indrykning og sætte matchende slutparenteser enten på samme linje eller med samme indrykning som startparenteserne. Nogle programmører havde en stil, hvor alle slutparenteser sættes på samme linje, men det gjorde det sværere at sikre, at antallet var rigtigt. Det blev ikke bedre af, at nogle LISP-dialekter lod et ] lukke alle åbne parenteser. Så var det bedre i de dialekter, som tillod både runde og kantede parenteser til samme formål, men krævede, at de matchede. Det gjorde det nemmere at tælle og gav også lidt sikkerhed mod dumme parentesfejl.

  • 3
  • 0
Ditlev Petersen

Der er vel nogle opgaver, hvor man kunne se en fordel i at kunne lave sub/superscripts og andet "fancy", nemlig matematisk tunge opgaver. Til administrativ databehandling, eller al anden flytten rundt på de samme data, vil det nok være dødens pølse. Det er mange år siden, jeg har set en potensopløftning eller en kvadratrod i forbindelse med mit arbejde. Og så svært er det ikke at skrive funktionsnavnet i stedet for at finde et kvadratrodstegn (alt + hvaderdetnudeter eller noget i en menu). I de fleste tilfælde tror jeg, at ulemperne langt vil overstige fordelene. Bortset fra for dem, der virkelig skal håndtere formler.

  • 1
  • 0
Jens loggo

Nu er kompetent softwareudvikling sjældent en enkeltmandsopgave, så det ødelægger lidt dit argument...

Principielt ja, i praksis: sjældent

Man har vel som regel på forhånd gjordt det klart, hvilken struktur man bruger, på sin arbejdsplads. Skulle man få noget kode udefra, som er anderledes struktureret, bør det ikke være det store problem at ændre det som ønsket, i eget programmeringsmiljø.

Jeg tror ikke der er noget stort problem her.

  • 0
  • 0
David Christensen

...men ofte kommer kode jo igennem mange sæt af udviklere over tid; somme tider endda mellem flere forskellige selskaber.

Jeg arbejder selv i den digitale bureau-branche, og det er ikke usædvanligt, at jeg får en bunke kode som har været forbi et andet bureau først.

Når dét sker, er det så meget mere irriterende, når koden er sat op på en eller anden psykotisk måde som én udvikler synes er fiks fordi den hjælper ham.

Så er det da at foretrække, at koden er opsat på en standardiseret måde, i stedet for jeg skal gå igennem 500+ kodefiler (det er ikke usædvanligt) og rette dem til på min præcise yndlingsmanér—for så blot at det samme skal gøres, når engang projektet passerer væk fra mig.

Det er kunden også gladest for i sidste ende, da de så skal betale for færre af mine timer (enten fordi jeg ikke behøver rette layout til, eller fordi jeg ikke behøver bruge længere tid på at sætte mig ind i det tidligere udviklingsteams præferencer).

Forudsigelighed ved layout er en af de absolut vigtigste ting, når man programmerer ting, der er lidt større end småscripts...

  • 1
  • 0
Palle Simonsen

For 30 år siden brugte jeg Xerox Interlisp D (Dolphin) med Syntax Highlightning i B&W med fede nøgleord og kommentarer i kursiv i en structure editor der kendte sproget. Det samme kunne man finde på de Apple Liza maskiner der var konverteret til Mac's, hvor Pascal blev vist og editeret på samme måde - iøvrigt med en sjov pegefinger, når man singlesteppede sig gennem programmet i debuggeren. Min hukommelse kan jo spille et puds, men jeg mener bestemt, at det var med proportionalskrift.

Hvorfor er det lige, at vi her - 30 år senere - skal diskuterer monotype vs. propertional og syntax highligtning? Er der da slet intet sket i de mellemliggende år?

  • 1
  • 0
Palle Simonsen

@David: Læste du min kommentar?

Iøvrigt, for at kommenterer på en anden del af artiklen:
Der er eksisterende sprog der definerer specielle tegn - APL er et eksempel. APL er dog på mange måder et 'writeonly' programmeringssprog hvor skrivehastighed er ofret til fordel for læsbarhed.

Iøvrigt er der programmeringssprog, der anvender brøker - f.eks. varianter af lisp, hvor man kan skrive (* 1/3 2/3 5/6). osv.osv. af samme tanget - men det er lidt pointeløst så ...

Det er en interessant vinkel i artiklen at udsøge, om man ved specialtegn, grafiske elementer iblandet 'almindelig' syntax osv. kan udvide programmeringssprog på en hensigtsmæssig måde, så de er lettere at forstå og læse. Et par skrækeksempler trænger sig på -Visual Age for at være specifik. Men måske faktisk et værdigt forskningsområde der fortjener en bedre medfart en denne diskusion.

Så se bort fra opstødene før og 'back on track' :)

  • 0
  • 0
David Christensen

Du har ret i der som sådan ikke er sket noget :-)

Derudover vil jeg så bare godt påpege det åbenlyse: At sådanne sprog aldrig har nået en så stor popularitet og kritisk masse, at de er kommet udenfor specialformålenes område (selv hvis du inkluderer Mathematica, Maple osv.; de fleste jeg kender, der anvender det, bruger monospace-fonts dertil)—som du også selv påpeger fx med Visual Age (som i øvrigt også var sløvt på grund af den ret langsomme Smalltalk-VM, men det er en anden historie...)

Jeg tror at årsagen er, at det er typisk ret upraktisk at skrive sådanne symboler, og det er nu engang belastende med kontekst-paletter man skal muse igennem. Jeg når gerne 100WPM på et tastatur, næppe så meget som 10 med en mus... Alternativet er sådan noget autoformattering hvor man skriver -> og får →...

  • 1
  • 0
Michael Zedeler

Jeg synes at forslaget ligner en løsning på udkig efter et problem.

Det kan godt være at 1/2 kan stå fint med en vandret brøkstreg, men jeg er stærkt i tvivl om det reelt øger læsbarheden af helt almindelig kode, når man altså ikke skriver programmer som laver en hel masse matematiske beregninger.

Min erfaring er at rigtig mange programmører virkelig slås for overhovedet at blive gode venner med deres editorer, som de virker i dag. Hvis man skal tage fat i HCI-delen af det at programmere, synes jeg det ville være væsentligt mere relevant at undersøge om programmører overhovedet kan finde ud af at bruge de eksisterende værktøjer.

Jeg har f. eks. set mange programmører der har

...utroligt svært ved at flytte blokke af kode uden at introducere syntaksfejl
...der ikke forstår at inkonsekvent formattering fører til ulæselig kode og flere fejl
...der tror at DRY er noget tørt eller også noget med en høj alkoholprocent
...der ikke kan finde ud af lave en diff som ignorerer whitespace
...der ikke forstår at det betyder noget om man gemmer i UTF-8 eller ISO-8859-1
...og når de opdager forskellen, stadigvæk ikke kan få deres editor til at gøre det rigtige
...der ikke ved hvordan man søger i mere end en fil ad gangen
...og endda sjældent gør dét, selv i kodebaser, de ikke kender og hvor de blot skal lokalisere en enkelt specifik variabel eller metode
...og heller ikke ved at den bedste og absolut mest sikre søgefunktion hedder grep

Nej - jeg har ikke lyst til at prøve at vedligeholde programmer hvor man har adgang til "rich text", hvis det er skrevet af den slags udviklere, og det er desværre fuldstændig uundgåeligt.

  • 4
  • 0
Log ind eller Opret konto for at kommentere