Erlang-opfinder: Objektorientering er absurd

Det er fup og fidus, når det objektorienterede paradigme fortæller os, at verden består af objekter, som nemt kan modelleres i programmeringssprog, siger Erlangs opfinder Joe Armstrong.

Det er vås, når objektorientering fortæller, at verden består af objekter, som nemt kan modelleres. Det siger Joe Armstrong, opfinderen af det funktionelle programmeringssprog Erlang.

En meget bedre model er aktører, som snakker i munden på hinanden. Og det koncept spiller godt sammen med fremtidens multikerne-hardware.

Joe Armstrong er en energisk mand på 57, som tydeligvis var i sit es, da han sidst i september holdte fordrag for en stuvende fuld sal på JAOO-konferencen i Århus.

Han endte i Sverige i starten af halvfjerdserne da hans kone studerede skandinaviske sprog. Det blev til et job hos Ericsson, hvor der blev kigget på bedre måder at programmere telefoni på.

»Vi kiggede på moderne computere og prøvede masser af, og det blev så til et sprog.«

Det, der manglede i samtidens populære sprog var en naturlig måde at beskrive samtidighed på.

Erlang er på ganske kort tid blevet det nyeste og varmeste hype, og det er der en grund til.

Moores lov, version 2

»Sekventielle sprog vil køre langsommere år for år, og det er en historisk ændring,« siger Armstrong.

Indtil for et par år siden blev processorer hurtigere hele tiden, og det blev programmørerne vandt til. Nu skalerer computerkraft ved, at antallet af kerner i maskinen stiger. Det medfører, at man må splitte beregningerne op, så de kan fordeles på flere kerner.

Og der er gode nyheder i fremtiden, fortæller Armstrong:

»Antallet af kerner vil følge Moores lov. Og hardware-folket siger, at vi har én million processorer på én chip i 2019. Hvordan i alverden skal man programmere til det? Alle er på udkig efter løsninger, som kun kræver minimale ændringer, og nogen gange virker det ikke. Hardwarefolk siger, at multikerner repræsenter et paradigme­skift.«

Hvis man ikke har mod på at flytte sin kode til Erlang, kan man i stedet tage ideer fra Erlang og benytte dem i andre sprog, så som Actor-modellen.

»Erlang er et prima eksempel på, at actors fungerer,« siger Armstrong.

Armstrong sammenligner modellen med den måde, mennesker interagerer på: Mennesker taler til hinanden og har adskilt hukommelse, og man kan se, hvem der taler med hvem. Det objektorienterede paradigme giver Armstrong til gengæld ikke meget for.

»Objektorienteret design fortæller mig, at hjulene på en cykel har noget at gøre med hjul på en bil, og det synes jeg er absurd. Jeg kan ikke se sammenhængen.«

Actor-modellen er meget mere intuitiv, betoner han.

»To mennesker taler til hinanden, de sender meddelelser. Så jeg synes, det er meget nemt at modellere. Når vi over­fører det til software... så skriver softwaren sig selv!«

Armstrong køber ikke den ofte hørte påstand om, at objektorienterede sprog skulle være nemmere end funktionelle sprog.

»Jeg har undervist en hel del i Erlang, og jeg oplever ikke, at folk har svært ved det. Jeg synes ikke, det er svært. Og de fleste af de studerende synes heller ikke det er svært. Jeg synes ikke, objektorienterede sprog er nemmere. Jeg synes, de er usædvanlig komplicerede.«

Denne artikel stammer fra det trykte Version2.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (13)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Torben Mogensen Blogger

Jeg ved ikke, om jeg vil sige, at OO sprog er absurde, men jeg er enig i, at OO er en unødig kompliceret abstraktionsmekanisme, som er blevet oversolgt ved at bruge dagligdags ord som "objekt", "klasse" og "nedarvning" om begreber, der ikke har den store relation til det, disse ord normalt betyder. Det giver folk et falsk indtryk af genkendelighed, men vildleder mere end det vejleder.

Det er min overbevisning, at mindre end halvdelen af de mennesker, der lever af at programmere Java rent faktisk forstår dynamiske metodekald og nedarvning fuldt ud. Og jeg er bange for, at det endda er højt sat.

