Scala-folk får 17 mio. kr. til at gøre sproget mere parallelt

Et interessant projekt, der favner mange områder. Jeg er dog lidt bekymret for, om JVM er den rette platform til dette, da der er mange dele af JVM's design, der er en hemsko for parallelisme. Så måske er vejen frem af adskille Scala fra JVM og lave en ny (og mere parallel) abstrakt maskine til Scala.

Ikke alene er JVM'en enormt outdated og uegnet (se f.eks. denne gamle RFE omkring tail recursion: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4726340), men Scala er også et underligt mishmash af paradigmer og type-systemer.

Så virker Go og Fantom (og til dels F#) noget simplere, selv om det desværre ser ud til at Scala løber med al opmærksomheden og resourcerne.

Man kan håbe at SCALA vil flytte sig væk fra JVM og måske bruge LLVM (https://github.com/greedy/scala/blob/llvm/README.llvm) eller andet, så hele stacken er mere åben, også for forbedringer som ikke kun Oracle vil det.

Ellers er der jo altid Erlang man kan falde tilbage på :-)

Hej Casper

Nu har du selvfølgelig ret til din vurdering af Scala, men jeg synes det er lidt for letkøbt at kalde sproget for et miskmask.

Scala er mere objektorienteret end Java (og Fantom) idet det erstatter statiske funktioner og værdier med singleton-objekter, hvilket nedsætter antallet af koncepter og gavner kompositionaliteten.

Scala har derudover formået at trække på tidligere arbejde med at låne nyttige elementer fra funktionsorienterede sprog og har ikke blot funktioner, men også algebraiske datatyper og pattern matching. Det gør at rigtig mange typiske programmeringsopgaver kan implementeres i en meget ligefrem stil i stedet for at bruge mere komplicerede patterns.

At der er gjort et stort arbejde for at lave et rigt typesystem som muliggør mange programmer, kan vist også kun tale til sprogets fordel.

Go er et helt andet dyr der er interessant fordi det udelader komplicerede, men allestedsnærværende elementer som nedarvning og dynamisk dispatch.

Fantom har modsat Scala et "simpelt" typesystem og udviklerne bag er ikke kede af at det ikke er sundt.

Med hensyn til ressourcer, så har F# og Go store, pengestærke firmaer i ryggen, mens Scala udvikles af en teknisk højskole i Schweiz. Det er nok derfor du hører mere om hver gang Scala-teamet får lidt småpenge at udvikle for.

Hvis man sætter sig ned og læser deres grant-draft, så lærer man hvad projektet går ud på. Ideen er som følger (det er løst skrevet fordi man i grants ikke vil ud med alt sin forskning):

Man vil udstyre Scala med værktøjer som lader en domæneekspert (en parallelprogrammør) kunne interface til heterogene CPU-miljøer (tænk grafikkort GPU'er ved siden af CPU'er). Eksperten skal så forfatte et domænespecifikt sprog (et DSL) som derefter skal benyttes til at skrive programmer i. Selvsagt er der tale om en specialisering og metoden kan nok ikke anvendes generelt.

Jeg vil nu ride min kæphest: Parallellisme og Concurrency er IKKE det samme. P. er en egenskab ved maskinen hvor det handler om at udnytte dens enheder maksimalt - således at programmet kører så hurtigt som muligt. C. er en egenskab ved programmet: Det handler om at beskrive flere samtidige hændelser så nemt som muligt så man kan give illusionen af at "der sker flere ting på samme tid". Standardeksemplet på et ikke-parallelt concurrent program var de oprindelige operativsystemkerner, før multicore-maskiner var en realitet. Jeg er ikke ene om dette synspunkt. Se for eksempel de første minutter af Guy Blelloch's keynote på ICFP 2010-konferencen:

http://www.vimeo.com/16541324

Både Go og Erlang er concurrent programmeringssprog. Bevares, de kan begge spinne flere cores op og udnytte dem, men målet er ikke at få programmer til at køre hurtigere - det er en sideeffekt at det rigtige mål: Nemlig at beskrive programmer på en måde så du nemt kan forstå samtidigheden i dem.

Bemærk endvidere at både Go som Erlang kræver at dine processor-cores er homogone (ens). Ideen i Scala-grantet er at gå efter heterogene cores hvor altså en del af arbejdet skal udføres af SIMD-orienterede GPU-lignende cores. Hverken Go eller Erlang passer specielt godt ind i et heterogent miljø, hvis rå hastighed er målet.

Tilbage er der spørgsmålet om JVM'en er det rigtige valg. Når man kigger på grantet er der ikke umiddelbart noget i JVM'en der hindrer den planlagte model. Det DSL som skrives til at køre på GPU'en har næppe nogen direkte indflydelse på JVM'en da det meste er koden kommer til at køre som "fremmed" kode i et C-lag nedenunder. Der er heller ikke noget til hinder for at lave Go eller Erlang ovenpå JVM'en (se Erjang-projektet f.eks., eller slå kilim-projektet op). Desuden har JVM'en en af de bedste parallelle garbage collectors der findes - så er din plan "one heap to rule them all and in darkness bind them", da er JVM'en et ganske fortrinligt valg.

Det primære problem, at JVM'en er ringe til funktionelle sprog, det kunne der godt komme en løsning på efterhånden som Java mister sin position som "hovedsprog". Så set ud fra et engineering-synspunkt er det formentlig mere værd at holde på resten af styrkerne ved JVM'en (GC'en, JIT-compileren).

LLVM kan slet ikke komme i spil alene iøvrigt. LLVM har kun GC-intrisics og det er op til den enkelte at beskrive "rigtig" garbage collection selv. Desuden er LLVM en high-level assembler med begrænset power når det gælder om at lave funktionelle sprog (det er et førsteordenssprog, så du skal alligvel lambda lifte/closure converte). Med andre ord kræver LLVM langt mere arbejde end at basere sin løsning på JVM'en.

Nu har du selvfølgelig ret til din vurdering af Scala, men jeg synes det er lidt for letkøbt at kalde sproget for et miskmask.

Det rigtige svar er at sproget ikke er særligt minimalt. Scala blander en masse koncepter - hvilket får skeptikeren til at betvivle sproget. Der er simpelthen for meget blandet ind i sproget allerede nu til at der er meget rum for videre udvidelse. Scala er for Java hvad C++ er for C. Naturligvis har det både fordele og ulemper.

Go er et helt andet dyr der er interessant fordi det udelader komplicerede, men allestedsnærværende elementer som nedarvning og dynamisk dispatch.

Go har faktisk nedarvning (konceptet er en embedding af en subtype i en anden, men essensen i det er det samme som nedarvning). Desuden har Go dynamisk dispatch: [code=text]

package main

import "fmt"

type Outer interface { Outer() }

type A struct {} type B struct {}

func (a A) Outer() { fmt.Println("Hello") }

func (b B) Outer() { fmt.Println("世界") }

func main() { var o Outer a := new(A) b := new(B)

o = a o.Outer() o = b o.Outer() } [/code]

variablen 'o' er tydeligvis dynamisk dispatchet i ovenstående, afhængigt af om vi har en 'a' eller 'b' i den. Eksemplet kan pastes og køres på http://golang.org

Ikke alene er JVM'en enormt outdated

Hvorfor er det du mener at JVM er outdated? Hvad gør den outdated?

Det rigtige svar er at sproget ikke er særligt minimalt. Scala blander en masse koncepter - hvilket får skeptikeren til at betvivle sproget. Der er simpelthen for meget blandet ind i sproget allerede nu til at der er meget rum for videre udvidelse. Scala er for Java hvad C++ er for C. Naturligvis har det både fordele og ulemper.

Jeg anerkender spektikerens vurdering at sproget ikke er "minimalt" på samme måde som fx Scheme er minimalt. Spørgsmålet er om det i de fleste sammenhænge er et mål i sig selv.

Det er misvisende at påstå, at Scala skulle være for Java, hvad C++ er for C. Faktisk klarer den objektorienterede kerne af Scala sig med færre koncepter end Java, fordi der er tænkt over at gøre de koncepter der er i spil generelle og kompositionelle.

I Java har man fx både (statiske og instans-) felter, metoder, initializers og konstruktorer. Der er indre klasser, statisk indlejrede klasser og anonyme klasser (med et sæt af regler for hvordan disse strukturer kan indlejres i hinanden og referere værdier i konteksten).

Scala befinder sig - sammenlignet med andre sprog i samme designrum (Java, C#) - slet ikke ude på overdrevet i antallet af koncepter. Scala's sprogspecifikation er da også en lille sag på mindre end 200 sider. :-)

Så alt i alt kan jeg godt forstå skeptikerens umiddelbare førsteindtryk at det er kompliceret. Men jeg vil hævne at hvad der opleves som kompliceret afhænger af hvad man sammenligner med og hvad man kender i forvejen. Min påstand er, at Java på mange punkter er langt mere kompliceret end Scala.

Go har faktisk nedarvning (konceptet er en embedding af en subtype i en anden, men essensen i det er det samme som nedarvning). Desuden har Go dynamisk dispatch

+1 og tak for den forklaring! Det gjorde mig klogere.

Nu har du selvfølgelig ret til din vurdering af Scala, men jeg synes det er lidt for letkøbt at kalde sproget for et miskmask.

Du har naturligvis også ret til din holdning, men lad mig da uddybe lidt hvad jeg mener så. :)

Som der står i artiklen, så er "Scala et Java-baseret objekt-orienteret sprog". Hvorvidt denne definition kommer udaf at Scala først og fremmest er henvendt JVM'en (kører jo ellers også på CLR'en mv.), eller fordi der tilbydes interoperabilitet med de eksisterende Java biblioteker, står lidt hen i det uvisse. Men faktum er, at en del af type-systemet og sprogets design, ser ud som det gør pg.a. denne bro-kobling imellem de to verdener. Det kan naturligvis aldrig blive en 1:1 mapning, som du f.eks. vil se hvis du i Scala forsøger at få fat i en protected inner static Java klasse fra en super-klasse, jvf. fejlen "error: class... cannot be accessed in object..."

Scala er mere objektorienteret end Java... nedsætter antallet af koncepter og gavner kompositionaliteten.

Scala er ikke bare mere objektorienteret, det er mere type-sikkert end de fleste andre mainstream sprog. Det betyder desværre netop at flere koncepter introduceret, som f.eks. forskellen på Null, null, nil, Nothing og None. Så dette punkt er jeg nok ret uenig med dig i.

Fantom har modsat Scala et "simpelt" typesystem og udviklerne bag er ikke kede af at det ikke er sundt.

Jeg er ikke 100% sikker på hvad du mener her, men jeg gætter på det er din fortolkning af Fantom's middle-road approach med at binde til dynamiske typer hvor og når man ønsker. Det er ellers netop her vi har muligheden for at begrave stridsøksen imellem static og dynamic, en tendens man iøvrigt ser i andre mainstream sprog også som f.eks. C#.

mens Scala udvikles af en teknisk højskole i Schweiz.

Ahh det er nok lige at underdrive lidt. EPFL er et teknisk universitet fordelt på 65 bygninger og med 7000 studerende og nogle af de mest indflydelsesrige Ph.d'er inden for CS (Odersky har skrevet dén javac der bruges til daglig af mio. af programmører verden over). Faktum er at Scala har opnået den kritiske masse, men det vil samtidig udgøre en stor fork af det etablerede Java community simpelthen fordi det splitter mere end det samler.

Hvorfor er det du mener at JVM er outdated? Hvad gør den outdated?

Umm det er en stor klodset lastbil, når man langt hen af vejen bare skal bruge en minivan. JVM'en er outdated fordi den ikke har været i stand til at følge med lean trenden, hvorfor også Google valgte at lave deres helt egen VM. JVM'en er meget tung at varme op, understøtter kun i ringe grad dynamiske sprog (f.eks. ingen dynamic dispatch), eller funktionelle (f.eks. ingen tail recursion).

Og så er samtlige instruktioner p.t. brugt så det er faktisk umuligt at viddereudvikle her (invokeDynamic får vist den sidste tilbage). Dette er en konsekvens af dét design Gosling i sin tid valgte, hvor der skulle være fokus på fortolkning og kun sekundært JIT kompilering (dén dag i dag starter Java kode med først fortolket, dernæst evt. kompileret). Der er f.eks. 4 forskellige JVM instruktioner for hver basal regneart, en for hver type (så for at lægge til er der dadd for double, iadd for integer, ladd for long og fadd for float).

Scala er ikke bare mere objektorienteret, det er mere type-sikkert end de fleste andre mainstream sprog. Det betyder desværre netop at flere koncepter introduceret, som f.eks. forskellen på Null, null, nil, Nothing og None. Så dette punkt er jeg nok ret uenig med dig i.

Med koncepter mente jeg i grove træk "language features". Alene det at objektsystemet i Scala er mere generelt end det i Java (fx ingen statics) betyder at antallet af koncepter er mindre.

Et andet eksempel er void. void er et keyword i Java, der betyder at en metode ikke har nogen returværdi. Det betyder at der findes to forskellige koncepter for metoder, som ikke passer ret godt sammen.

Hvis du fx har et interface Visitor hvor T er returværdien af visit metoderne, så kan du ikke have en Visitor instans af den type. (Man kan have en Visitor, men den eneste værdi der kan konstrueres af typen Void er null så man er nød til at skrive 'return null' i hver af visit metoderne.)

I Scala har alle metoder har en returværdi. Der er altså skåret ét koncept væk, så vi kun har én slags metoder at arbejde med. Man kan vælge at returnere værdien () af typen Unit, som er en singleton-værdi der ikke indeholder nogen information. Det svarer i alle henseender til en metode uden returværdi, men uden at introducere et særligt koncept for det.

Mht. de konkrete eksempler du nævner så findes null i Java. nil er et objekt, der repræsenterer den tomme liste, som også findes i Java via Collections.emptyList(). None er ikke en language feature, men én case for Option-typen der er en slags collection der kan indeholde ingen eller netop ét element. Java har næsten tilsværende Collections.singletonList(element) og Collections.emptyList(), og man kan sagtens implementere og bruge Option i Java.

Så hvis du med "koncepter" mener language features så har Scala lidt færre*, men mere generelle language features. Hvis du mener standardfunktioner og -typer, så har Scala flere idet det har sine egne og alle Java's.

• mit bedste gæt for jeg har ikke talt efter

Jeg er ikke 100% sikker på hvad du mener her, men jeg gætter på det er din fortolkning af Fantom's middle-road approach med at binde til dynamiske typer hvor og når man ønsker. Det er ellers netop her vi har muligheden for at begrave stridsøksen imellem static og dynamic, en tendens man iøvrigt ser i andre mainstream sprog også som f.eks. C#.

Jeg hentydede egentlig til hensigtserklæringen om at typehuller ikke nødvendigvis er noget problem: http://fantom.org/sidewalk/topic/254

Fantom har ligesom Java (usikker) support for kovarians i collections. Det gælder dog så vidt jeg kan forstå kun for Map og List. For mig at se giver sådanne særtilfælde og ad-hoc regler et mere kompliceret sprog end ét med færre og mere generelle koncepter. Ref: http://fantom.org/doc/docLang/TypeSystem.html

Med hensyn til at bilægge stridsøksen mellem dynamisk så er det et spændende, aktivt forskningsområde at lave udtryksfulde typesystemer der kombinerer statisk og dynamisk typning.

Fantom er ikke state-of-the-art i det rum. Det som man typisk vil opnå er automatisk at få en høj grad af statisk sikkerhed og statisk dispatch hvor det er muligt (dynamisk dispatch baseret på et type tag er langsommere end et statisk dispath). Fantom's særlige dynamiske metodekaldsoperator -> gør at programmøren skal skelne mellem forskellige typer dispath og lave casts. Det er altså en lækker syntaks for manuelt at programmere med reflection og casts.

Jeg synes også at Fantom er et hyggeligt hack-as-we-go sprog. Jeg er dog uenig i at Fantom - i kraft af at det har et svagt og usikkert typesystem med ad-hoc regler og en lækker syntaks for reflection - bliver "simpelt" og dermed fortjener noget af Scala's opmærksomhed og ressourcer.

Odersky svarer på en del af de ting I diskuterer i dette interview:

http://www.infoq.com/interviews/martin-odersky-scala-future

Umm det er en stor klodset lastbil, når man langt hen af vejen bare skal bruge en minivan.

Hmm. det er så din holdning. Det er ikke megen argumentation du fører for din påstand. F.eks. har JVM en sikkerhedsmekanisme som jeg tror det er svært at finde i ret mange andre VM's. JVM er åp 97% af mobile håndsæt, og det er en af de største server VM's på markedet.

JVM'en er outdated fordi den ikke har været i stand til at følge med lean trenden,...

Kan du ikke give nogle eksempler på VM's der følger lean trenden og hvad du mener med lean trenden?

hvorfor også Google valgte at lave deres helt egen VM.

Det var vist mere pga. licensering, men smid bare nogle links der bekræfter din påstand. Desuden var Google's fejl at de flyttede Java sproget med. VM'en da super god, men sproget er outdated. Er det ikke det du egentligt blander sammen :-)

