Et liv blandt jubeloptimister

Hvis jeg engang bliver gammel nok og træt nok af computere, så skriver jeg en selvbiografi med titlen "Et liv blandt jubeloptimister".

Den konstante muzak i IT branchen er at "alting bliver bedre med den næste version", hvad enten det er hardware, software eller vapourware.

Vi skal have ny cpu'er med flere kerner (for halvlederproducenterne kan ikke finde ud af at lave hurtigere cpu'er).

Multiprogramming er svært og derfor øjner alle mulige absurde og kinky programmeringssprog morgenluft for deres mere eller mindre bizare syntax og model for samtidighed, fra Brinch-Hansens med god ret uanvendte concurrent pascal over Ada's "we-told-you-so" model til java, python, ruby osv.

Hvordan kan andre end IT branchens jubeloptimister, se det som et fremskridt at man har gjort programmering 10 gange så svært ?

Er denne jubeloptimisme der, trods 50 års vidnesbyrd om det modsatte, stadigt med ukueligt håb i de våde øjne, tror at gennembrudet er lige om hjørnet, i virkeligheden er et udtryk for dyb desperation over at vi ikke er nået videre ?

På næste lørdag fejrer vi 50 årsdagen for det første computerprograms afvikling på dansk jord og dansk hardware, men objektivt set, fejrer vi også at vores softwareudvikling stadig er bagud kompatibel med den metode Peter Naur brugte på DASK: Linie for linie, tanke for tanke.

Nogle få IT genier stikker engang imellem hovedet op over programlisterne med en ny ide, fra Negroponts kunstige intelligens ("Computer programmer dig selv til at ...") over Charles Simonyi's Intentional programming eller for den sags skyld "genetisk programmering".

Men det bliver bare aldrig til noget i praksis, er der overhovedet nogen her der stadig kan huske hvad "4GL" drømmen handlede om ?

Nej vel ?

Vi sidder faktisk stadig og koder, linie for linie og tanke for tanke.

Når folk som jeg, med 25 års erfaring i branchen, brokker os over de 6000 siders omfang af en specifikation, så er det fordi vi har erkendt at Dijkstra havde ret: "I have only a small brain, and know I must live with it.".

Jubeloptimisterne omkring mig kan ikke se problemet, 6000 sider vil være peanuts for den nye "Brain 2.0".

phk

PS: Læs denne uges karrieresektion i Ingeniøren, den tager et interessant kig på projektledere der stilles overfor umulige opgaver og som alligevel ikke siger fra.

Kommentarer (15)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Martin Rytter

Hvis jeg engang bliver gammel nok og træt nok af computere.

Umiddelbart lyder det godt nok som om der ikke er så lang tid til som der har været ... :)

Det er alt sammen meget godt phk.

Meeeen, er der nu ikke ind imellem sket en enkelt ting eller to der er værd at bemærke? Måske bare en lille ting?

Lad os nu bare tage dit eksempel med flertrådet programming. Det er jo ikke rigtigt at det ikke er blevet nemmere. Når alle folk pludselig taler om at det er så svært, er det jo kun fordi det pludselig er blevet noget flere har behov for. Med andre ord: Det er et nyt problem. Ethvert nyt problem er et fremskidt.

  • 0
  • 0
#4 Poul-Henning Kamp Blogger

Martin,

Folk der uden at trække på smilebåndet kan sige ting som "Ethvert nyt problem er et fremskidt." hører til i den klasse af jubeloptimister jeg skriver om.

Nej, nye problemer, specielt ikke de selvskabte er ikke fremskridt.

Nye løsninger er fremskridt.

At gud og hverman nu tror de har brug for flertrådet programmering, fordi KISS og software tools er gået i glemmebogen er således ikke et fremskridt, men endnu et tilbageskridt.

Helt uden anden input, end blot skiftet fra enkelttrådet til flertrådet programmering kan vi forudsige at det vil medføre mindre pålidelige programmer der hænger, smadrer data og generelt opfører sig uforudsigeligt.

Bare fordi Intel og AMD pludselig spytter flerkerne CPU-er ud, betyder det ikke at alverdens programmører har fået opgraderet hjernen.

Poul-Henning

  • 0
  • 0
#5 Flemming Sørensen

Handler det så ikke bare om at have et ordenligt design fra starten af, så man ikke behøver høre på folk der mener at problemer i sig selv er fremskridt?

Kristian Van Der Vliet skrev følgende, i den første i en serie af artikler om programmering, på Side 2 i SDN: "Sending messages between threads is what makes multi-threaded C++ so painless. There is no need for multiply threads to share state between themself. If there is no shared data, there is very little need for any locking. Each thread can be fully autonomous, sending and receiving Messages between themselves instead of attempting to juggle shared variables and avoiding deadlocks."

Som jeg forstår det, og som jeg har forstået det gennem de sidste lidt over 3 år, så er det hverken mere eller mindre besværligt, end single-threaded programmering...

  • 0
  • 0