Jeg er til gengæld helt enig i, at OO er en ualmindeligt dårlig model til programmering af højparallelle systemer: Hele ideen om skjult lokal tilstand i objekter tvinger sekventiel udførsel af programmer, medmindre man eksplicit deler programmet op i processer, der kommunikerer med hinanden -- uden at denne kommunikation sker via tilgang til felter i objekter eller globale variabler. Og med de begrænsninger, er det sådan set funktionel programmering, man laver.

Jeg er til gengæld ikke helt overbevist om, at Erlang-modellen skalerer til millioner af processorer. Der tror jeg mere på noget som Google's Sawzall (http://labs.google.com/papers/sawzall.html).

  • 0
  • 0
Carsten Frigaard

Tråden med funktionelle sprog følger en tendens i tiden: æhh, det her OO hjælper da noget men er ingen "silver bullet" (for at benytte et software-mytisk udtryk fra Brooks).

Nu udgør nedarvningsmetoderne en mindre del af multiparadigme sprog som f.eks. C++, men jeg er egentlig selv overrasket hvor lidt brugbar OO-nedarvning i praksis er! Og den meget påståede genbrug af kode har jeg sjældent set meget til!

Generisk programmering har sjovt nok vist sig meget mere anvendelig og "gen-brugbar" end nedarvning...men igen afhænger det af applikationen: i matematiske modeller er der f.eks. uhyre lidt gavn af OO/nedarvning og uhyre ideel brug af generisk programmering.

Generisk programmering er også langt mere fleksibel (kræver ikke et helt inteface for at arve) og modulariserbar (template specialization: funktioner kan blive raffineret på typeniveau) end gammeldags nedavning.

Den åbenbare konklusion på OO-nedarvning må snart hedde: skuffende!

Og så kan andre sprog, der vil redde verden, komme på banen...

mvh
Carsten

  • 0
  • 0
Carsten Frigaard

Eller stillet over for valget "is-a" (nedarvning) eller "has-a" (embeded member variable) er "has-a" som koncept nemmere at forstå og vedligeholde

Hvilket så egentlig betyder at indkapsling er meget mere nyttigt en nedarvning, ikke!

mvh
Carsten

  • 0
  • 0
Peter Nørregaard Blogger

Til de tidligere kommentare: Arv var måske set som håbet for udvikling tilbage først i 1990'erne, men i dag vil ingen begavet model specificere nedarvning i mere end 2-3 niveauer.

Styrken i OO ses vel egentlig bedst udtrykt i design-patterns. En af de grundliggende designregler for et godt pattern er "favor aggregation over inheritance".

Så at sidestille OO med nedarvning, som Joe Armstrong gør - forhåbentlig af rent retoriske årsager, dumhed kan det nok ikke være - er ikke retfærdigt over for OO.

  • 0
  • 0
Jonas Kongslund

Joe Armstrong om OO:
"Why OO Sucks"
http://www.sics.se/~joe/bluetail/vol1/v1_oo.html

Mere interessant er Ralph Johnsons syns på Erlang:
"Erlang, the next Java"
http://www.cincomsmalltalk.com/userblogs/ralph/blogView?showComments=tru...

Johnson synes det er synd at Armstrong benægter at Erlang har noget med OO at gøre eftersom aktørmodellen i høj grad er relateret til OO.

  • 0
  • 0
Peter Nørregaard Blogger

... tja, artiklen er som Jonas implicit skriver ikke voldsomt interessant. Personligt kunne jeg på stående fod finde svage side ved alle hans "objections" som gør at de efter min mening ikke holder vand og i stedet må betragtes som et mindre seriøst partsindlæg.

Men Joe Armstrongs pointe med at der er brug for et sprog der effektivt kan anvende parallel hardware (og på sigt en massiv parallel hardware), se dét er det interessante. Fx. arbejder Anders Hejlsberg og andre i MS med at forsøge at håndtere den udfordring i kommende versioner af .Net. Spændende at se hvad det betyder for OO-programmeringsparadigmet fremover.

  • 0
  • 0
Jens Madsen