JVM'en er meget tung at varme op, understøtter kun i ringe grad dynamiske sprog (f.eks. ingen dynamic dispatch), eller funktionelle (f.eks. ingen tail recursion).

Opvarmning, er korrekt, specielt hvis du kører på pre Java 5 VM's. Java 6 VM er meget hurtigt startende - og har en yderst god performance. JVM findes stort set på alle platforme (og er supporteret der af virksomheder)

Og så er samtlige instruktioner p.t. brugt så det er faktisk umuligt at viddereudvikle her (invokeDynamic får vist den sidste tilbage). Dette er en konsekvens af dét design Gosling i sin tid valgte, hvor der skulle være fokus på fortolkning og kun sekundært JIT kompilering (dén dag i dag starter Java kode med først fortolket, dernæst evt. kompileret).

Men mon ikke de finder en vej ud af den spændetrøje, ligesom de fandt en vej ud af only 32-bit/2GB heap space problematikken. Desuden arbejder Gosling ikke længere for Sun/Oracle, så nu er han der ikke til at være stopklods for forbedringer og ændringer.

Der er f.eks. 4 forskellige JVM instruktioner for hver basal regneart, en for hver type (så for at lægge til er der dadd for double, iadd for integer, ladd for long og fadd for float).

Kan det være fordi at man så super hurtigt kan optimere mod en specifik arkitektur? F.eks. en der kræver streng alignment (læs: Sun SPARC). CLR f.eks. har een arkitektur pt. som er x86 (den er vist ikke så kræsen med alignment). Desuden har JVM runtime optimization (Hotspot), hvilket jeg ikke helt er sikker på om CLR har fået endnu. CLR har dog på en del punkter en del bedre designløsninger, men de løber jo også ind i problemer på et tidspunkt.

