Torben Mogensen header

Fremtidens API

Diskussionen ved Peter Makholms indlæg "Unix Haters Unite!" kom efterhånden til at handle om APIer og specielt manglerne ved POSIX, som allerede for et årti siden var mere bagudskuende end fremadskuende.

Så hvordan bør fremtidens API se ud?

Nogle vil måske pege på .NET som et eksempel, idet det er en maskinuafhængig komplet applikationsafviklingsinfrastruktur. Men jeg synes, at .NET stadig er bagudskuende, for den bygger på den klassiske ide om et API som et samling af procedurer/metoder/rutiner, der arbejder på et fælles lager. Men fremtidens applikationer er ikke maskincentrerede – de er distribuerede og uden fast holdeplads på bestemte maskiner.

Derfor bør en fremadskuende API bygge på kommunikation som det primære virkemiddel, hvilket vil sige protokoller frem for procedurekald. Og protokollerne skal ikke bare være en skal ovenpå et procedurebegreb, så det er ikke RPC (Remote Procedure Calls), jeg snakker om. Man burde hellere tage udgangspunkt i proceskalkuler og helst nogen, der tager skiftende lokaliteter i betragtning. Det kunne f.eks. være The Ambient Calculus. Dermed får man en API, der ikke alene er maskinuafhængig i den forstand, at den er agnostisk overfor processor og operativsystem, men også i den forstand, at applikationer og data ikke er bundet til bestemte maskiner, mens de kører.

Endvidere bør man gøre op med ideen om en applikation som et program, der startes, bruges og lukkes ned igen. Fremtidens applikationer er "på" hele tiden, de udvikler sig konstant og de arbejder med data, der ikke har en fast adresse. En API, der ikke har denne kontinuitet, metamorfose og mobilitet som centrale elementer (og ikke bare noget, der er boltet ovenpå en gammeldags model), er ikke rettet mod fremtiden.

Kommentarer (32)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Mikkel Meyer Andersen

At applikationer ikke startes op og lukkes ned (lad os lege det), giver en masse spændende udfordringer i forbindelse med opdatering/udvikling af disse. Det betyder vel, at applikationer skal udvikles som styresystemer med mikrokerner - der er kun den helt basale funktionalitet for at kunne køre, og features kører som servere, der kan startes, genstartes og lukkes. Måske endda en generisk applikationsmikrokerne fælles for applikationer. En browser ville så bestå i at loade et HTTP-modul, renderingsmodul, bookmark-modul osv. Når HTTP 2.0 kommer, vil det modul lige blive genstartet - uden at browseren lukkes ned! Og lad os da for den sags skyld udlicitere renderingsmodulet til en applikationsserver, så vores bærbare holder strøm noget længere!

  • 0
  • 0
Helge Svendsen

Og lad os da for den sags skyld udlicitere renderingsmodulet til en applikationsserver, så vores bærbare holder strøm noget længere!

Hvis man ser på, hvilken båndbredde, der er mellem GPU og CPU i dag, så vil jeg sige det varer et stykke tid før den slags kører med samme performance som en netværksløsning.

  • 0
  • 0
Poul-Henning Kamp Blogger

Det der har gjort POSIX til den success der er, er alene at det er et agnostisk API.

Det forudsætter ikke en bestemt holdning eller filosofi indenfor programmering, hvad enten man er till OO eller andre religioner, så kan man implementere sine ideer på at POSIX API.

Det har den simple forklaring at POSIX definerer en virtuel maskine uden for mange bindinger.

Jeg tror at vi bør opdatere POSIX på et antal "håndværksmæssige" områder, men ethvert forsøg på at binde en opdatering fast i en eller anden datalogisk religion vil dømme opdateringen til et lille frelst segment af IT branchen.

De opdateringer jeg er er efter er simple ting som:

int tcp_open(const char *remote_address, timeout_t timeout);

unlisten(2) ville også være rar at have i samme hjørne.