Jeg er helt enig i, at C++ er fra en tid hvor parallelisme ikke fandtes. Det forstår at reklamere, og beskriver dagligdags ting som for enhver forekommer parallele, som noget der af natur skulle være OOP - der jo er sekventielt. Dette leder til, at ting der simpelt kunne beskrives parallelt, bliver sindsygt uigennemsigtigt, og alligevel er risiko for, at når et objekt starter, så kan en anden ikke køre.

Fra før C, var ting som stabilitet ikke så væsentligt indenfor programmeringen da det var en selvfølge at softwaren var stabilt. Kun meget sjældent, sås ikke C programmer, var ustabile. Et typisk C program, havde væsentligt højere risiko for ustabilitet, end software i andre sprog. Imidlertid havde C dermed bevist noget meget vigtigt overfor tvivlerne: At et sprogs deffination betød noget, for sprogets stabilitet. Måske kunne man endog frygte umuligheden af at store programmer nogensinde vil kunne fungere. C++ er på mange måder som C, og har arvet en del ustabilitetsproblemer. Dermed er det som sådant ikke et sprog lavet til store programmer - dog er det alligevel netop idéen med C++ i forhold til C.

At et program gør det samme hver gang den køres (determinisme) er et væsentligt problem, og specielt at kunne håndtere dette, hvor vi beskriver vores problem som mange parallele processer. Det er ikke et problem, hvis vi har et sprog, der automatisk tvinger os til at deffinere vores problem, som noget der deterministisk og alligevel beskrevet parallelt. Ikke determinisme er i nogen grad tilladt, men det skal være tydeligt at sproget, at nu gør vi noget som fører til ikke ens opførsel (ikke deterministisk opførsel), på grund af parallelisme. Og ofte, er en sådan opførsel end ikke lovlig. Vi burde kunne sikre os, at en komponent, er "lovlig", og deterministisk, så vi ved, at den fungerer ensartet (som ISO 9000) fra gang til gang.

I dag er vi - takket være C++ og JAVA - kommet dertil, at et sprog ikke behøver at gøre det samme hver gang noget udføres. Det afhænger af sprogets deffination.

Den bedste måde, er at udvikle sprogene, således de sikrer at koden bliver simpel, overskuelig, sikker, deterministisk hvor vi tror den er der, gør som vi faktisk skriver den skal, og sikrer at computerens maskinniveau, allignment osv, ikke får betydning for indstruktionerne og deres udførsel, og at man på ingen måde kan lave et program der nogen gange dur, og andre gange ikke fungerer. Denne opgave, er jo ikke triviel. Man tager ikke bare en vilkårlig deffination (eksempelvis C++ eller Java), og opnår en god sprog konstruktion.

Når vi udvikler sprog, er en af de vigtigste egenskaber, at vores software er beskrevet på en ordentligt og forståelig måde, der afspejler hvad vi egentligt ønsker skal foregå, og at det rent faktisk funktionelt også er det som sker. Det er også en utrolig vigtig egenskab, at sproget "by nature" fører til pålidelig kode, der virker ensartet hver gang, som fungerer ens uafhængig af underliggende hardware og operativsystems natur, og at man derfor ikke får store kvaler, fordi der isættes større processor, eller programmet overføres til anden CPU, addressebitbredde, integerbredde, floatprocessor bit bredde, processor, eller anden processor akitektur.

Der er ingen tvivl om, at sprogets evne til at håndtere parallelisme, er væsentligt for at opskrive sikre og overskuelige programmer, og samtidigt også at sprogets måde at håndtere dette på, har stor betydning for programmernes pålidelige opførsel. Men, der er mange andre "problemer" med sprog, som man bør tage højde for. Selvom noget virker dødsmart, er det ikke nødvendigvis godt, i et ordentligt sprog.