Jeg kunne ligesom dig også godt tænke mig at der blev support i JVM for de ting du påpeger (dynamike sprog, tail recursion osv.) JRuby, Groovy, Scala, Clojure m.fl. kunne alle nyde godt af dette. Men som din egen RFE beskriver er der problemer med at supportere fuld tail recursion i JVM (problemer som proper exception reporting, debugging, sikkerhed mv.). Problemer som man er nødt til at tage højde for, i en professionel og højt ydende VM som er meget udbredt. InvokeDynamic som skulle komme i Java 7, bliver dog et stort plus for bla. Groovy. Ligesom direkte support for closures, som skulle komme i Java 8 (med en yderst sindsyg syntaks - hvorfor skal de hele tiden finde på en ny syntaks, som er super lam i forhold til etablerede måder at gøre det på? sagde nogen NIH), måske kan redde lidt af Java som sprog.

Vi kan så snakke om, at Sun muligvis valgte den forkerte strategi for bagudkompatibilitet, hvor Microsoft lærte af det mht. CLR og har valgt en bedre strategi. Der er dog intet i vejen for at Sun/Oracle sadler om, det er fair nok, at fok på et tidspunkt skal recompilere deres kode med den nyeste javac for at kører på den nyeste JVM (det gør de alligevel i dag).