Funktioner for at forbedre kommunikationen med kernen, f.eks en generel "move_data()" funktion, der kan flytte data ifølge en generel scatter/gather specifikation, ville gavne performance.

Dertil nogle snævere men problematiske problemer der skal løses (f.eks tid, herunder 2036 & skudsekunder).

Og endelig nogle helt basalt håndværksmæssige værktøjer som asserts og profilering af pthreads låse og den slags.

Det er ikke rocket science, det er håndværk der mangler.

Men det er der jo ingen der interesserer sig for i programmering.

Poul-Henning

  • 0
  • 0
Jan Andersen

Er et sådant scenarie med programmer delt op i små fragmenter overhovedet realistisk i andet end tænkte sammenhænge? Selvom tanken er fascinerende, så lyder det i mine ører ret så meget som den udbredte misforståelse om, at hvis vi blot pakker disse data ind i overmåde "beskrivende" SOAP-indpakninger, så kan diverse systemer på magisk vis få nye evner koblet på af tredieparts moduler.
Jeg har svært ved at forestille mig, hvor en sådan opbygning vil komme til sin ret. Eller rettere: Jeg har svært ved at forestille mig systemer, hvor data, behandling af data og de systemer der møder brugerne er så indbyrdes uafhængige, at det her faktisk kan lade sig gøre. Det lyder mere som datalogers (og sælgeres!) våde drøm, end som noget der reelt kan tilføre en værdi som retfærdiggør den forøgede kompleksitet.
Overbevis mig gerne om, at jeg tager fejl :-)

  • 0
  • 0
Klaus Kolle

Erlang er - så vidt jeg endnu har forstået det - et sprog, som tillader on-the-fly programopdateringer. Jeg er endnu ikke så fortrolig med sproget at jeg kan udtale mig om at koden kan flytte, men der ligger noget i sproget, som måske er et skridt på vejen i den henretning.

Jeg synes Erlang er et spændende sprog, som jo også anvendes i store telefoncentraler af Ericsson så vidt jeg kan forstå. Jeg er derfor ved at dykke ned i det for at udforske dets hjørne og kroge. Ikke at jeg er kommet langt endnu, men det kommer sikkert hen over sommeren.

Måske skal vi interessere os for noget der ligner Erlang fremfor at nørkle i C/C++/Pascal/og lign. (siger en C/C++ udvikler). Joe Amstrong har jo trods alt ret i mange af de begrundelse han benytter som baggrund for udviklingen af Erlang.

  • 0
  • 0
Mikkel Meyer Andersen

Jeg skal ikke gøre mig dømmende og komme med et definitivt svar, men jeg vil erklære mig enig med dig i, at det næppe bliver en pragmatisk holdbar og acceptabel løsning. Men det er jo ikke ensbetydende med, at våde drømme skal afskaffes :-). Hvis man var flabet, så sagde man, at det er våde drømme, der er drivkraften bag forskning :-). (Og lige endnu et godt citat fra Grimmitt og Stirzaker med reference til forgreningsprocesser indenfor sandsynlighedsteori: "Besides gambling, many probabilists have been interested in reproduction".)

  • 0
  • 0
Lars Balker

Fremtidens programmer skal ikke bekymre sig om hvilken maskine de kører på - de skulle gerne køre (redundant!) på mange, så hardware-fejl er et datacenter-problem.

Og de skal ihvertfald ikke skrives i C. Vi kan vist godt afse lidt regnekraft til at undgå pointer-fejl og array-overløb.

Principielt set kører alle vores programmer så på "én computer", så der skal selvf. en helt anden sikkerhedsmodel til, ikke alene fordi jeg ikke vil have andre (hverken dig, staten eller cia) til at kigge i mine data, men jeg stoler heller ikke nødvendigvis på at datacenter-ejeren kører mit program som forventet. Så stærk kryptografi hele vejen ned, tak.