For OOP, og C++ i særdeleshed, kan disuteres mange konstruktioner, og deres "egenskaber" i retning af pålidelighed. Vi kan tage muligheden for, at man ethvert sted i programmet kan erklære et statisk objekt, evt. sammen med objektet, og da vil dette objekts konstruktør udføres. Er dette en god egenskab? Smart - men godt? Er det en "hackers drøm"? Jeg kan placere mit beskidte kode hvorsomhelst i mudderet, og det vil blive bragt til udførsel? Jeg kan få programmet til at hænge uden nogen opdager noget? - Eller er sprog, hvor vi har lidt kontrol med hvor kode udføres et mere sikkert valg? Jeg vil ikke påstå, at C++ ikke er smart, men alligevel pointere, at det er en af mange problemer ved sproget, at det meget nemt opbygger konstruktører, som endog udføres, og kan medføre mange fejl der er sværre at opdage hvis man ikke kender sine biblioteker. Vi kan også diskutere den smarte operatoroverlejring, hvor der også er set "fantastiske konstruktioner", hvor smartheden har sat såvel samarbejde, som sikkerhed langt ud af kontrol.

Det er mange væsentlige detaljer når man udvikler et programmeringssprog. Det er ikke væsentligt, at udvikle et sprog, der bare giver hurtig programmeringstid for at omskrive et helt program, hvor et ikke OOP program omskrives til OOP fra "bunden", men derimod langt mere væsentligt, om denne omskrivning har ført til at programmet er med færre programmeringsfejl, virker stabilt, anvender CPU og ram mere optimalt, osv. Enhver kan udvikle noget, hvor man hurtigt tager noget eksisterende og omskriver hurtigt fra bunden til noget nyt, og får dette til at fungere "beta" stabilt, meddens det er langt sværre, at tage et "beta" stabilt sprog, og få det til at fungere stabilt, ved omksrivning. Vi skal gerne opnå, at når vi omskriver eksempelvis et C++ sprog, til fremtidens sprog, så vil det automatisk føre til at vi opdager alle fejlene, som vi før ikke så. At opnå dette er vigtigt, men også et større problem, end det første hvor man blot hurtigt omskriver alt fra bunden (ved at kigge på og genbruge eksisterende kode), og tilmed opnår noget nu ustabilt. Vi står overfor nye problemer indenfor programmeringen, hvor fortidens brølere skal opdages. Og hertil, skal vi have nogle nye sprog for at undgå fejl. De gamle, er ikke sikre som programmeringssprog.

  • 0
  • 0
Jørgen Henningsen

Man diskutere hele tiden funktioner og de kan så pakkes ind i objekter og blive til metoder. Jeg synes operatoren er et overset begreb. Man kan ganske vist i C++ selv definere operatorer, men det kan ikke lade sig gøre i Java.
Hvis f.eks. man bare vil lave en klasse 'X' til komplexe tal, så skal man da kunne definere hvad det betyder at skrive 'x1+x2'. Igrunden kunne man vel også i funktionelt baserede sprog få lov til at definere hvad der skal ske hvis man f.eks. addere variabler af bestemte typer. Der er en del kode, som ville blive mere læselig samtidig med at det bliver mere kompakt.

  • 0
  • 0
Peter Juhl Christiansen

Du har ret, at definerer operatorer er smart!!

Og egentlig netop når man snakker objekter giver det mening at kunne definere hvad det fx vil sige at lægge dem sammen.

At man ikke kan det i Java, har intet med OO at gøre det er et design valg, jeg koder fx en del Ruby og der kan man uden problemer give en klasse en + metode.

En del af hjørne stenene i denne diskution er at C/C++ og Java er gammeldags, og hvis vi skal forbedre vores evne til at lave god software skal vi forbedre måden vi snakker med computere på!!

Erlang er for mig at se bestemt med til at bringe nye ting på banen, men tror nu aligevel at der er ideer i OO der er kommet for at blive.

Mht nedarvning, så vil jeg mene at det er et smart koncept, man bruger det bare ikke særlig tit, og som med alt andet skal man bruge det med måde. Jeg mener enhver vil idag sige at recursion er et smart koncept, men det bruger man heller ikke hverdag.

  • 0
  • 0
Torben Mogensen Blogger

Problemet med OO i forbindelse med parallelprogrammering er ikke nedarvning, problemet er, at metoder opdaterer lokal tilstand i objekter.

Det sekventialiserer alle tilgange til objektet, og kræver derfor synkronisering, stort set hver gang man kalder en metode.

Statisk nedarvning (jeg er ikke meget for dynamisk nedarvning) kan fungere fint sammen med parallelprogrammering, og også være en ganske god mekanisme til at opbygge biblioteker. Se f.eks. på Haskell's typeklasser, der navnet til trods har meget lidt tilfælles med klassebegrebet i f.eks. Java. Faktisk ligner det mere operatoroverloading.

  • 0
  • 0