JVM er måske den virtual machine der er flest programmeringssprog til, og det siger noget. Der er en horde af funktionelle sprog, dynamiske sprog osv. Den er derfor ikke helt så ringe som nogen her i tråden påstår. Den er desuden klippestabil, hvis man altså behandler den ordenligt, og afvikler den på et stabilt OS (!Windows).

Hmm. det er så din holdning. Det er ikke megen argumentation du fører for din påstand. F.eks. har JVM en sikkerhedsmekanisme som jeg tror det er svært at finde i ret mange andre VM's. JVM er åp 97% af mobile håndsæt, og det er en af de største server VM's på markedet.

Jeg skal love for du får blandet bolcheposen; footprint vs. sikkerhedsmodel vs. JME distribution vs. JEE.

Kan du ikke give nogle eksempler på VM's der følger lean trenden og hvad du mener med lean trenden?

Med lean mener jeg skåret ind til benet, de væsentlige ting. Men kommentaren er nu mest knyttet til JRE som helhed, da en typisk installation i dag fylder over 50MB og indeholder 20.000 klasser incl. en masse legacy som Corba, AWT osv.

Det var vist mere pga. licensering, men smid bare nogle links der bekræfter din påstand.

Det er mere end licensering, JME er stack-baseret med nogle ret tunge method-JIT optimeringer lånt fra HotSpot. Hvorimod Dalvik er register baseret og med trace-JIT'er istedet for method-JIT'er. Der er masser af resourcer der forklarer Dalvik og dens designmål, det behøver jeg vel næppe linke til. Der er gode forelæsninger på nettet fra både Parleys og Google IO

