Fortegnfejl i kompatibilitet

Hvis mit blodtryk steg 1 mm(Hg) hver gang jeg stødte på nogle paphoveder, der har brugt for meget energi på at være kompatible med gamle versioner og for lidt energi på at være kompatible med fremtidige versioner, kunne jeg komme på rumtur før Peter Madsen blot ved at bide mig hårdt i tungen.

En helt simpel opgave i mængdelære kan få enhver til at indse, at mængden af existerende software man kan være kompatibel med er endelig, mens mænden af fremtidig software i princippet er uendelig.

For 20 år siden var det "LanManager" protokollen, der uden nogen god grund skulle være kompatibel med SMB protokollen, i år er det IE6, 7 & 8 der ikke kan blive enige om hvordan en webside skal se ud.

Men princippet er det samme: for meget tænken bagud og for lidt tænken forud.

Hvis den nye IE kunne emulere de gamle versioner perfekt (inklusive crashes ?) så kunne man bruge det til noget, men når emuleringen ikke er perfekt, så bliver det blot endnu en pind til den kombinatoriske ligkiste der gør alle EDB projekter dyrere og dyrere for hver version der kommer.

Jeg har mødt en del af de web-mullaher fra Norge der udstedte en Fatwa over IE6 og manner hvor er de trætte af browserleverandørene, nej, ikke kun Microsoft, også Firefox, Opera og de andre mindre browsere.

Men i virkeligheden burde browserleverandørene også være grundigt trætte af web-mullaherne, for hvorfor fanden tænker de sig ikke om og laver deres web-sider noget enklere ?

"Bare fordi du har betalt for hele buen behøver du ikke at spille med hele buen" som talrige violinlærere har sagt igennem tiderne.

Men det er ikke kun indenfor browsere.

Programmeringssprog som C og C++ hænger fast i tjæresumpen af baglæns kompabilitet i en grad at ingen af sprogene har set væsentlige forbedringer i 15 år, kun lappeløsninger og et stadig stigende antal "clarifications".

Prøv lige at overvej, at C, sproget for den sande systemprogrammering, ikke har en anvendelig bitmap type, ikke kan specificere layout af datastructurer og ikke kan håndtere forskelle i byte-order.

... 40 år efter sproget blev opfundet.

Jeg finder det dybt ironisk, at der er så mange IT folk stolt reciterer "To Boldly Go..." når de i praksis har ryggen vendt direkte imod fremtiden i hele deres professionelle virke.

Mere Dr. Emmett Brown og mindre Indiana Jones, tak!

phk

Kommentarer (10)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Michael Schade

Prøv lige at overvej, at C, sproget for den sande systemprogrammering, ikke har en anvendelig bitmap type, ikke kan specificere layout af datastructurer og ikke kan håndtere forskelle i byte-order.

Når du skriver det sådan, så går jeg ud fra at det ikke er struct{} du har i tankerne, vil du forklare nærmere omkring hvad du mener med datastruktur i denne sammenhæng?

M.h.t. bitmap type, hvilket sprog håndterer direkte håndtering af bitmaps uden at du skriver support funktioner til?....på assembler niveau får du alligevel det du normalt skriver funktioner til i C.

Byte-order, mener du vel når du henter data på tværs af processor platforme hvor den ene anvender Big og den anden Little Endian?....d.v.s. at du vil have en facilitet i sproget for andre processorers opførsel eller for at man kan lave vilkårlige filformater?

  • 0
  • 0
Poul-Henning Kamp Blogger

De fleste private dialekter af C tillader dig at skrive ting som:

struct something {
int8_t foo @31;
uint32_t bar __bigendian @32;
...
}

og tilsvarende, så du kan overlade det til compileren at pakke data strukturer der er dikteret udefra ind og ud.

De fleste PCI master chips, netværks-controllere og den slags, har private data strukturer som device driveren skal fylde ud.

Kig på hvordan det foregår i en device driver idag, og overvej så hvor meget renere det kunne gøre hvis man kunne fortælle compileren hvad man foretager sig direkte, istedet for alle krumspringene.

En bitmap type kunne f.eks være en variant af enum konceptet, med logisk valg af operatorer:

bitmap frobozz {
this,
that,
something_else
};

I setedet for de evendelige:

     int flags;  
define FLAG_THIS 0x01
define FLAG_THAT 0x02
define FLAG_SOMETHING_ELSE 0x04

Problemet er ikke hvorledes det skal gøres, det kan intelligente menneske skrive ned hurtigere end de kan drikke en øl.