Hvem ejer hardwaren? Hvem betaler for brug? Tjah, hvem som helst skal kunne koble en computer på, og derved udvide regnekraften, og måske modtage mikrobetalinger for brugen. I Charles Stross' Halting State er det ca. sådan mobiltelefons virtual-reality verdenerne virker - alle applikationer kører (og gemmer data) på tværs af alle mobiltelefoner.

Men centralt i denne ide er at hr og fru jensen måske slet ingen computer har - de har det absolut mindst nødvendige interface mod "cloud-computeren" som kommer ud af et stik i væggen ved siden af vand og el. Den eneste måde vi kan sikre fremtidens offentlige internet er ved at fjerne de dumme operativsystemer og deres inkompentente administratorer fra ligningen...

Jeg synes det er perspektivtløst at snakke om nye operativsystemer på den arktitektur vi bruger i dag, hvor applikationerne så selv skal kodes til redundans og scalability (eller acceptere manglen på samme). Lad os få flyttet de ting ned i os'et som helt selvfølgelige ting.

  • 0
  • 0
Poul-Henning Kamp Blogger

Og de skal ihvertfald ikke skrives i C. Vi kan vist godt afse lidt regnekraft til at undgå pointer-fejl og array-overløb.

Hvis historien har noget at lære os, så er det at hvis det ikke kan skrives i C, så er det ikke godt nok.

Det er ikke det samme som at det partout skal skrives i C, men alle de programmeringsmiljøer der har afskrevet sig den mulighed er kun blevet nieche produkter.

Poul-Henning

  • 0
  • 0
Poul-Henning Kamp Blogger

Du misforstår situationen Lars.

'C' er ikke et fossilt sprog der burde udryddes af højt oplyste dataloger.

'C' er vores symbolske assembler, til brug for når vi er nødt til at kommunikere med den hardware, der hverken er objektorienteret, har lært SCRUM, eller agile metoder men derimod har behov for at få maskininstruktioner der passer til den aktuelle hardware.

Hvis vi derfor laver et ny OS API der ikke kan bruges fra C, så har vi helt sikkert malet os ud i et hjørne.

Der er mange der har prøvet og betalt prisen.

NeXT og BeOS er to gode eksempler.

Poul-Henning

  • 0
  • 0
Lars Balker

Jeg er helt med på C's betydning. Fuldstændig. Jeg siger blot at vi er nødt til at komme videre, fordi vi skal over på en meget mere delt arkitektur, hvor C simpelthen er for farligt. For jo, det er et fossil i den sammenhæng jeg beskriver. Jeg snakker om at mine bankoplysninger og personlige oplysninger bl.a. ligger på en maskine i din kælder, og så stiller vi altså nogle andre krav til sikkerheden.

Man kan sagtens forestille sig at C/C++/i386-assembler eller andre arkitekturnære sprog får en sandkasse-VM at boltre sig i; ja, det er vel en forudsætning for at komme i gang. Men det vil jo ikke være beregnet til nyudvikling som sådan, for hvor er pointen.

Men hvordan det skal virke hele vejen fra IC'er til Movie-OS er jo så en helt anden snak :)

  • 0
  • 0
Henning Makholm

Jeg tror ikke rigtig på Mobile Ambients og tilsvarende kalkyler som grundlag for et egentligt programmeringssprog. De er oprindelig skabt som et analyseværktøj snarere end et programmeringsværktøj, og det viser sig i at de overapproksimerer hvad der let kan lade sig gøre mht kodemobilitet - grundantagelsen er at al kode som udgangspunkt kan flyttes alle steder hen, og en stor del af øvelsen i at lave en model i kalkylen går ud på at modellere eksplicit hvilke kodeflytninger der er mulige.

Ude i virkeligheden ser det meget anderledes ud - der er ganske vist mange maskiner der snakker sammen, men de udgør et stærkt heterogent miljø med forskellige arkitekturer, ressourcer og rettigheder overalt. Vil man skrive kode der både kører på en mainframe, en mobiltelefon og en brødrister kræver det at man tager specille hensyn, installerer passende VM'er alle tre steder, og sørger for at ejerne af alle dimserne er enige om at den pågældende kode har lov til at flytte sig. (I almindelighed bør enhver maskinejer jo være temmelig paranoid mht hvilken fremmed kode han giver sig til at udføre).

