Oops, I did it again...

Jeg er ganske enig med PHK i, at der ikke er grund til at holde sig til ASCII. I min blogserie om programmeringssprogsdesign valgte jeg f.eks. at bruge bl.a. Unicode symboler og subscripts.

Fortress (http://en.wikipedia.org/wiki/Fortress_%28programming_language%29)er i øvrigt et andet eksempel på et moderne sprog, der går ud over ASCII i sin notation. Fortress tillader dog, at man kan skrive sine programmer i ASCII, men de kan vises og skrives med matematisk notation (det sidste kræver dog specielle værktøjer). Min ide var at bruge en delmængde af HTML, så programmer kan vises i en browser og skrives med en HTML editor -- eller i "rå" HTML med emacs, vi eller andre ASCII editors.

Jeg har siden jeg startede med at lege med computere undret mig over, hvorfor keyboards ser ud som de gør (Ja, jeg har senere fundet ud af den historiske grund). Eftersom QWERTY og DVORAK tastaturer er blevet 'standarden' for at interagere med computeren, 'tør' producenterne ikke satse på at forbedre dem væsentligt.

Jeg ved hvor meget et dansk QWERTY tastaturet arbejder imod mig, når jeg skal skrive kode (jeg rammer med 70% nøjagtighed { og } og ca. 60% []). Med en tastehastighed tæt på 300 tegn i minuttet, når jeg skriver længere dokumenter, er mine 50-60 tegn i minuttet i kode ikke imponerende. De konstante fejlrettelser koster mig flow. Jeg ville super gerne eksperimentere med skrivekugler optimeret for et programmeringssprog - hvis bare de kunne findes...

Jeg har det ligesådan med hvad end udviklingsværktøj jeg arbejder med - jeg er villig til at gå ret langt for at få mere overskuelig kode. Igen arbejder IDE'et imod mig. Jeg har to skærme - jeg kunne sætte to mere op i morgen, men IDE'et udnytter dem ikke godt nok. Bare det at udnytte den sekundære skærm kan ikke lade sig gøre... Jeg synes det ville være super elegant med color-coding, så blokke af kode bliver markeret med baggrundsfarve - og private metoder/funktioner bliver vist på en af de sekundære skærme.

Jeg er såmend ikke uenig i at visse ting kunen gøres nydeligere ved at anvende unicode. Men lidt med mådehold tak, vi skal også gerne kunne taste det ind uden at skulle ty til store tegntabeller.

For hvad har jeg lige vundet ved at skulel taste en mystisk tastekombination for &#21d2; (Rightwards Double Arrow) når '=>' har kunne gøre det hidtil? Og skal jeg pludselig til at tage hensyn til at vælge mellem syv forskellige højre-pile istedet for idag to forskellige?

Når jeg ser på kodeksemplerne på http://projectfortress.sun.com/ så ser det langt hen af vejen også ud til at den 'pæne' udgave mere er syntax-highlightning end en egentlig udvidelse af mængden af tegn vi vælger syntaks ud fra.

Men ærlig talt så mener jeg ikke at nyskabelser kommer ved at fedte syntax. Næh, lad og få nogle nye interessante 'betydninger' og så være åbne over for at bruge unicode til at udtrykke dem. Men at diskutere unicode issoleret er kedeligt.

Men for guds skyld, tænk på at vi helst skal kunne skrive det let på et fysisk tastatur et par år endnu. Og så er der grænser for hvor mange pile jeg kan huske forskel på - Og ja, det gælder også når man skriver rigtige artikler i LaTeX.

Jeg føler trang til at citere Linus Torvalds:

if your typing speed is the main issue when you're coding, you're doing something seriously wrong.

Hvorfor er det ikke adopteret i alle programmeringssprog for længst ?

Godt spørgsmål. Mener du at Unicode-diskussionen er interessant for at besvare det? Er det virkelig mangle på tegn der gør at de færeste udbredte programmeringssprog har den slags typer?

Istedet for at fnidre med stråmandsargumenter for og imod Unicode, så lad os se på listen over features som programmeringssprog burde have. Så kan vi angribe myter og fordomme om at subtyper er skadelige.

Jeg tror det handler om at folk er bange for at validering kommer til at ske på køretidspunktet og så bliver det langsomt og svært at fange fejl. Og det tror jeg sjovt nok også gør sig gældende selvom folk skriver i sprog der alligevel kræver store fede køretidsmiljøer.

Jeg tror at fordomme og konservatisme angribes bedst punkt for punkt. At bare angribe at folk er konservative kan i bedste fald få dem til at sige 'Nåja, det er måske dumt' med det ændrer ikke deres handlinger.

Vi er enige så langt at LOC er en dårlig metric - min pointe var også nærmere at min tastehastighed mere er et udtryk for om jeg kan holde mit flow. Det er afbrydelser i flow, der er mit problem - ikke hvor mange tastetryk jeg kan lave.

Jeg vil sige at jeg kender flere hardcore nørder der bruger Dvorak layout på Qwerty tastaturer, og jeg møder stor entusiasme for nye sprog og paradigmer blandt seriøse programmører.

Når det er sagt tror jeg problemet med at man holder sig til ASCII-tegn at programmører ikke så gerne kaster sig over GUI-design, hvilket vil være påkrævet med Unicode, og som Torben Mogensen nævner, matematisk notation.

PHK, dit eksempel med unicode-tegn i ACM-indlægget virker mig lidt abstrakt. Jeg kan til gengæld godt se hvorfor man ville have matematisk notation i sin programmering - det ville muliggøre sprog hvor man ikke ville være nødt til at tænke over hvad der skete under algoritmen - men det er nok et scenarie du helst ikke vil tænke på :)