Desuden var Google's fejl at de flyttede Java sproget med. VM'en da super god, men sproget er outdated. Er det ikke det du egentligt blander sammen.

Ja, Java er i dag et forældet og klodset sprog, men en fejl vil jeg næppe kalde det! Det var deres vision allerede tilbage i 2003, at udnytte de mange mio. eksisterende Java udviklere der fandtes. Og at dømme efter Android's success, var det vist ikke helt dumt.

Men mon ikke de finder en vej ud af den spændetrøje, ligesom de fandt en vej ud af only 32-bit/2GB heap space problematikken.

Det er ligesom en lidt anden debat synes jeg, eftersom kun et nyt byte-kode format vil løse problemet. Og der er jo stort set intet sket siden det blev opfundet.

Desuden arbejder Gosling ikke længere for Sun/Oracle, så nu er han der ikke til at være stopklods for forbedringer og ændringer.

Nej han har skam ikke været involveret i mange år efterhånden. Og stopklodsen kom vist mest fra Oracle, IBM og de andre mastodonter i JCP'en der har så mange mio. liniers kode liggende at de helst bare ser status quo med sådanne ting.

Kan det være fordi at man så super hurtigt kan optimere mod en specifik arkitektur?

Nej det er vist mere fordi at JVM'en som sagt er designet med fortolkning for øje, og det er jo hurtigere at fortolke en type-specifik instruktion (man kender jo allerede typen) frem for at skulle udlede det fra omkringliggende operanter (som f.eks. CLR'ern gør).