I den verden er en programmør der vil skrive et velfungerende sikkert system, nødt til konstant at forholde sig bevidst til at maskiner er forskellige, ikke alting kan køre ikke alle steder, og at vi ikke kan være sikre på at kode vi sender ud i verden for at blive kørt, nu også bliver udført som den er skrevet. (SQL injections er det p.t. hippeste eksempel på hvad der går galt hvis man glemmer grundreglerne).

Et programmeringssprog som bygger på MA-agtige kalkyler, hvor primitiverne netop går ud fra at alting kan flytte sig transparent hvorhen det skal være, vil gøre programmøren en bjørnetjeneste, ved at forsøge at skjule og bortabstrahere den heterogenitet som programmøren er nødt til at tage bevidst højde for.

Og bare fordi man KAN abstrahere et eller andet væk, SKAL man det ikke nødvendigvis. Det kunne netop vise sig at være det interessante (hvilket jeg mener er tilfældet her).

Lambdakalkylen er en succeshistorie fordi den uventet viste sig at give direkte anledning til en række temmelig seje programmeringssprog. Men det følger ikke at andre kalkyler nødvendigvis er lige så heldige.

  • 0
  • 0
Søren Straarup

Det er nager mig er at folk siger at C er farligt.
Det er jo også farligt at ligge i sengen det er der de fleste dør (iflg. statestik).

Det jeg ser som en udfordring er memory håndtering.
Det er jo op til kode poeten at tage vare på det.
Min holdning til garbage collection er at: "En kæde er ikke stærkere end det svageste led."

+1 på holdet af dem der syntes at POSIX mangler et facelift.

/Søren

  • 0
  • 0
Torben Mogensen Blogger

Erlangs concurrency er grundlæggende set pi-kalkule, og en stor del af API'en i Erlang bruger netop asynkront kommunikerende processer.

Et godt resume af, hvad som kendetegner Erlangs programmeringsmodel kan ses på
http://ulf.wiger.net/weblog/2008/02/06/what-is-erlang-style-concurrency/

Erlang understøtter desuden "hot code swap", dvs. opdatering af moduler, mens programmet kører.

  • 0
  • 0
Torben Mogensen Blogger

Hvis vi derfor laver et ny OS API der ikke kan bruges fra C, så har vi helt sikkert malet os ud i et hjørne.

Det har du ret i. Men et API, der bruger kommunikation over kanaler som basis og ikke deler data i lageret kan netop bruges fra alle sprog, som understøtter kommunikation over kanaler.

  • 0
  • 0
Poul-Henning Kamp Blogger

Det har du ret i. Men et API, der bruger kommunikation over kanaler som basis og ikke deler data i lageret kan netop bruges fra alle sprog, som understøtter kommunikation over kanaler.

Sikkert.

Men det er ikke sådan vores hardware faktisk virker, så hvis vi bygger denne abstraktion ind i vores API, så har vi, per definition, solgt vores performance.

Hardware virker ved at dele ting i lagret.

Poul-Henning

  • 0
  • 0
James Avery

<i>
Men det er ikke sådan vores hardware faktisk virker, så hvis vi bygger denne abstraktion ind i vores API, så har vi, per definition, solgt vores performance.

Hardware virker ved at dele ting i lagret.
</i>

Men er det ikke netop pointen, at dette bør håndteres af de underliggende operativsystemer og programmeringssprog, og abstraheres væk i API'et? API'er er vel, som navnet antyder, henvendt til applikationsprogrammører - som jo helst skal se en homogen grænseflade i stedet for at skulle rode direkte med de hundredevis af forskellige underliggende hardwarekombinationer.

Abstraktion betyder ikke nødvendigvis tab af performance. Moderne C-oversættere genererer hurtigere kode, end de fleste kan skrive i assembler.

  • 0
  • 0