En mulig implementation ville være at bruge funktionalitet fra Open Office idet det både har et XML-outputformat man kan have både kode, formler og diagrammer i samt formatteringsværktøjerne til at lave samme. Man kunne med et sprog der benytter de elementer faktisk godt forestille sig en artikel om en algoritme hvor implementationen var en del af dokumentet uden det blev ulæseligt.

For at få adgang til flere tegn fra et Qwerty keyboard ville man nok være nødt til at have acceleratorer eller flere 'lag' for tasterne. I forvejen modsvarer f.eks. de græske tegn flere af de latinske ('o' for omega, 'd' for delta osv.) - jeg skifter selv mellem amerikansk og dansk layout fordi førstnævnte er mere behageligt når jeg programmerer.

Ulempen vil så være at det nok ville gøre dataloger endnu mere uvante indenfor 'praktiske' sprog som C.

Ada har f.eks muligheden for at deklarere en heltalstype med et specifikt legalt interval:

type Month is range 1 .. 12;

Hvorfor er det ikke adopteret i alle programmeringssprog for længst ?

Ada har fået denne konvention fra Pascal, som også tillod den slags typer som indeksmængder for tabeller, f.eks.

[code=pascal] neighbours : array[-1..1,-1..1] of real; [/code]

Og, jo, det er bestemt en god ide (hvis det bliver checket, at værdierne rent faktisk ligger i det rigtige interval). Pascal ødelagde det lidt ved også at have en maskinafhængig integer type (defineret som minint..maxint, hvor de to konstanter er maskinafhængige). Det havde været bedre at lade integer være ubegrænsede heltal (som man ser det i f.eks. Haskell) og lade alle begrænsede heltalstyper være specificerede med intervaller.

C er på mange måder et tilbageskridt fra Pascal, som havde mange ting, jeg ofte savner i C. Udover intervaltyper kan følgende nævnes:

• En "rigtig" boolean type.
• At man kan bruge alle begrænsede typer (som f.eks. char og enumererede typer) som indeksmængder i tabeller.
• Indlejrede funktionserklæringer.
• Call-by-value overførsel af records og tabeller.
• Mængdetyper.

Pascal havde dog nogle irriterende begrænsninger (kun sekventiel i/o og at tabeller havde compiletidsbestemt størrelse), som de fleste compilere fandt måder at omgås. Disse udvidelser var dog ikke standardiserede, så der blev for meget fragmentering i sproget.

Hold da op mand...?