Jørgen Henningsen

Jeg har fingrene i embeddede ting iøjeblikket. Det er et ret lille system med 512kb flash og 512kb ram. Der er der intet valg. Næsten uanset hvad man vælger af processorer, så følger der en c/c++ kompiler med. Det kan så kombineres med noget RTOS eller noget i den stil.
C (evt. objektorienteret) har lige den fordel at du både kan lave abstraktionen og rode med bits, bytes og pointers på hardware niveau i eet og samme sprog. Det savner jeg i alle alternativerne. Abstraktionen er god nok, men når man så får stukket een eller anden binær blob i hovedet udefra og der skal roteres bytes o.s.v. så savner man virkelig sin C kompiler alligevel.

Måske har jeg har kodet C i så mange år at jeg ikke længere kan se fidusen i at finde alternativer?

  • 0
  • 0
Jens Madsen

"Måske har jeg har kodet C i så mange år at jeg ikke længere kan se fidusen i at finde alternativer?"

Din pointe er ganske god - ja jeg tror godt, man kan indoktrineres af sprog. Forestil dig, du selv skulle "opfinde" et sprog. Jeg er næsten sikker på, at du aldrig vil opfinde C++'s objekt begreb. Derimod, er jeg ganske sikker på, at du nemt vil opfinde et system hvor data og processer samles i objekte, og kører parallelt. Du vil endog syntes det var unaturligt, at have en "process" uden denne kunne have sine egne variable. Når du arbejder mere med dette, kommer du måske til, at en sådan parallel opfattelse, er i stand til at kunne løse alle sekvens opfattelserne, meddens det modsatte ikke er tilfældet fordi eneste måde at opnå noget som ligner task skift, er at indføre en indstruktionspointer som tilstand i dit C++ objekt, og dette giver langt mindre overskueligt kode med en sådan tilstand, end at anvende multiprocessing som beskrivelse. Og som om det ikke er nok - så udelukker du samtidigt at tingene kører samtidigt.

Du har lært C++ så godt, at du ikke selv har arbejdet med at "opfinde" sprog, før du lærte C++. Og du har ikke følt behov for dette senere. Det gør, at du er en god programmør - men en god datalog? Derpå vil jeg tvivle. En god datalog, er bedre til at opfinde sprog, med specielle karakteristika, end til at programmere.

Min holdning er, at man ikke kan være glad for C++. Analyseres sproget, indeholder det mange dele, som et logisk tænkende menneske ikke kan acceptere. Ganske vist, kan alt gøres - men ting der reelt er ens, skal i mange tilfælde gøres så forskelligt, at man ikke opdager den overordnede strategi som er bag. Og det tyder på, at den faktisk ikke er der, men at C++ er blevet "bygget", som "spagethi programmering", hvor nogle har sagt at noget manglede, ved at køre et konsistenttjek. Herpå, er det tilføjet på vilkårlig måde. Denne metode, gør at det er meget svært at se, om noget er konsistent, fordi det ikke fremlægges på ens måde, hvor det burde være ens. Værst, er at C++ programmørerne ikke kan se ensartetheden og at noget er gået galt.

Det værste - som jeg ser det - er sprogets evne, til at gøre noget forkert, og lave ustabil kode. Dette er en absolut forbudt ting. Arvningerne har jeg ikke noget direkte negativt at sige om, men implementeringen af objekte i maskinkode, ved jeg er gjort forkert. Dem, der har kodet C++ compilerne, er ikke dygtige nok, til at kode, og finde ud af hvordan det skulle gøres. Du vil se de dygtige, på en måde "føler" at noget er galt, men på grund af indoktrinering, har de svært ved at gå tilbage og opdage fejlen, hvis de ikke har fundet løsningen først. Har man først opdaget noget tilsvarende, så opdages hurtig ved en form for "overenscheck", at det faktisk er gjort ekstremt dårligt i C++.

C++ er derfor et farligt sprog, fordi det har tendens til at være indoktrinerende.