Carsten Sonne

Sådan som jeg ser de sprog og APIs jeg kender, har de hver deres styrker og svagheder. At tro der findes et svar på alle spørgsmål, vil jeg betragte som en naiv holdning.

C er et ganske fornuftigt sprog og har bestemt en eksistensberettigelse. Som f.eks. Poul-Henning Kamp ganske rigtig har pointeret er det meget maskinnært. Der har sine fordele i flere sammenhænge, herunder perfomance. Jeg ved i bl.a. indlejrede systemer er C meget udbredt og med god grund.

På samme måde kan man finde mange gode egenskaber ved andre sprog og APIs. F.eks. giver en API på meget høj abstraktionsniveau en ganske god produktivitet. Her slipper man for at beskæftige sig men mange trivielle opgaver. Men der er ikke uden omkostninger, igen f.eks. på performance og kontrol.

Java har sin store styrke i sin platformsuafhængighed.

Sådan kunne man blive ved og ved.

Jeg tror ganske givet at der vil opstå nye sprog og API som har andre fordele og tilgodeser nye behov som vi ikke har i dag, eller som i hvert fald ikke er så påtrængende endnu. I den forbindelse kan man jo henlede tankerne på den udvikling der foregår i retning af flerkernede processorer. Jeg har læst om en udgave a C kaldet Ct som Intel eksperimenterer med. Måske bliver det ikke lige Ct som bliver udbredt, men jeg er sikker på der vil komme et sprog som tilgodeser de muligheder der ligger i den flerekernede arkitektur på en måde som igen af nutidens sprog og APIs gør. Formegentlig vil der også kommer flere sprog og API i denne kategori.

Ser man lang ud i fremtiden, er det nok svært at have en forestilling om hvordan den tids programmeringssprog og APIs kommer til at se ud. Som bekendt har mennesket svært ved at se alt for langt frem da vi er begrænset af vores nutid.

Nu er jeg relativ ung og glæder mig lidt til at se hvordan sprog og APIs vil udvikle sig i min tid som systemudvikler. I dag bruger jeg primært .Net, men jeg er sikker på i en ikke så fjern fremtid, måske 5-10 år, så bruger jeg noget helt andet.

Under alle omstændigheder tror jeg aldrig der kommer et sprog eller en API som simpelthen bare er svaret på alles behov og tilgodeser alle verdens forskellige platforme/processorer lige godt. Derimod er jeg overbevist om at der vil blive ved med at være en mængde sprog som alle sammen har en eksistensberettigelse og vil have en vis udbredelse, også i fremtiden.

Mvh
Carsten Sonne Larsen

  • 0
  • 0
Poul-Henning Kamp Blogger

Sådan som jeg ser de sprog og APIs jeg kender, har de hver deres styrker og svagheder. At tro der findes et svar på alle spørgsmål, vil jeg betragte som en naiv holdning.

Jamen så er der noget du ikke har fattet.

Der skal været et og kun et API der skiller kernen fra user-land programmer og det skal understøtte alle sprog der skal køre.

Derfor bliver netop dette API ikke højniveau abstrakt, for det er det API runtime miljøer (som f.eks JVM) bruger til at implementere deres egne abstrakte og højniveau API med.

Vi taler om det helt basale API, hvor et program siger til kernen: Jeg skal bruge indholdet af en fil der hedder "foobar.dat" og tilsvarende lavpraktiske handlinger.

Hvis man fylder en masse abstraktion på dette API, så skyder man high-performance applikationer i foden og man opnår aldrig koncensus imellem C++, Ada, ObjC og Haskell folkene om hvilke abstraktioner der skal fyldes på.

Poul-Henning

  • 0
  • 0
Poul-Henning Kamp Blogger

Carsten:

Der er et sted i ethvert system hvor der kun er plads til et enkelt API: det er kerne/userland grænsen.

Alle andre API'er er bygget ovenpå dette.

Derfor er det, i denne sammenhæng, slet ikke interessant at diskutere disse andre API'er, for de er valgfri, udskiftelige og helt op til markedskræfterne.