Lad os starte fra en ende af. ASCII er 'tegn' fra 0-127, hvor de første 32 er kontroltegn. ÆØÅæøå manglede i det danske tegnsæt, så man indførte substitution (stadig 7-bit). (Her brugte vi HP's Roman-8), men så kom IBM med deres 'fadæse' CP437, hvor der manglede ø og Ø, hvem husker ikke 'Yen' og 'cent'.

Nu er vi ovre i 8-bit, og med printerne kom PC8 og PC8DN tegnsæt, men her operer man stadig med 8 bit, og codepages - dvs relationen mellem værdier og glyphs.

Ansi, eller ISO 8859-1, eller Western Latin løste stort set hele behovet i den vestlige verden, men stadig 'codepages'.

Unicode - handler derimod om codepoints vs. glyphs, og er eentydig.

MS startede med W95 med UCS2, som en et encoding scheme, men begrænsede sig til 65536 codepoints.

Med Win2K (eller måske SPx) gik man over til UTF-16, som også er et encoding scheme.

Disse encoding schemes er fine nok til internt(programmeringsmæssigt) brug, men har den ulempe, at ethvert tegn fylder(mindst) 2 bytes.

Med XML (i '90-erne) indførte man derfor utf-8 som encoding scheme, da det er perfekt til 'wiredata', herunder 'filer'.

Det er en multibyte encoding, og er særdeles uegnet til databehandling, men fylder mindst, da de mest almindeligt brugte karakterer (ASCII) fylder 1 byte, og byteværdien=codepoint.

Endvidere er de næste codepoints (128-255) identisk med iso-8859-1/iso-8859-15, eller som (vistnok anbefalet) windows-1252.

(Den opmærksomme læser vil vide, at eks. FF viser de samme glyphs uagtet hvilket af disse 3 charsets der er angivet).

Da de første 256 codepoints er identiske, vil dem med programmeeringserfaring se fordelen ved UTF-16 (eller højere).

UCS4 ville måske være optimalt (performancewise), men det kræver noget mere memory, så igen er det trade-off's.

Og det er stort set alt - der findes ikke en universel løsning, der tilfredsstiller alle.

Der er faktisk et rigtigt lækkert keyboard layout her: http://xnybre.dk/?p=keymap Det virker til linux, og andre ting der bliver xorg.

Der er absolut ingen forbindelse fra Pascals array-index til Adas heltal.

Pascal tillod ikke kun intervaller som tabelindeks, men også i typer, f.eks.

[code=pascal] type Month = 1 .. 12; [/code]

Tabelindeksmængder i Pascal er blot typer. Grammatikken siger (citeret direkte fra "Pascal User Manual and Report" af Wirth og Jensen):

::= array [ {, } ] of

::=

::= | |

::= ..

::= ( {, } )

Dette her keyboard har jeg kodet mange gode programmer med, man vænner sig lynhurtigt til tegnenes placering. IBM lavede disse keyboards med IBM's sædvanlige fremragende mekaniske funktion. Se et eksempel her --> http://www.wickensonline.co.uk/apl/unicomp-apl-top-large.jpg

Lidt sker der da rundt omkring. F.eks. har Microsoft haft stor fokus på stabilitetsproblemer i device drivere, som typisk udvikles i C. Derfor har de indført diverse muligheder for annotationer på parametre, variable m.m. Dette er knyttet tæt sammen med byggemiljøet. Når man kompilerer sin driver med Windows DDK'ets "build" kommando, så startes automatisk et job i baggrunden der udfører statisk analyse af koden. Selve analysen kan godt tage noget tid, og det er derfor smart det kører i baggrunden. Hvis den så finder noget kommer der en notification i proceslinien. Den checker for memory leaks, manglende overholdelse af diverse driverkonventioner, overtrædelse af ens egne erklæringer osv. På den måde er den statiske analyse en fast integreret i byggeprocessen man får "gratis" med - og udvikleren bliver straks mindet om det når der er problemet, så de kan tages i opløbet. Erfaringsmæssigt er det en tung og kedelig opgave at tage et gammelt projekt, der ikke har overholdt konventionerne, og så gå igennem de hundredevis af advarsler der er tilstede. Der er også mange udviklere (jeg inkl.) der kvier sig lidt ved at rette sådanne findings i legacy kode man har overtaget, idet der er en risiko for nye problemer i marginalsituationer, der ikke altid kan fanges i tests, og som kunden utvivlsomt vil kræve en forklaring på hvorfor pludseligt er opstået. Jeg retter derfor kun hvis jeg med sikkerhed kan sige det kan være et (sikkerheds-)problem i praksis, og kun efter en aftale med kunden. Det er selvsagt et tungt forløb at gå igennem for hundredevis af warnings.

Det er langt nemmere at rette denne type fejl inden koden er i produktion. Det er også mere produktivt, idet visse typer af fejl (f.eks. signed vs. unsigned) kan kræve omfattende ændringer i koden at udbedre, idet de har en tendens til at påvirke mange kodesteder og endda protokoller, dataformater m.m. der går udover modulet selv!

Hvorfor kan man ikke bruge typografi og billeder i kildetekster? Det er ikke ualmindeligt at se "funktions-hoveder-kommentar-blokke" med masser af /*******/ omkring så det nemt fanger øjet. Det ville jo give mere mening at benytte større skrift til "overskrifter" og måske endda indsætte et billede eller to til lige at forklare hvordan denne state-maskine virker. Et billede siger jo mere end tusind ord - og dokumentation der vedligeholdes separat har det med ikke at blive vedligeholdt (eller ikke at blive læst).

Problemet er nok historisk og med en hvis mængde inerti indblandet. Grunden er formentlig, at hvis du vil innovere beskrivelsen af programmer, så skal du også samtidigt innovere værktøjet til at lave beskrivelsen i.

Nye sprog koncentrerer sig ikke om det beskrivelsesproblem, og derfor skal de nødvendigvis virke i vi/emacs. Og så rammer laveste fællesnævner: Alt andet end unicode/UTF-8 kræver mere innovation af værktøjet - inklusive farvekodning (som ikke er nemt at skrive ud på sort/hvid-tryk by the way).

De fleste sprog er gamle. Du kan bare se på de sprog jeg typisk hacker: Python (1991), C (1972), OcaML (1996), Haskell (1987) og Erlang (1987). Da deres syntax blev defineret fandtes Unicode slet ikke, og det har inerti: Du ændrer ikke i kodestilen på et eksisterende projekt (Med mindre du accepterer at din revisionskontrolsarkæologi går galt). Så gevinsten ved at skifte opvejer ikke ulemperne - også for nye projekter. Lokale ekstrema.

Nye sprog, og opdaterede sprog, accepterer naturligvis unicode. GHC haskell compileren lader dig indtaste unicode-symboler. Agda (et proof-assistant legetøj) ligeså. Uden ændringer i tastaturlayout er dette ikke en farbar vej (jeg hader at skulle indtaste ting i Agda - og det virker kun i emacs fordi jeg har sat den op til det. Den her textbox i V2 kan ikke...).

Så er der din ide om at lave input-devicet om. Det har muligvis en mulighed for at opnå traction så snart at den typiske computerbruger har brug for mere end et vesteuropæisk tastatur eller ikke længere har brug for det fordi hans/hendes smartphone dækker. Skjult faktor er at kineserne løser problemet. For øger du tegnmængden betragteligt, så konvergerer du nærmere mod et asiatisk tegnsæt.

Og det tror jeg er den skjulte variabel: For mange tegn er også et problem.

For mange tegn er også et problem.

Bestemt. Ikke kun af hensyn til indtastning, men også af hensyn til læseren: Hvis der er 200 forskellige tegn med hver deres betydning, så kan det være svært at huske.

Det er dog ikke bedre, hvis der er 200 forskellige ASCII-tegnkombinationer med hver deres betydning. Det er næsten værre: Hvis tegn sammensættes, kan det være svært at se, om de skal tolkes som et enkelt symbol eller flere separate symboler. I C er udtrykket a---b f.eks. svært at læse: betyder det (a--)-b, a-(--b), a-(-(-b)) eller noget helt fjerde? Ved at bruge tegn fra et større tegnsæt (f.eks. Unicode) kan man undgå sammensatte tegn, hvilket øger læseligheden.

Så moralen er: Brug ikke for mange forskellige symboler, men gør dem, du bruger, til individuelle tegn, selv om du skal bruge et udvidet tegnsæt.

Lad mig først give PHK helt ret. Og lad mig så gå videre til et eksempel..

Advarsel! Ikke for sarte sjæle: http://redpixel.dk/IsabelleEvil2.png http://redpixel.dk/IsabelleEvil.png

De to screenshots er fra en såkaldt proof assistant ved navn Isabelle. Det er ikke programmering som sådan, og det er stadig langt fra den verden PHK ønsker sig. Men det er en god illustration af hvad han mener. Og noget af det man ser i første screenshot er faktisk syntaks-beskrivelsen af et modelsprog. Men hvad i ser i de screenshots er desværre ikke unicode. Underlaget er stadig ASCII, med en symbol-fortolker ovenpå. Men det er nok også udviklet af nød. Mekanisk bevisførelse er så langhåret at jeg sandsynligvis ville have begået seppuku for et halvt år siden hvis jeg kun kunne se det i ASCII.

Men nøden har åbenbart ikke været der når vi snakker programmeringssprog? Eller måske har folk bare ikke lagt mærke til nøden? Er vi blevet helt følelsesløse som programmører?

Efter at have arbejdet med Delphi og VisualStudio med dertil understøttede sprog, føler man sig sat tilbage til de glade 80'ere når man rammer udviklingsverden i Linux. Det er ikke gået op for mig før nu at ASCII var synderen.

Selv om Linux i vid udstrækning præsentere innovation og nytænkning så er det lige omvendt inden for udviklingsværktøjer og sprog. Selv værktøjer til indlejerede systemer hvor output er målrettet Linux, tilbydes primært til Windows.

Efter lang tids research, er jeg nået til den konklusion at Linux simpelthen er for umodet til at virke som udviklingsplatform selv med Linux som afviklingsmiljø. Det hænger simpelthen ikke sammen økonomisk. Det er nærmest tragisk.

Når jeg en gang imellem sidder og fedter med print statements i SQL under debugging, undre jeg mig over man ikke er kommet længere i den verden. Et moderne IDE med code inspection, single step debugging, refactoring tools, code analysis ol. øge både produktiviteten og kvaliteten betragtelig. Det har SQL udviklere og så en ganske stor del Linux udviklere åbenbart stadig til gode at opdage.

Nu ved jeg ikke helt hvad SQL udviklere og Linux udviklere er, men til de sprog jeg typisk benytter (Java, Ruby, Scala) er IntelliJ Idea ganske fremragende. Om det giver Visual Studio baghjul skal jeg ikke kunne sige, da jeg ikke har andet end leget med VS.

...Men altså hvis du foretrækker Windows, så ville det da ikke give mening at skifte til noget andet bare fordi. Selv foretrækker jeg at have en fornuftig terminal.

Carsten Sonne Larsen:

Efter at have arbejdet med Delphi og VisualStudio med dertil understøttede sprog, føler man sig sat tilbage til de glade 80'ere når man rammer udviklingsverden i Linux. Det er ikke gået op for mig før nu at ASCII var synderen.

Sådan kan man godt forsøge at stille det op.

Linux-udviklere, og open source udviklere generelt, er i høj grad selvhjulpne. Og da de generelt heller ikke lader sig kyse af kompleksitet og udfordringer, er det nok lidt forfejlet at kalde Linux udviklingsværktøjer for noget der "ikke er kommet videre". De passer til dem der har udviklet dem og bruger dem, inklusive al den tilgængelige kompleksitet.

Hvis man kan rumme kompleksiteten af sine kode-konstruktioner inde i sit eget hoved, er det hundredefold mere effektivt end at skulle arbejde gennem et smalt GUI for at forstå sin egen kode, og håndtere den efficient udfra forståelsen.

Det jeg ser PHK bede om, er 20-30 ekstra oktaver på sit flygel. Det er selvølgelig ikke noget han gør for Delphi-koderens skyld.

Hvis man ikke blot kan rumme sin kodes eksisterende kompleksitet inde i sit hoved, men har ekstra kapacitet til at danne yderligere kompleksitet, som man ikke kan formidle til maskinen pga et snævert kodningsinterface, så er tiden selvfølgelig kommet til at åbne diskussionen om at udvide interfacet.

Det må i sandhed være de færreste der kan få noget ekstra ud af disse mange ekstra oktaver, og den tilhørende kompleksitet. Så der er ingen der siger at Delphi-koderen skal smide sit nuværende IDE væk.

Men det er da et godt skud at åbne snakken om, at der kan være et stort uudnyttet potentiale i den Unicode real-estate og kode-farvning vi har adgang til.

Snakken er dog nok mest forbeholdt dem, der både kan forstå og håndtere den medfølgende kompleksitet.

...Men altså hvis du foretrækker Windows, så ville det da ikke give mening at skifte til noget andet bare fordi. Selv foretrækker jeg at have en fornuftig terminal.

Kritikken er ikke udtryk for mine personlige præferencer. Derimod er jeg fustreret over at skulle ty til Visual Studio som 'General Purpose C' udviklingsmiljø. Det er en anden problemstilling end den PHK fremføre. Lad os gemme den til en anden god gang.

For 25 år siden, var kildefilerne tekstfiler. Det er de stadig i dag, 25 år senere. Udviklingsmiljøer og biblioteker har været igennem en omfattende udvikling. Programmeringen sker dog stadig i tekst. Forsøg med visuel programmering har vist sig at være en svær vej med flere begrænsninger end muligheder. Det er endnu vanskeligere end med tekst at fortælle computeren hvad man vi have den til at gøre. Domænet bliver som konsekvens for snævert.

Det kan være ganske svært at formidle tanker om mål og hensigten til både computeren og den næste programmør som læser koden. En Objekt Orienteret struktur kan hjælpe til at udtrykke de overordnede linier. Med kommentar kan programøren udtrykke sig på menneskesprog. Det kan dog være endnu svære at forstå end det formaliserede programmeringsprog.

Som PHK selv er inde på, er vejen frem nye måder at udtrykke sig på. Tekst som primære medie ændre sig nok ikke foreløbig. Selv om farver ville være en rigtig god ide, tror jeg desværre det er for snævert og anderledes. Tiden og sprogene er for umoden.

Der er allerede en udvikling i gang: Abstraktion og syntaksukker gør det nemmere at vise hvad hensigten er. Budskaberne i sproget bliver langt mere koncentreret, både for computeren og for programøren. Samtidig smelter paradigmer som dynamisk og statisk typede sprog mere sammen. General Purpose sprog og Domain Specific Languages gennemgår samme udvikling. Herved får programmøren styrkerne fra flere paradigmer med mulighed for at udtrykke sig endnu mere præcist.

Det er den vej udviklingen vil gå. Abstraktionen vil til stadighed øges og paradigmerne vil smelte sammen med det formål at give programmøren bedre mulighed for at udtrykke sig så kort og præcist som muligt. Det hele krydret med lidt syntaksukker. Det vil vare mange år før teksfilerne afgår ved døden som kildekode. Mindst 25 år endnu.

Til de interesserede, havde Anders Hejlsberg et fordrag om emnet for et par år siden: Where are programming languages going?

Er edb-folk virkelige så bange for deres programmer, at de ikke engang tør tænke på bedre værktøjer ?

Ja! (utroligt men sandt). Jeg flipper ud over det på daglig basis.

Det korte svar er "i alle retninger". Der bliver lavet forsøg med visuelle sprog, ASCII-sprog, sprog med matematisk notation, OO-sprog, funktionelle sprog, procesorienterede sprog, parallelle sprog, dynamisk typede sprog, statisk typede sprog, domænespecifikke sprog, general-purpose sprog osv.

Det er dog de færreste af disse sprog, der når mainstream. For mange er det heller ikke hensigten: Et domænespecifikt sprog til et meget snævert domæne bliver næppe nogensinde mainstream, og andre sprog er udelukkende tænkt som forsøg.

Tendensen ser lige nu ud til at være multiparadigmesprog: Man tager elementer fra OO og funktionelle sprog, tilføjer [i]message-passing[/i] og gør sproget dynamisk typet, fordi man ikke gider skrive komplicerede typer og ikke kan finde ud af at lave typeinferens. Man sælger så de dynamiske typer som en fordel. "[i]Make a virtue of necessity[/i]", som de siger [i]over there[/i].

Carsten, har du prøvet f.eks. Eclipse?

Det korte svar er "i alle retninger".

Det er rigtig der bliver eksperimenteret rigtig meget for tiden. Set over en længere periode og i et bredere perspektiv, er tendensen dog helt tydelig: Abstraktionen øges og paradigmer smelter sammen med det formål at øge kvalitet og produktivitet.

DSL'er er i sagens natur nichesprog. General-purpose sprog derimod sigter mod at løse alle typer opgaver. Styrken er jo netop det brede domæne. Prisen er så at udtrykformen bliver vag. Der skal skrives meget kode for at udtrykke formålet i modsætning til domæne specifikke sprog, hvor det snævre domæne i vid udstrækning implicit definere formålet.

Carsten, har du prøvet f.eks. Eclipse?

Ja.

Det kunne være, at der var nogle ængstelige elementer i deres personlighed, der gjorde, at mange af dem blev "EDB folk" i første omgang. Computere er simple at omgåes. Noget mere simple end at forholde sig til fluktuerende kompleksitet i sociologien. :)

[quote]Carsten, har du prøvet f.eks. Eclipse?

Ja.[/quote] Ja.... Og uddybende? Hvad er det lige Eclipse mangler?

Der er forøvrigt også KDevelop.

Ja.... Og uddybende? Hvad er det lige Eclipse mangler?

Eclipse er fint. Intet ondt ord om Eclipse. Hvad syntes du om PHK's forslag med farver?

Her er et tastatur, hvor du selv bestemmer - det må da være optimalt:

http://www.daskeyboard.com/model-s-ultimate/

Der er absolut ingen forbindelse fra Pascals array-index til Adas heltal.

Ada er det sidste sprog der er designet, hvor hovedfokus var at skrive korrekte programmer.

Derfor gjorde man sig utroligt mange tanker om hvad programmøren skulle sættes til at forklare.

Poul Henning har indset, at Pascal havde interval-typer i typesystemet. Pascal opstod også i bestræbelser på at understøtte udvikling af korrekte programmer. Specielt om interval-typer og muligheder for i praksis at lave kontrol på oversættelsestidspunktet er der en relevant artikel:

WELSH, J. Economic range checks in Pascal. Softw. Pract. Exper. 1978.

Generelt savner jeg i denne tråd en skelnen i store træk mellem program og dokumentation. I programmer er det naturligvis et problem, at tekstkonstanter er snævert begrænsede af tegnrepræsentationen.

Farver og matematiksymboler er formentlig nyttige redskaber i løsninger på problemer knyttet til programdokumentation. Men da talen er om udviklingstendenser i programmeringssprog er det måske på sin plads at henvise til Donald Knuth's arbejder med 'literate programming', som foreslår at sætte dokumentationen i førersædet og skrive den således at programteksten trækkes ud derfra -- naturligvis med passende værktøjer.

Jørgen rammer et helt centralt problem i den måde software udvikles på i dag: Det formaliserede sprog som computeren forstår er ikke forenelig med det sprog som mennesker forstår. Endnu værre er det i out-sourcing projekter hvor den ene udviklers sprog ikke er forenelig med den anden udviklers sprog. Som konsekvens skal programmets formål, hensigt og fremgangsmåde udtrykkes i 2 eller måske endda 3 forskellige sprog. Når en ændring indtræffer skal de 2 andre forklaringer tilsvarende opdaters. Både udviklingsprocessen og den efterfølgende vedligeholdes lider under denne 2-3 dobbelte bogføring.

Hvorvidt problemet løses som Knuth forslår, ved at kondensere informationer fra et menneskeligt forståeligt sprog til et sprog der kan afvikles af en maskine, eller omvendt, ved at berige det formaliserede maskinforståelig sprog til et menneske forståeligt sprog, er knap så vigtigt. Det vigtigste er der findes en samhørighed.

Udvikling er så småt er startet. Til Visual Studio findes et stykke software, GhostDoc. Det er i stand til delvis at oversætte det formaliserede programmeringssprog til kodekommentar. Pt. er intelligensen begrænset. Benarbejdes bliver lavet af GhostDoc hvorefter teksten kan tilrettes. Desværre kan GhostDoc ikke finde ud af at rette i en tilrettet tekst.

Værktøjet er stadig meget umodent, men viser en vej til hvordan problemet kan adresseres. Igen, hvorvidt udviklingen går i Knuths retning eller i GhostDocs retning er knap så vigtig ift. at løse problemet.