Hils på Noop - Googles Java-agtige sprog uden null-pointere

Googles nye programmeringssprog, Noop, er sat i verden for at blande de bedste fra den nye og gamle verden af programmeringssprog. Ifølge en dansk datalogilektor er der dog ikke så meget nyt at komme efter.

Google har netop løftet sløret for et nyt programmeringssprog, Noop, der kører på Javas virtuelle maskine og ligner sproget på syntaksen.

Noop er navngivet efter assemblerinstruktionen No Operation og udtales derfor med samme ordlyd som i 'cooperation'. Sproget blander den bedste lærdom fra både gamle og nye programmeringssprog, skriver udviklerne bag Noop.

Designerne af sproget arbejder blandt andet på at få indført unit tests som en del af sproget, så programmøren ikke selv skal tilføje muligheden via tredjepartssoftware. Samtidig understøtter Noop dependency injection, som kan bruges til at minimere koblingen mellem klasser.

Datalogilektor og Version2-blogger Torben Mogensen har taget et hurtigt kig på beskrivelsen af Noop, og den umiddelbare dom er, at der ikke er så meget nyt under solen.

»Der er en masse ideer, men ikke meget konkret at gå efter. Ideerne er gode, og mange af dem kommer fra funktionelle sprog såsom Standard ML og Haskell, og det er ikke første gang, at idéer fra de sprog er forsøgt overført til objektorienterede sprog,« siger Torben Mogensen.

Skrotning af null pointers og dynamic subclassing hitter
Han fremhæver dog et par designbeslutninger i sproget, som ikke er hverdagskost.

»Det er ikke almindeligt, at man på objektsiden fravælger null pointers som default og implementation inheritance. De har altid været mine yndlings hade-features ved objektorienterede sprog, så det synes jeg er positivt,« siger Torben Mogensen.

I objektorienterede sprog er det normalt, at alle objektreferencer implicit kan være 'null'. Det betyder, at programmøren skal sørge for at skrive fejlhåndtering ind i koden, da 'null' som udgangspunkt ikke er en spiselig reference.

Der kan dog være enkelte tilfælde, hvor 'null' bruges aktivt, for eksempel som den reference, det sidste element i en hægtet liste peger på.

Men derfor er det bedre at kunne slå null pointers til, når man har brug for dem, og så slippe for dem resten af tiden, mener datalogilektoren.

»Tony Hoare (opfinderen af bl.a. Quicksort, red.) har sagt, at en af hans største fejltagelser var at introducere null pointers i sproget Algol W. Jeg synes, det giver god mening at fravælge null pointers som udgangspunkt og så lade det være en option, man selv kan vælge til. De er primært en kilde til fejl,« siger Torben Mogensen.

Beslutningen om at skrotte implementation inheritance - også kendt som dynamic subclassing ? er endnu et positivt træk ifølge Torben Mogensen.

Java-folket og objektorienterede programmører vil nikke genkendende til dynamic subclassing, som betyder, at den samme variabel på forskellige tidspunkter kan få værdier, der ligger i enhver subklasse af den erklærede.

»Det er en god ide at fjerne subclassing, fordi man i de fleste tilfælde kan klare sig på nedarvning på typer, og ikke implementeringer. De mekanismer, der træder i kraft på køretid, er ikke trivielle, og det er noget, selv garvede programmører kan have svært ved at gennemskue,« siger Torben Mogensen.

Kildekodefiler i Noop kan behandles på tre måder. En Java-translator kan oversætte Noop-kildekoden til Java-kildekode, Noop-koden kan afvikles gennem en fortolker, og endelig kan Noop-koden compiles til Java-bytecode.

Noop er lige nu i sin spæde begyndelse, og interesserede udviklere kan læse mere om sproget på hjemmesiden under fanebladet Eksterne links.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (11)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Baldur Norddahl

Så vidt jeg kan gennemskue, så har de indført at man ikke kan nedarve fra andre klasser. Man kan kun implementere grænseflader (interface i java termologi).

Keywordet "extends" er simpelthen afskaffet, undtagen at et interface godt kan nedarve fra et andet interface.

Så hvis man ønsker at nedarve fra en klasse, så må man implementere de samme grænseflader som den pågældende klasse og så manuelt lave proxy metoder for de metoder der skal føres uændret til den oprindelige klasse.

Implementation inheritance betyder at en nedarvet klasse kan genbruge kode fra super-klassen. Altså at man kan kalde metoder fra super-klassen, modsat et interface hvor man er nødt til selv at implementere hver enkelt metode.

  • 0
  • 0
Lasse Hillerøe Petersen