API'et imellem kerne og userland derimod, det du misforstår som et "OS API", er derimod spørgsmålet om du er bundet til din hardware/OS platform eller om du kan skrive portabel kode.

Det er det API vi taler om: fundamentet.

Poul-Henning

  • 0
  • 0
Carsten Sonne

Poul-Henning,

Jeg vil blank erkende at mit indlæg ikke holder sig præcist til diskussionsemnet og artiklen. Det var blot nogle mere generelle og overordnede betragtninger, som jeg lige fandt lejlighed til at lufte. Jeg blev inspireret af at Torben Mogensen selv nævner .Net som et bud i sin artikel, trods han mener der er et dårlig bud og for ’bagudskuende’.

I forhold det det egentlige emne, fundamentet som du kalder der, vil jeg antage en holdning lidt i stil med mit første indlæg: Jeg vil mene det er lidt utopi at tro at situationen vil udvikle sig i retning af eet enkelt standardiseret API. I så fald skulle der jo mere eller mindre indirekte betyde at der kun ville findes eet operativsystem. I hvert fald hvis dette API ikke skal være en abstraktion oven på det egentlige OS API (snitfladen mellem kerne og userland). Er dette i det hele taget en ønskværdig situation? Eller har jeg misforstået dig?

Jeg syntes egentlig det er fint der findes forskellige operativsystemer med hver deres måde at gøre tingene på. Selvfølgelig har det da også nogle ulemper. Men et OS API til alting, lige fra de mindste indlejrede systemer, til PDA’er, desktop computere, serverer og supercomputere, det forekommer mig som en lidt utopisk tanke.

Personligt syntes jeg den nuværende situation med flere forskellige styresystemer og hardwareplatforme er ganske god. Jeg mener det bringer dynamik og giver inspiration og modspil systemerne imellem. Jeg håber ikke at vi i min tid, alle sammen kommer til at bruge Windows X eller Linux eller hvad det måtte være. Det ville da være trist og enfoldigt.

Mvh
Carsten

  • 0
  • 0
Poul-Henning Kamp Blogger

Jeg vil mene det er lidt utopi at tro at situationen vil udvikle sig i retning af eet enkelt standardiseret API. I så fald skulle der jo mere eller mindre indirekte betyde at der kun ville findes eet operativsystem.

Hvad er det for en planet du bor på Carsten ?

Hvorfor skulle et standardiseret API forhindre at man kunne have mere end et OS ?

POSIX API'et er implementeret på alt fra DG/UX over MVS til Windows.

Det eneste problem der er med POSIX er at det er klar til at computerne springer direkte ind i 1970erne.

Poul-Henning

  • 0
  • 0
Carsten Sonne

Poul-Henning,

Hvad er det for en planet du bor på Carsten ?

Den samme som dig formoder jeg :)

Hvorfor skulle et standardiseret API forhindre at man kunne have mere end et OS ?

Jeg kunne forstå på dig, at det fundament der diskuteres, er det nederste tilgængelige lag til kernen. Antagelsen er baseret på:

Der er et sted i ethvert system hvor der kun er plads til et enkelt API: det er kerne/userland grænsen.

Alle andre API'er er bygget ovenpå dette.

Sådan som jeg forstod citatet, var meningen at dette API skulle være den laveste fællesnævner og ingen kunne gå dybere end dette. Såfremt man ligger et lag oven på den ”native” OS API er det vel en abstraktion. Det havde jeg forstået var uønsket.

Deraf resonerede jeg at der var tale om alle systemer skulle implementere standard API’en direkte og heraf tanket om én OS.

POSIX API'et er implementeret på alt fra DG/UX over MVS til Windows.

Det var jeg ikke klar over. Faktisk ved jeg meget lidt om POSIX. Det fik mig til at kigge bl.a. på wikipedia:
http://en.wikipedia.org/wiki/POSIX