Desuden har JVM runtime optimization (Hotspot), hvilket jeg ikke helt er sikker på om CLR har fået endnu.

Ingen tvivl om at JVM'en, grunden dens alder, indeholder en del flere hardcore optimeringer i JIT'en. CLR'en har AFAIK ikke adaptive (løbende profilering) JIT endnu, men den har tilgængæld den fordel at alt kompileres mindst én gang før det køres, hvor JVM'en kan være svær at blive klog på (stort set umuligt at benchmarke Java kode af samme årsag).

Der er dog intet i vejen for at Sun/Oracle sadler om, det er fair nok, at fok på et tidspunkt skal recompilere deres kode med den nyeste javac for at kører på den nyeste JVM (det gør de alligevel i dag).

Det tror jeg bare ikke de gør, Sun viste ikke rigtig vision de sidste mange år og JavaFX var jo en tåbelig escapade som kun de selv vist troede på. JavaFX kanibaliserede samtidigt så mange ting hos Sun (masser af folk skred og masser af JSR's blev droppet, bl.a. 2 jeg brugte, 295 samt 296). Vi får ikke rigtig generics og det ser heller ikke ud til at vi får ordentlige closures, så det kan da godt være man bare skal springe med på Scala vognen mede det samme. :)

Jeg skal love for du får blandet bolcheposen; footprint vs. sikkerhedsmodel vs. JME distribution vs. JEE.

Tja Java er i dag en platform, hvor JVM er den centrale del. Mange håndsæt solgt i dag kommer med en eller form for Java SE (og ikke JME mere).

Med lean mener jeg skåret ind til benet, de væsentlige ting. Men kommentaren er nu mest knyttet til JRE som helhed, da en typisk installation i dag fylder over 50MB og indeholder 20.000 klasser incl. en masse legacy som Corba, AWT osv.

Og hvilke VM's er det som er lean. Jeg synes faktisk at JVM er temmelig lean (den er dog meget større end 50MB, det er kun downloaden, og den er vist over 70MB for Java 6 :-) Corba og AWT er forældet teknologi, men bagudkompatibilitet gør at det stadigt leveres. Jeg synes dog det er lidt underligt at klage over en 50MB download i 2011, hvor harddiske og netværk har de størrelser og hastigheder de har. Størrelsen på Java er ikke vokset synderligt de sidste 8-10 år. Desuden er det jo fløjtende ligegyldigt at der leveres noget legacy med, hvis man ikke bruger det. Det er i hvert fald ikke noget man kan klandre JVM for.

Det er mere end licensering, JME er stack-baseret med nogle ret tunge method-JIT optimeringer lånt fra HotSpot. Hvorimod Dalvik er register baseret og med trace-JIT'er istedet for method-JIT'er. Der er masser af resourcer der forklarer Dalvik og dens designmål, det behøver jeg vel næppe linke til. Der er gode forelæsninger på nettet fra både Parleys og Google IO

Tja det kan vi gætte på. Det er klart at JVM ligesom CLR er stack baseret, og Dalvik er registerbaseret. JVM kører på mange arkitekturer og derfor gav en Stack baseret arkitektur god mening. Dalvik kører på een: ARM.

Det er ligesom en lidt anden debat synes jeg, eftersom kun et nyt byte-kode format vil løse problemet. Og der er jo stort set intet sket siden det blev opfundet.

AMD og Intel kunne godt finde ud af at lave amd64/emt64, og stadigt være bagudkompatible, men ikke en udviddelse af instruktionssættet kan laves uden at ødelægge kompatibilitet. Det er vel ikke en anden snak, du klagede over at man var nået til vejens ende for udvidelse af instruktionssættet, så jeg svarede bare.

Nej han har skam ikke været involveret i mange år efterhånden. Og stopklodsen kom vist mest fra Oracle, IBM og de andre mastodonter i JCP'en der har så mange mio. liniers kode liggende at de helst bare ser status quo med sådanne ting.

Nej ikke korrekt. Jeg har siddet på JCP EC (Executive Commitee), og de eneste med veto ret (og den brugte de tit og var stopklods), var Sun. Det er bla. en af grundene til at JME led som den gjorde (den eneste af platformene som Sun tjente penge på). Gosling har altid været modstander af udvidelser til Java, for han mente det var godt nok som det var, og det blev konstant referet på utallige JavaOne konferrencer.

Nej det er vist mere fordi at JVM'en som sagt er designet med fortolkning for øje, og det er jo hurtigere at fortolke en type-specifik instruktion (man kender jo allerede typen) frem for at skulle udlede det fra omkringliggende operanter (som f.eks. CLR'ern gør).