Problemet er at det ikke bliver gjort.

Poul-Henning

  • 0
  • 0
Anonym

M.h.t. bitmap type, hvilket sprog håndterer direkte håndtering af bitmaps uden at du skriver support funktioner til?

Nu ved jeg ikke helt hvad du mener med bitmap-typer, men hvis det er hvad Poul-Henning giver et eksempel på nedenfor, kunne man f.eks. udnytte at Ada kan pakke en tabel af Boolske værdier tæt og at alle diskrete typer kan benyttes til at indeksere en tabel med. Derudover er de normale Boolske operationer defineret på tabeller af Boolske værdier. Der er selvfølgelig også andre løsninger, afhængig af hvad formålet er.

  • 0
  • 0
Lars Lundin

Min brug af C bringer mig ikke så tæt på hardwaren at jeg oplever de nævnte begrænsninger, men det minder mig om en pudsig historie:

For en funktion med en integer parameter der blev brugt med bitvise kombinationer, f.eks. FLAG_THIS | FLAG_THAT, meddelte en kollega at uanset hvilke flag han kombinerede, så opførte funktionen sig altid som om han kaldte den med FLAG_THIS.

En nærmere inspektion af hans kode viste at han kombinerede sine flag med logisk or, og at han derfor altid kaldte funktionen med værdien 1.

Udover at påpege denne misforståelse, så foreslog jeg en regel for vores projekt om at integer flag, der kan kombineres med bitvis or ikke må defineres til værdien 1. Ideen er at den kaldte funktion hermed kan afvise værdien 1 som en fejl, der (typisk) er opstået ved brug af logisk or fremfor bitvis or.

Historien gjorde specielt indtryk på mig fordi den nu tidligere kollega ved et af vores første møder, hvor han så min K & R bog, meddelte at den havde han "transcended years ago" (arbejdsproget var engelsk).

  • 0
  • 0
Thomas Knudsen

Udover at påpege denne misforståelse, så foreslog jeg en regel for vores projekt om at integer flag, der kan kombineres med bitvis or ikke må defineres til værdien 1. Ideen er at den kaldte funktion hermed kan afvise værdien 1 som en fejl, der (typisk) er opstået ved brug af logisk or fremfor bitvis or.

Smuk løsning på et velkendt problem, men en løsning som jeg aldrig er stødt på før. Er den almindeligt brugt? (eksempler?)

  • 0
  • 0
Bjarke Dalslet

Hvis mit blodtryk steg 1 mm(Hg) hver gang jeg stødte på nogle paphoveder, der har brugt for meget energi på at være kompatible med gamle versioner og for lidt energi på at være kompatible med fremtidige versioner

Er jeg den eneste der kan se det sjove i dennne her sætning?
Host - Si - Host

  • 0
  • 0
Lars Lundin

Så mange år(tier) som C har på bagen, så må der være andre der har overvejet det samme. Hvis det skorter på eksempler, er det måske fordi problemet i realiteten ikke er så stort.

Efter at have genlæst PHKs ide om en bitmap type, forstår jeg endelig hvad ideen er. Sådan een ville jeg da bruge, hvis den var der, det ville jo hjælpe på type check (inkl. mulighed for advarsel om brug af logiske operatorer fremfor bitvise) og gøre koden mere selvdokumenterende.

Sproget udvikler sig jo med tiden, er det ikke muligt at bringe nye forslag til overvejelse hos f.eks. ISO? - hvis man ellers kan vente 10 år, eller hvad det nu er der går mellem deres standarder.

  • 0
  • 0
Andreas Bach Aaen

Hvor ville det være rart at kunne hårdkode, at structs skal være tætpakkede samt, at kunne angive hver enkelt felts længde i bits og endianness. Her tænker jeg på den mængde af programmer jeg i tidens løb har lavet, der skal fortolke IP pakker. Det er ikke uden bøvl ,at lave nogle gode C struct til at håndtere dette, når koden skal fungere under forskellige C compilere og virke på både big endian og little endian maskiner med 32 bits CPUer eller 64 bits CPUer.
C burde bakke lidt bedre op omkring disse hardware nære problemer. Det er vel netop i dette domæne at C har sin styrke.

  • 0
  • 0
Michael Coene

Hvad med HTML? Hvis man i starten havde lavet en tag som hed "hvis du ved hvad 'tag type X' betyder så vis <FOO> ellers vis <BAR>....

Sa skulle vi ikke skrive javascript i kommentar feltet nu...

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