På den anden side, mener jeg at vi ser så mange fejl i C, og C++, at det ikke har været farligt, med hensyn til at overbevise folk om, at sprogets egenskaber betyder noget for funktion og stabilitet for et sprog.

Du ønsker et sprog, som er meget bitnært, og hvor du ved eksakt hvor koden ligger i maskinkode. Her er C nok det bedste sprog, og jeg syntes ikke C++ er så godt. Derfor har jeg også lidt en forkærlighed for sprog som C.

Men, det er ikke nogen god ting, for et højniveau sprog, der skal køre under et operativsystem, at du har begreber som pointer, og at denne pointer er 32 bits. Dette er en "arv" som kommer fra maskin niveauet, og som ikke bør findes på et operativsystem niveau, og som er totalt urelevant for dit software. Intet, må komme fra maskin niveauet, i et højniveau sprog, og int, må hellerikke være deffineret til 32 bits, eller 64 bits. Byte, kan diskuteres lidt, da det altid er 0-255, men genneralt er det langt bedre, at deffinere en type til 0..255, som i Pascal. Det er så op til compilerens opgave, at lave det til en byte.

Nu får du et nyt problem. Du kan måske skrive et program, men du får ofte nogle typer ind i en datafil, eller fra en datastrøm, der "binært" er beskrevet i bit formater, og byte formater. Du har gavn af, at her kunne definere et format, som disse data kommer ind i, og sikre at du kan beskrive dit input format i dit sprog. Dette har ikke noget med din underliggende processor at gøre, men en specifikation du har fra dit input, og som er specificeret andet steds. Her er relevant, at have nogle typer som specificerer bestemte måder bittene betragtes på, således du får nemt adgang til de data der måtte komme ind i dit sprog, fra dit filformat eller data strøm format (måske via TCP/IP eller RS232 ol.). Typerne, kan du så enten selv skrive en algorithme der håndterer, eller bruge en indbygget metode, f.eks. der deffinerer bittenes betydning i float, eller en word. Der kan være specielle formater såsom tid, du selv opskriver konverteringsformatet for. I dette tilfælde, betyder det ikke noget, at du skal bruge evigheder for at omregne til/fra formatet, da det er formatet som er det vigtige, og ikke funktionen. Det er også et krav, at bittene ligger helt tæt, og der ikke sættes tilfældige bytes ind for bedre alligning, da dette ikke er hensigten når du anvender det til sådanne beskrivelser. Her, må du gerne have en byte, der overligger bytes, eller en float, og det er 100% deffineret hvad herved forstås. Derimod, giver det ingen mening, hvis der pludseligt sættes "space" ind, således det ikke konverteres korrekt, på grund af et sådant overlap. Med andre ord, her skal det altid være "packet".

Hvis du kan C++, så ved du, at ovenstående "bit unions" findes. Fin feature. Men, dem der koder, vidste ikke at det ikke gav mening at de ikke var pakket, og mange compilere har bit unions, som standard til ikke packed format. Det er totalt tåbeligt, og viser de burde udvises.

Hvis du derimod skriver et program, og har nogle typer du deffinerer, så er det altid op til compileren at gøre dette godt og korrekt. Du må her ikke have adgang til nogle funktioner eller muligheder, der afslører den underliggende hardwares funktion. Ovenstående bitunions gør hellerikke, da det er fuldkommen abstrakt deffineret, og din float er en deffinationsfloat, der måske ikke eksisterer i din hardware. Den vil sikkert køre sindsygt sløvt, for ingen ved hvordan din coprocessoer er lavet, og der kan være mange indbyggede deffination float formater.

Hvis du vil lave noget "ordentligt software" skal du ikke vide noget om det underliggende. Hvor mange bits, der afsættes til en bit du har deffineret, er compilerens hovedpine. Den må bruge 2, 8, eller 32 hvis den ønsker det. Og du må ikke kunne opdage dette, eller se dette fra dit program. Du må ikke have en size-of der kan afsløre det. Sizeof kunne du have på bit-union, men du må ikke på andre typer, da det vil afsløre en talværdi, der siger noget om din compilers funktion, og dette er ulovligt. Et program skal kunne forstås, og må ikke indeholde noget fra hverken compiler, eller hardware.