Det er korrekt. Det har så den ulempe for CLR at den er længere om at starte end JVM (al koden skal lige kompileres). Der er dog intet i vejen for at tilføje noget -XpreJIT til JVM så den ville opføre sig som CLR.

Det tror jeg bare ikke de gør, Sun viste ikke rigtig vision de sidste mange år og JavaFX var jo en tåbelig escapade som kun de selv vist troede på. JavaFX kanibaliserede samtidigt så mange ting hos Sun (masser af folk skred og masser af JSR's blev droppet, bl.a. 2 jeg brugte, 295 samt 296). Vi får ikke rigtig generics og det ser heller ikke ud til at vi får ordentlige closures, så det kan da godt være man bare skal springe med på Scala vognen mede det samme. :)

Det kan jeg kun tilslutte mig. Desværre fristes jeg til at sige.

Mange håndsæt solgt i dag kommer med en eller form for Java SE (og ikke JME mere).

Øhh gør de det? Hvilke, udover Nokia's ikke-sælgende top-of-the-line enheder? Android understøtter ikke JSE og iPhone ej heller. Netop derfor er det jo så tåbeligt at NemID bruger JSE applet teknologi med rødder i 1996.

Størrelsen på Java er ikke vokset synderligt de sidste 8-10 år.

Jeg har løbende tracket disse aspekter i et regneark, bla med "ls -R -1 | grep '.class' -c" der afslører at 1.4->1.5 steg fra 9236 til 12781 klasser, mens 1.6 steg til 17168 klasser. Så hvorfor du ikke mener Java er vokset, forstår jeg ikke - det er da ret nemt at følge.

JVM kører på mange arkitekturer og derfor gav en Stack baseret arkitektur god mening. Dalvik kører på een: ARM.

Android kører på x86 både af officielle (men endnu ikke åbne) veje og uofficielle. Check www.android-x86.org og www.androidx86.org

Jeg har siddet på JCP EC (Executive Commitee), og de eneste med veto ret (og den brugte de tit og var stopklods), var Sun

Interesant, det står i modstrid med alt hvad jeg har hørt. Og skriver du ikke selv, i en anden tråd, at Sun aldrig brugte deres veto ret? http://www.version2.dk/artikel/14268-skatteregler-forsinker-suns-java-butik

Det har så den ulempe for CLR at den er længere om at starte end JVM (al koden skal lige kompileres).

Det er så godt nok ikke min erfaring. CLR'en har yderligere den fordel, at det kompilerede image gemmes i GAC'en og kan memory-mappes direkte næste gang det skal bruges. Til sammenligning skal JVM'en jo hver gang møjsommeligt udpakke JAR, loade klasser, verificere disse, køre koden via fortolker for så omsider at JIT kompilere.

Øhh gør de det? Hvilke, udover Nokia's ikke-sælgende top-of-the-line enheder? Android understøtter ikke JSE og iPhone ej heller. Netop derfor er det jo så tåbeligt at NemID bruger JSE applet teknologi med rødder i 1996.

Nemlig. Nokia sælger klart flest telefoner i verden, og er klart ledende når det gælder om at sælge smartphones (som hos dem kører JSE).

Jeg har løbende tracket disse aspekter i et regneark, bla med "ls -R -1 | grep '.class' -c" der afslører at 1.4->1.5 steg fra 9236 til 12781 klasser, mens 1.6 steg til 17168 klasser. Så hvorfor du ikke mener Java er vokset, forstår jeg ikke - det er da ret nemt at følge.

I 1996 havde du haft ret, her i 2010/2011 er dette jo ingenting, men kune naturligt at der kommer mere til som tiden går.

Android kører på x86 både af officielle (men endnu ikke åbne) veje og uofficielle. Check www.android-x86.org og www.androidx86.org

Sejt! Det vidste jeg ikke.

Interesant, det står i modstrid med alt hvad jeg har hørt. Og skriver du ikke selv, i en anden tråd, at Sun aldrig brugte deres veto ret? http://www.version2.dk/artikel/1426...

Jo og det er også det rigtige. Men hvis man har været en del af dette forum, har oplevelsen også været at Sun brugte alle mulige andre metoder end netop veto, til at blokere for tiltag de ikke ville have, eller til at gøre det modsatte, promovere tiltag de ønskede. Så det jeg prøvede at sige på en kort måde var, at Sun omkring udviklingen af Java sproget (og JVM - for den er jo ikke en cross language VM, som f.eks. CLR, men tæt bundet til Java), har prøvet at blokere for tilføjelser og ændringer, da de deres holdning er/var at dette vil/vill gøre Java mere kompliceret og svært.

Om Tail Recursion, kan det vel siges, at det er en optimering som compiler/VM skal foretage, ikke noget vi som programmører skal lave (så bliver det IMO Goto-ish programmering).

Nå Nicolaj, skal vi så ikke bare blive enige om at det optimale ville være en alternativ VM (Parrot, LLVM, Mono) der er open source, fleksibel og ikke-polariseret. :) Mit største issue med Java verdenen har unægteligt været selvfedheden og skyklapperne. Det virker heldigvis som om den tid er ved at være forbi.

Hej Casper.

Jo lad os det :-)

Parrot tror jeg desværre ikke på længere.

Ja, Sun har med Java, begået den synd at hvile for længe på sin succes, og troet at det var nok at være enormt udbredt. De glemte også at lave forretning i den periode.

Oracle bibringer nok ikke det helt gode på den front. De har i hvert fald formået at skræmme en del kloge hoveder hos Sun ud af butikken, så de nu er spredt vidt omkring.

Om Tail Recursion, kan det vel siges, at det er en optimering som compiler/VM skal foretage, ikke noget vi som programmører skal lave (så bliver det IMO Goto-ish programmering).

Sludder og vrøvl.

Sludder og vrøvl.

Tak for dit yderst oplysende indlæg, som samtidigt er så velargumenteret, at det næsten kan tages seriøst.