Dansk Google-udvikler: Nyt sprog skal hjælpe flere til at programmere til Internet of Things

GOTO 2015: Google frigiver nu den første testversion af et programmeringssprog baseret på Dart, som skal gøre det nemmere at programmere til de helt små computere, som udgør Internet of Things.

GOTO Copenhagen 2015: Når man skal få de helt små ’ting’, der udgør Internet of Things, til at gøre noget, så forudsætter det nogle programmeringsfærdigheder, som ikke er helt ligetil. Det vil Google nu lave om på med et nyt programmeringssprog til helt små computere.

»Jeg mener, at verden virkelig har brug for mere produktive programmører til små enheder. Vi har brug for en mere tilgængelig platform, hvor vi kan nå millioner af udviklere, baseret på højniveau-sprog,« sagde den danske Google-udvikler Kasper Lund, da han præsenterede Googles nye bud på en udviklingsplatform til Internet of Things på udviklerkonferencen Goto i København i dag, tirsdag.

Internet of Things er stadig i sin barndom, og mange udviklere, som vil prøve kræfter med nye typer enheder, løber ind i, at det i praksis ikke er muligt at få eksempelvis en fuld embedded Linux til at køre på de helt små enheder.

Dermed kan udviklerne være nødt til at skrive deres programmer til enhederne i eksempelvis C, men det er sprog, der er mindre tilgivende end eksempelvis de sprog, der bruges til webapplikationer og mobil-apps.

Så selvom C er brugbart til programmering af små enheder, så er sproget ikke så let at komme i gang med som højniveau-sprog.

»Vi risikerer at ende med, at det er de samme 100 udviklere, som udvikler til alle de her enheder,« sagde Kasper Lund.

Fletch skiller sig ud fra Java og .Net

Google lancerer derfor et nyt programmeringssprog til Internet of Things, som leverer eksempelvis automatisk garbage collection og styring af hukommelsen, som programmører til eksempelvis web ikke behøver bekymre sig om på samme måde som C-udviklere.

Modellen kendes fra eksempelvis Java og .Net, men Googles nye Fletch skiller sig dog lidt ud. Både Java og .Net afvikler koden på en virtuel maskine, men de indeholder begge en række funktioner, som optager plads. Og det kan knibe med pladsen på de helt små mikrocontrollere, som vil blive brugt i de billigste Internet of Things-enheder.

Derfor har Google skilt compiler-delen og debugging-delen fra som separate komponenter i Fletch i stedet for at være en del af den virtuelle maskine på enheden.

For at spare på pladsen har Google også gravet metoder frem fra dengang hulkort var state of the art.

»For længe siden bekymrede dataloger sig virkelig om disse ting, så vi er vendt tilbage til forskning fra 1970’erne,« sagde Kasper Lund, som blandt andet fremhævede metoden selector-based row displacement til hurtig adgang til klasser og metoder som en teknik, der var hevet frem fra skufferne.

Baserer sig på Google Dart

Fletch er baseret på Googles Dart, som er beregnet til webudviklere, og som har fået tilføjet et par ekstra elementer.

»Det er Dart-kode, og den eneste skræmmende ting er nok closures, men de dukker op i alle sprog i disse dage, så det er nok bare noget, man skal vænne sig til. Fletch er vores forsøg på at lave et højniveau-sprog, som kan gøre nogle lavniveau ting med understøttelse fra systemet,« sagde Kasper Lund.

Google har netop frigivet version 0.1 af Fletch, og foreløbig understøtter den kun Raspberry Pi. Det kan synes paradoksalt, fordi det netop er en enhed, som understøtter mange andre sprog end eksempelvis C.

»Raspberry Pi er en stor computer i Internet of Things-sammenhæng, men den er let at få fat på. Lige nu kigger vi først på 32 bit systemer, og der er også nogle Arduinoer, som passer på det, og de kommer nok i næste omgang en gang næste år,« sagde Kasper Lund.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (20)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
David Christensen

...du er godt klar over, at vtable-kald performer næsten lige så godt som native invokering, med en ordentlig optimerende compiler—noget jeg formoder Google har styr på med deres tidligere arbejde på V8 JIT VM-platformen? Der er jo et minimalt sæt af instruktioner, der indgår heri.

Det er rigtigt, at med multipel nedarv bliver det en hel del mere kompliceret. Men der er næsten heller ikke sprog udover C++ der supporterer dette. Protokoller og enkel nedarv er noget, der giver rigtig fin performance.

Og så skal vi ikke glemme, at OOP er en, for rigtig mange, naturlig abstraktion. Det var netop årsagen til at SIMULA, siden Smalltalk, og Objective-C og, ja, C++ blev store successer.

Problemet er, at rigtig mange ting bliver, for mange, mere komplicerede uden OOP, særligt hvis man, som det lader til hér, understøtte low-level operationer gennem intrinsic funktioner eller specielle funktioner. Hvis ikke disse pakketeres på en logisk måde, er det 'sgu svært at huske; om ikke andet, som statiske metoder...

Jeg får/fik ofte fornemmelsen fra dig, at imperativ udvikling er lidt et fy-ord, men faktum er, at imperativ udvikling, med den logiske ovenbygning, klasse-baseret OOP, er klart de mest produktive sprogtyper til applied programming.

At man så ikke kan lire faktorialfunktions-onelinere af, eller bevise at listefoldning fra højre er genialt uden side effects (dette er en joke), kan man vel godt leve uden... ;-)