#7 Martin Rytter

phk:

Måske udtrykte jeg mig uklart. Hvad jeg mente da jeg skrev "ethvert nyt problem er et fremskidt" er, at når man har løst et problem så kan man koncentrere sig om et nyt. Nye problemer er ofte kun relevante givet at gamle problemer er løst.

Fx.: Man har fundet ud af hvordan man kan lave processorer med flere kerner. Det er en løsningen på et problem (ikke nødvendigvis et problem alle har, men et problem nogen har). Det er imidlertid også skabelsen af at nyt: Hvis man vil udnytte dette nye påfund må man være i stand til at tænke flertrådet.

Der findes masser af lignende eksempler på at løsning af et problem medfører nye problemer. Det er denne proces al videnskab bygger på.

Jeg beklager uklarheden. Og jeg forstår hvis du misforstod mig.

Dernæst.

Jeg er fuldstændig enig med dig i at man skal gøre ting så simpelt som det viser sig muligt.

Jeg er også enig i at IT-branchen er alt for dårlig hertil.

Jeg er også enig i at flertrådet programming til langt de fleste formål er overflødigt.

Jeg er også enig i at 6000 sider er meget.

Jeg tror i det hele taget vi er meget enige når det kommer til mange helt konkrete ting.

Men.

Jeg synes blot du tegner et for dystert billede:

Det er jo ikke rigtigt at "programmering er blevet 10 gange så svært". Programmering er så let som aldrig før. Flere kan lære at programmere i dag. Og de problemer de bedste programmører kan løse er sværere end dem man kunne løse for 25 år siden.

Det er jo ikke rigtigt når du siger at "det bliver bare aldrig til noget i praksis". Der afprøves masser af nye ideer hver eneste dag og nogle af dem bliver faktisk til noget! Hvordan var det fx med udbredelsen af visionsystemer for 25 år siden? Hvor lang tid tog det at finde sin opspore sin fjerne familie i amerika for 25 år siden?

Der er altså sket rigtigt meget på meget få år. Det kan jeg ikke forestille mig du vil benægte. Find selv 50 år i menneskets historie hvor et vidensfelt har udviklet sig på samme måde som datalogi/it har gjort i disse år.

Ja. Meget kan gøres bedre. Rigtig meget. Men! Det er ganske enkelt ikke rigtigt at der ingenting sker. Det er ikke de samme problemer vi har i dag som vi havde for 25 år siden!

/mrj

  • 0
  • 0
#8 C Frigaard

Hej Flemming,

Checkede dit link ud, men som jeg kan se er der blot tale om en form for "message-passing" system, der er en-af-mange metoder til at distribuere software. Klart, det er et helt andet design end "shared-memory" systemer, som man typisk ser i flertråede programmer og hvor man normalt har direkte adgang til et fælles hukommelsesområde.

Med et message-passing system kan man køre programmer i hver deres proces, og hermed undgå overskrivning af hinandens data - direkte understøttet af hardwaren, og det er jo rart (på lidt bekostning af performance). Man kan også dele systemet ud på mange enkelte computere ala et cluster system, såsom en Beowulf cluster.

Men det fritager på ingen måde programmøren i at dele funktioner ud i parallelledele: det er besværligt, langsommeligt og fejlbehæftet En enlig processor med summen af alle underprocessorernes clockfrekvenser og ram er klart meget mere KISS.

Spørgsmålet er, hvilke dele af softwaren, der egentlig har behov for at køre på flere en een enkel processor (andet en spil)? Jeg skriver selv på nogle kosmologiske simuleringer, og har hele tiden overvejelsen om jeg skal bruge tiden på at forbedre algoritmen eller parallelisere den. Det er et typisk enten-eller spørgsmål!

mvh Carsten

  • 0
  • 0
#9 Mikkel Høgh

Jeg har lidt svært ved at se det fantastiske i multiprogrammering. For nylig blussede debatten om netop det op igen i Python-miljøet. Juergen Brendel skriver en lang snak om hvorfor han umuligt kan undvære en flertrådet udgave af Pythons interpreter. http://blog.snaplogic.org/?p=94

Han får det svar fra at det vil komplicere Python-interpreteren unødigt og gøre den langsommere, og at det derfor ikke er en acceptabel løsning. Men ingen argumenter kan overbevise ham om at det er tilfældet. Heller ikke det faktum at langt de fleste brugere af Python er 100% ligeglade om selve den virtuelle maskine er flertrådet.

I min daglige brug af næsten hvad som helst, både PHP og Python arbejder jeg ikke med flertrådede ting. I stedet starter man flere processer med apaches prefork MPM.

Så på den led er det da en fremgang med flerkernede processorer. Så kan man afvikle flere processer af gangen. Det er da positivt, men for mig som webprogrammør giver det meget lidt mening at lave flertrådede applikationer. Der er jo selvfølgelig altid nogen specielle applikationer som f.eks databaseservere og den slags som kan drage fordel af det, men det er utopi at tro at alle ting blive flertrådet.

  • 0
  • 0