Såfremt denne information er korrekt og jeg forstår det rigtig, er POSIX i nogle systemer ”native” og i andre systemer en abstraktion, herunder Windows XP SP1 og Vista. I så fald er ideen i POSIX på nuværende tidspunkt jo ikke bedre i sin grundsubstans jo end f.eks. .Net (I øvrigt står der at en del Unix varianter, herunder Linux, ikke er 100 % kompatible med IEEE standarden).

Ideen i sig selv, om at have en OS API som er platforms uafhængig uden at det er på bekostning af f.eks. performance ser jeg som utopi hvis man ikke er villig til at enten accepterer en eller anden form for abstraktion eller tanken om én universel OS.

Jeg mener ideen om en standard API i forhold til operativsystemer er god. Men man bliver nød til at accepterer den enten er en abstraktion eller i det mindste en delmængde af et systems OS API. Hvis så man så kan accepterer det performance tab som det medføre at bruge denne standard OS API, så kan man bruge den. Hvis ikke må man gå til det dybest tilgængelige lag nemlig det ”native” OS lag. Sådan må det være.

Mvh
Carsten

  • 0
  • 0
Poul-Henning Kamp Blogger

Faktisk ved jeg meget lidt om POSIX.

Det anede mig :-)

Det viser på glimrende vis, at dette emne er for snævert til at kunne diskuteres i brede kredse.

Kun et fåtal forstår dybden i, hvad der umiddelbart lyder som et meget simpelt spørgsmål, men som i grunde overhovedet ikke er det.

Se også: www.bikeshed.org :-)

God weekend.

Poul-Henning

  • 0
  • 0
Carsten Sonne

Poul-Henning,

Artiklen handler om ’Fremtidens API’. Det er udgangspunktet for mine indlæg.

Jeg vil afslutte diskussionen med lige kort af ridse op hvad jeg har en holdning til og ikke har en holdning til.

Som overskriften på dette indlæg viser, handlede mit oprindelige indlæg om at hvert sprog og API har sine fordele, også i fremtiden. Det vil jeg holde fast i.

Mine øvrige indlæg var primært et forsøg på at forstå dig og dine holdninger. Jeg ved du er en person der besidder stor vide på området. Jeg vil dog stadig holde fast i de pointer jeg har fremsat.

At diskussionen blev drejet over på viden om ’fundamentet’ og OS APIs og til sidst POSIX vil jeg nu ikke tage æren for.

POSIX har jeg ingen holdning til. Jeg ved stor set intet om denne API ud over hvad jeg har læst mig til i dag. Som bekendt er en holdning jo aldrig bedre end den information som holdningen er baseret på. Derfor har jeg ingen holdning.

Lad den ligge der :)

Religiøse holdninger i forhold til OS, programmeringssprog og lignende har jeg ikke meget til overs for. Jeg vil gerne forsøge at skabe et nuanceret billede af tingene og kæmper imod de ensidige, til tider arrogante, holdninger som man kan blive mødt med mange steder. Det være sig gældende i Microsoft verden, *nix verden og i øvrigt alle andre steder. Det var min egentlige motivationen for at skrive mit første indlæg.

God weekend til dig også :)

Mvh
Carsten

  • 0
  • 0
Torben Mogensen Blogger

Men det er ikke sådan vores hardware faktisk virker, så hvis vi bygger denne abstraktion ind i vores API, så har vi, per definition, solgt vores performance.

Hardware virker ved at dele ting i lagret.

Modellen med delt lager skalerer ikke, så om ti år er den model begrænset til små systemer.

Men, som James Avery så fornuftigt sgde, så er en edel af pointen med et API at abstrahere væk fra hardwaren og programmere på et niveau, der er uafhængigt af maskinplatformen. Og på det niveau skal man se på, hvad det er for nogle applikationer, fremtiden vil bringe. Og her er det netop kommunikerende mobile applikationer -- ikke kun mobil i den forstand, at harwaren er mobil, men i den forstand at selve applikationen flytter sig mellem forskelligt hardware, mens den kører.

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