David Christensen

Fordi Go netop er en C-konkurrent, med en stejlere indlæringskurve end Dart, i hvert fald hvis man skal tro traditionel visdom.

Derudover har Go strukturer som message pipes som er ret centrale i sproget, men som er svære for nybegyndere at konceptualisere. Og som måske er lidt overkill på en Atmel ATMEGA µC.

Endelig har Go en spøjs "OOP"-model. Type-associerede funktioner. For at elske det skal man, efter min mening, kende til mere traditionel klassebaseret OOP, for at se det geniale deri...

Derudover er det meget begrænset, hvilke arkitekturer, den native go compiler targeter (x86 og amd64). Alternativet er at bruge en go-frontend til gcc... og det er ikke en særlig fed oplevelse. Derimod har Google en rigdom af readymade teknologi fra deres V8 VM (som er Darts native platform) de kan anvende i denne kontekst...

Palle Due Larsen

Fletch er ikke som sådan et nyt sprog, det er bare en ny måde at køre Dart på. Og der bliver ikke brugt vtables, selector based row displacement bliver netop brugt til at reducere en 2-dimensionel tabel over tabeller og metoder, så der bruges mindre plads.

Hele formålet med øvelsen er, at få flere udviklere til at udvikle til microcontrollere, derfor mener Google, at man har brug for et objektorienteret sprog med garbage collection.

David Christensen

Fletch er ikke som sådan et nyt sprog, det er bare en ny måde at køre Dart på. Og der bliver ikke brugt vtables, selector based row displacement bliver netop brugt til at reducere en 2-dimensionel tabel over tabeller og metoder, så der bruges mindre plads.

Det giver selvfølgelig god mening, da det trods alt er muligt at tilføje metoder etc. i runtime i Dart. Så ved at komprimere dispatch tabellen kan man reducere pladsmæssig overhead, hvilket er ret vigtigt på nogle af targetarkitekturerne...

Cool stuff.

David Christensen

Jeg tager her udgangspunkt i ATMega-arkitekturen, da Arduino (der anvender disse) er nævnt i artiklen.

Vi taler her om en CPU der kan adressere max 64 kilobyte RAM. I de fleste konfigurationer, ml. 2 og 8 kilobyte.

Endvidere er det en Harvard-arkitektur, altså en arkitektur hvor data og instruktioner er separate.

Embedded Java findes ikke til en sådan arkitektur. Ganske enkelt fordi det er for stort. Den eneste teoretiske mulighed er Java for Smart Cards, https://en.wikipedia.org/wiki/Java_Card

...men det er så forældet, og ubrugeligt til general purpose-udvikling.

Generelt er .NET og Java begge store, tunge systemer (også .NET Compact og Java ME, i denne kontekst). Skidegode til Enterprise-udvikling, brugbare til mobiludvikling med en hel del udeladelser... men på noget så småt og begrænset, kommer det bare ikke til at ske.

David Christensen

Undskyld. Det var en fortalelse.

Det var i konteksten af udvikling til de helt små embedded platforme, jeg mente. CLOS er et stort system, som Common Lisp i sig selv. Eiffel kan vi vel godt kalde et nichesprog (og intet ondt ment dermed). Perl mister langsomt tyngde (Perl 6 kom aldrig...) bortset fra primært *nix-systemadministratorer over en vis alder... Python er for stort, og Pascal, også OOP-varianterne—trods en ihærdig flok kommentatorer herinde—bliver mindre og mindre relevant. De eneste af ovenstående nævnte der er appropriate er kontekst er, dermed, C++.

Du tager i øvrigt fejl om TCL—TCL er ikke i sin natur OOP, men der findes en lang række extensions. Nogle af disse med multipel nedarv, andre uden...

David Christensen

Jeg ved faktisk ikke, hvordan det forholder sig i Dart. Men i Javascript gemmes alle tal, integers som floats, som 64-bit double precision floats (derfor de fjollede tricks med at typedeklarere en variabel som integer ved at bitshifte den, i Asm.js)...

Det kræver dermed en hel del konvertering...

Så mon ikke man her går efter en lidt mere native datatype.. også taget i betragtning af en god del af måldevices ikke har en FPU...

Ivo Santos

Jeg kan da godt forestille mig at dem der går fra javascript / .net og lign. sprog har svært ved at programmere i C da man ikke for noget som helst foræret, altså ud over at sproget i sig selv nok er det mindst komplekse i forhold til andre sprog.
Det jeg umiddelbart vil mene er det sværeste i C er at holde styr på pointers samt allokerede hukommelse, ud over det er da ellers et nemt sprog at have med at gøre, det er min personlige mening.

Troels Henriksen

"Næsten ingen"? C++, CLOS, Eiffel, Perl, Python, TCL, en del varianter af Pascal, ...

Multipel nedarvning i CLOS er som udgangspunkt enklere end i C++, idet CLOS fladgør klasselisten. I C++ kan ud derimod nedarve flere gange fra den samme klasse, og ende op med forskellige, helt uafhængige instanser. (Man undgår dette ved at bruge virtuel nedarvning.)

Desuden er metodeopslag i CLOS væsentligt langsommere end i C++, selv for de indbyggede metodekombinatorer, og kan kun gøres nogenlunde hurtigt via JIT-lignende caching-mekanismer - det kommer aldrig til at flyve på en resursebegrænset indlejret enhed.

Log ind eller Opret konto for at kommentere