Skal vi nu belemres med endnu et elendigt designet sprog, bare fordi det bliver hypet af en fremstående aktør i IT-verdenen (lisom Java (Sun)og C# (MS))? Heldigvis ser det ikke ud til det - er det ikke bare en Google-ansats kæleprojekt, der er blevet mediehypet lidt ud over hvad det kan bære, i den klassiske Fjer-til-Høne maskine?

Indtil videre kan der i hvert fald ikke koges meget suppe på den høne: syntaksen er ikke fastlagt, der er ingen biblioteker, ingen implementation, nil. (Nil er i øvrigt navnet på et andet tilsvarende projekt fra Alex Eagle, ser det ud til. Eller måske en forgænger?)

Er der i øvrigt nogen der kan forklare mig hvorfor alle nyere programmeringssprog skal ligne C? I disse microbrew tider kan man undre sig over, at næsten al kode ligner reklame for Tuborg, med alle de krøllede parenteser.

/Lasse

(som ville ønske nogen ville udvikle en Algol68 implementation med bedre biblioteksstøtte/foreign interface, måske et par tilføjelser fra OOP, og evt gerne kompileret til JVM.)

  • 0
  • 0
Torben Mogensen Blogger

Er der i øvrigt nogen der kan forklare mig hvorfor alle nyere programmeringssprog skal ligne C?

Det er heldigvis ikke alle nyere programmeringsprog (se f.eks. F#).

Men jeg giver dig ret i, at mange sprog gør det. Tendensen blev særlig markant efter Java, som valgte C for at gøre sproget mere spiseligt for C/C++ programmører. Bjarne Stroustrup bemærkede efterfølgende, at han synes, at det var sjovt, at Java valgte netop syntaksen fra C++, som han selv synes var en af de ringeste aspekter ved C++. Jeg kan kun være enig.

Efter Java kom frem overvejede jeg, om man kunne gøre SML mere "spiselig" ved at give det en C-lignende syntaks. Jeg gjorde ikke noget ud af det, for det ville ikke i min bog gøre sproget bedre. Men det kunne have været sjovt at se.

  • 0
  • 0
Torben Mogensen Blogger

Jeg vil lige uddybe min kommentar om inheritance, som jeg blev citeret for.

At en variabel på køretid kan få en værdi, som er af en subklasse af den erklærede type, er i Java-lignende sprog primært brugt til tre ting:

  1. At lave polymorfe klasser såsom collections, der kan have elementer af vilkårlig type. Det gjordes (inden generics blev tilføjet) ved at erklære elementtypen til at være Object, så man kan bruge elementer af vilkarlig type.

  2. Det samme, som man kan bruge interfaces til.

  3. At definere, at en variabel kan have værdier fra flere beslægtede typer, som erklæres som subklasser af en (måske abstrakt) superklasse. Altså det, der svarer til en union-type i C eller en sum-type i SML.

Jeg synes blot, at hver af disse ting kan gøres nemmere og mere elegant ved netop at bruge generics (parametrisk polymorfi), interfaces (dog helst i en form, der minder mere om Haskells typeklasser) og sumtyper. Hver af disse har en enklere semantik end implementation inheritance og undgår det køretidsoverhead, som implementation inheritance giver.

  • 0
  • 0
Daniel Madsen

Takker for uddybelsen, jeg var også en af dem der undrede mig lidt over de fancy betegnelser i artiklen :)

Men jeg synes det virker som om at de lidt begår samme "fejl", som i Java og forsøger at pakke programmøren ind i vat.

Jeg bryder mig generelt ikke om den her tendens med at hvis noget kan misbruges, så laver vi sådan en laveste fællesnævner beslutning og fjerner muligheden helt fra sproget.

Jeg synes det er fint hvis sproget advarer mod at jeg bevæger mig ud på farlig grund, f.eks. synes jeg C# gør dette meget godt i forhold til at få adgang til at benytte "unsafe" kode. Men hvis jeg vælger selv at tage risikoen for at skyde mig i foden, så vil jeg gerne have adgang til pistolen.

  • 0
  • 0
NA NA

Hvis man kigger på det eksterne link finder man en liste over ting som er med og ting som ikke er med.

Ting som ikke er med:

  1. Implementation inheritance. En beslutning som gør det umuligt/svært at lave en fornuft objektmodel.

  2. Primitive typer. En beslutning som gør det umuligt at lave effektivt kode. Java har primitive typer og det gør at det rent faktisk er muligt at skrive ekstremt effektiv kode i Java (vha bit manipulation) - de få steder det giver mening.

Ting som er med:

  1. Properties. C# indførte properties og det er årsagen til at meget C# kode man ser er fuldstændigt håbløst. Det giver simpelthen ikke mening at lave syntaktisk sukker for noget som er bad practice (get/set metoder).

Tror ikke lige at det er et sprog jeg kommer til at anvende :)

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