#10 Deleted User

Principperne er de gode gamle, som jeg lærte for over 20 år siden. Jo en ting er blevet bedre: Værktøjerne I stedet for sort-hvide petrinet, så har vi fået farvede petrinet, se CPNTools fra Daimi i Århus.

Jeg kontaktede min lære i parallel programmering på DTU, Hans Henrik Løvengren, for at høre, om der var kommet nye principper i parallel programmering. Svaret var nej!

Jeg håber at rigtig mange kender til principperne i parallel programmering eller fler trådet programmering, som man kalder det her. For mange får brug for dem, når alle vores elektroniske dimser kan kommunikere.

  • 0
  • 0
#11 Jesper Louis Andersen

Først et postulat: Der kommer ikke til at ske det store ved flerkerneprocessorer. Langt de fleste anvendelser af IT-systemer har en "shared nothing" konstruktion, hvor hver enkelt process stort set kan arbejde isoleret fra de andre. Problemet opstår når der skal udveksles information mellem processerne.

Det eneste der sker er at landskabet bliver mere interessant at kigge på. Der hvor det bliver tungt at arbejde med software er de steder hvor der er stor deling "sharing" af data. Men jeg tror egentlig ikke det er så mange steder igen. Så længe databehandlingen kan hugges op i mindre bidder, kan man jo bare lade hver enkelt bid eksekvere på hver sin processor.

Der hvor det virkeligt gør ondt er i (UNIX) kerner, computerspil og andre programmer af samme klasse.

Seancen er lidt som AI i firserne: Hvis system/programmeringssprog Foo kan løse multiprogrammeringsproblemet, så bliver Foo det næste store. Problemet er bare, at det er hulens svært at løse. Et af de bedre bud på en løsning kommer fra Rob Pike:

http://tinyurl.com/32ddkb (Google Tech Talk -- Rob Pike -- Concurrency/MP in Newsqueak)

Rob er altid værd at lytte til.

Det er også på sin plads at nævne programmeringssproget Erlang (http://erlang.org), der siden 1987 har leveret en Message Passing model som ikke er et teoretisk forskningsprojekt, men har været anvendt til at skrive store softwaresystemer i, der er meget samtidige. 20000 - 30000 processer er ikke ualmindeligt i et Erlang program og har du snakket i telefon indenfor de sidste 10-15 år, er der en god chance for at Erlang har haft en finger med i spillet. Vi snakker her samtidige softwaresystemer med oppetider på 9 9-taller i procent (Ja, det er rigtigt skrevet). Grunden? Fordi programmellet er splittet op i mange små processer og nogle processer har det eneste formål at redde andre, hvis ting begynder at gå galt. Systemet har indbygget fault-tolerance og det gør at man får en interessant egenskab ved programmet: Små fejl har kun lille impact. Det er ualmindeligt i softwarekonstruktion hvor små fejl normalt får hele programmet til at foretage sig noget udefineret.

Erlang er dog ikke designet med det formål at lave hård number-crunching. Blandt andet har det sin utypede typedisciplin imod sig på det punkt.

J.

  • 0
  • 0
#12 Ulrik Gerdes

Poul-Henning :: Undskyld, men jeg har tilladt mig at låne lidt at den gode saft og kraft i dit indlæg i en intern (Closed Source)kommunikation indenfor mit lægefaglige område.

Mine bemærkninger (Closed Source)omfatter en uforbeholden veneration for jeres stil hér på Version2. Det ville være forfriskende og udviklende, hvis vi indenfor sundhedsvæsenet kunne gøre det samme.

Gad vide om man kunne få lidt assistance til at banke et tilsvarende website op? Jam'n --- jeg spør' bare, ikk'?

  • 0
  • 0
#13 Henrik Knopper

Uden at være særlig rutineret i programmering vil jeg påstå at det er lidt vrøvlet at påstå at programmering er blevet 10 gange så svært i løbet af de sidste 25 år.

Der er i dag 10 gange så mange mennesker der forsøger sig i kunsten og ikke alle er lige kyndige, så der bliver begået 10 gange så mange fejl og de fejl der bliver begået har 10 gange så store konskvenser, men det kan man vel ikke klandre de professionelle for?

Jeg er enig i at antallet af dilletanter på kanten at faget giver branchen som helhed et lidt blakket ry, men det er vel ikke værre end de dilletanter i jura- og konsulentbranchen der afstedkommer kontrakter, udbudsmaterialer og tekniske specifikationer på 6000 sider eller mere. (Gad vidst om de bruger 4GL værktøjer til udarbejdelsen???)

Så jubeloptimisterne må være dem der sidder i CYA til halsen og stadig tror de kan udrette mirakler. Dem troede jeg vi havde fået forvist til andre brancher.

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