Du kan sagtens programmere i et godt sprog - og ligesom hvis du skulle være gået fra at programmere bits i maskinkode og selv assemblere, og til at gå til at bruge en rigtig assembler - så vil du her også opdage, at der ofte opdages nogle fejl, i nogle rutiner du måske bruger. Det kan være en sizeof som er brugt forkert, og returnere det magiske tal 4, hvor du troede den returnerede længden af en tekst i en streng. Dette er naturligvis ikke godt, at C og C++ gør noget sådant. Det magiske tal 4, er noget vås, som skyldes længden af en pointer, og at du tilfældigvis har fået lavet en streng til en pointer, uden at fået programmet rettet helt korrekt.

C++ er simpelthen ikke et godt sprog. Mange indser det, og skifter til Java. Nu er Java hot - og godt. Men er det så det? Næh, på visse områder, såsom determinisme, og at tingene sker ens fra gang til gang, har Java ikke opnået - tværtimod. Parallelismen giver anledning til fejl, og til at noget kommer før noget andet og derved går forkert. Det er noget, som ikke må kunne ske.

Det gode ved C++ er at det er så forkert, at enhver datalog burde brokke sig. Og begynde at tænke. Men desvære sker det ikke altid, og man må konstantere at folk indoktrineres.

Jeg tror intet problem der er i, at få compilere til microcontrolere for et nyt sprog. Men i dag, er C det bedste sprog, til programmering af microcontrolere. I fremtiden, vil C måske stadigt vinde indpas til dette formål, men jeg mener ikke, at det er velegnet til computere der har et operativsystem.

Her skal nævnes, at jeg har en speciel opfattelse af begrebet operativsystem, da jeg mener at det har følgende egenskab: At kunne køre et program, og at kunne køre det sikkert, samt gerne optimalt. Derudover, skal det gøre det uafhængigt af den underliggende hardware og fungere som abstraktionslag til denne. Derfor, vil du ikke bruge microcontrolerens sprog, når du anvender et operativsystem, fordi du bruger operativsystemets sprog. Et program oversat til et operativsystem, er derfor kompatibelt med det pågældende operativsystem, uanset CPU. Dette betyder, at operativsystemet skal have en dynamisk compilerende kerne som optimerer og lægger koden over i hardware. Dette er et stort job for et operativsystem, og ikke nogen simpel ting at løse.

Ved et "ikke advanceret operativsystem", som efter min opfattelse ikke lever op til operativsystemets deffination om at kunne køre kode, og at kunne køre kode sikkert, men overlader dette problem til CPU'en på grund af dens egen manglende formåen, gør CPUen til operativsystemet. Måske pyntes med nogle rutiner der kan opnås ved call. Men langtfra noget, der gør at selve operativsystemet kører programmet. Basic, var i den sammenhæng et større operativsystem. Jeg ved godt min deffination ikke er standard, men det er simpelthen nødvendigt, hvis du skal opnå noget optimalt, og du vil opdage at det er en stor fordel for operativsystemet, at kunne "behandle koden" når den skal køre sammen med andet kode samtidigt. På et tidspunkt, skal de parallele processer ned i nogle få VLIW processorer, i FPGA'er, eller i grafikprocessoren, og så er dette operativsystemets opgave. Dit program, beskriver din opgave, og det er det som kører under operativsystemet. At mappe programmet ned i hardware, mener jeg er operativsystem niveau, fordi det bedst kan gøres under hensyn til de parallele processer der køres samtidigt her, og samtidigt tilbydes dynamisk ændring i hardware resourcer og konfiguration.

I første omgang, er sprogene dog det vigtige. Så kan man altid se på oversættelsesfasen bagefter, og hvilke dele der bør være del af operativsystemerne, for at opnå ordentligt udførsel når mange processer arbejder samtidigt.

  • 0
  • 0
Jørgen Henningsen

Jeg er enig med dig i din kritik af C++. Det er et skønt forsøg på at øge abstraktionen i et sprog igrunden er bundet til hardware. Det er bestemt ikke optimalt og jeg går udenom det hvis jeg kan. Du har iøvrigt ret... Jeg er ikke datalog. Jeg er ingeniør og grunden til jeg fidler med kode er at jeg er flasket op med det.

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