Java and the F-word

Jeg opfatter ikke Java som et specielt trend-sættende programmeringssprog. Faktisk anser jeg Java for at være et temlig konservativt miljø. Bevares, der er folk der laver interessante ting på JVM'en, men som programmeringssprog er Java lidt bagude.

Derfor er foredrag og artikler om Java ikke det der står øvert på listen over ting der fanger min interesse. Havde det ikke været en keynote var jeg nok heller ikke gået til Brian Goetz foredrag Java Past, Present, and Future under sidste uges GOTO konference. Den store "nyhed": Java SE 8 får lambda-termer - og så er der vel ikke flere større sprog der ikke har anonyme funktioner i en eller anden afskygning?

Lambdaer er rare, men kun et skridt i retning af funktionel programmering. Det var først blandt konferencens sidste foredrag jeg spærrede øjnene op. Ben Christensens foredrag Functional Reactive Programming with RxJava handlede om hvordan Netflix håndterer concurency. Ofte ender man med en spaghetti af callbacks eller også anvender man Futures som kan være besværlige at sætte sammen i en større process. Med en sund dosis funktionel programmering bliver det let og elegant (her i Groovy):

def simpleComposition() {
  // fetch an asynchronous Observable<String>
  // that emits 75 Strings of 'anotherValue_#'
  customObservableNonBlocking()
    // skip the first 10
    .skip(10)
    // take the next 5
    .take(5)
    // transform each String with the provided function
    .map({ stringValue -> return stringValue + "_transformed"})  
    // subscribe to the sequence and print each transformed String
    .subscribe({ println "onNext => " + it})
}

Læs også Ben Christensens blogindlæg på Netflix' Tech Blog og dokumentationen til RxJava.

Det glæder mig at funktionel programmering bliver mere og mere mainstream og jeg håber at det bider sig fast og ikke bare bliver en hurtig hypet stil. Desvære ser jeg også enkelte tegn på at pendulet er svunget lidt for langt. Et enkelt foredrag fik jeg ikke meget andet ud af end "Functional good, object oriented bad" som et andet kampråb fra Kammerat Napoleon.

Kommentarer (29)
Casper Bang

Jeg så også Brian Goetz, og stillede spørgsmål¹² (som han ikke ønskede at svare på) men det var ikke rigtig noget overaskende. Sun og Oracle kunne have slået en streg i sandet, trykket på "reboot" engang så vi kunne få et moderne sprog at arbejde med. Toget er nu desværre kørt; guro'er og greenfield operatives (de fleste ThoughtWorks folk bl.a. ) er for længst hoppet over til alternative JVM sprog. og det er mit indtryk af resten af den cooporate verden skuler til .NET, simpelthen fordi at de, udover moderne sprog, også lægger vægt på standard. Det kan godt være Ola Bini og et firma som ThoughtWorks skubber på for polygloth programmering, men det er alt andet lige, nemmere for en virksomhed at hyre C# udviklere til ens .NET infrastruktur, end at skulle finde talenter der mestrer både Groovy, Clojure, Scala, JRuby etc.

¹ Nu hvor Brian refererer til "Java SE 8" istedet for "JDK8", betyder det at Java nu igen er en spec man (f.eks. Apache) frit kan implementere?

² Kunne vi ikke nok få decimal literal support i sproget, frem for at skulle bruge det cerimonikrævende BigDecimal objekt?

Torben Mogensen Blogger

Antoine de Saint-Exupery (Nok bedst kendt for "Den lille prins") sagde en gang: "Perfektion er ikke opnået, når der ikke er mere at tilføje, men når der ikke er mere at tage bort".

Mange af de "store" sprog har en tendens til at fylde flere og flere features på sproget, men selv om hver enkel ekstra ting lokalt set kan ses som en forbedring (der er visse ting, der kan gøres lettere), gør det ikke nødvendigvis sproget til et bedre sprog. Jeg savner lidt, at man i de store sprog også fjerner features, som kan siges at være mindre vigtige (for eksempel fordi nye features gør dem overflødige). Men i bagudkompatibilitetens hellige navn sker det meget sjældent.

Konsekvensen er, at de store sprog efterhånden udvikler sig til kolosser på lerfødder, og som reaktion derpå udvikles nye, simplere sprog. Nye sprog kan så også risikere med tiden at ende som kolosser, men hvis der er en stram styring af et sprogs standard, kan dette udskydes eller undgås. En så stram styring kan sjældent ske i en komite med mange eller skiftende medlemmer, så det ideelle er et lille tribunal, der følger sproget fra vugge til grav.

Jeg er (som de fleste nok ved) stor tilhænger af funktionelle sprog, så det glæder mig, at den funktionelle tankegang er ved at blive mainstream. Men jeg ser hellere udviklingen ske ved, at man skifter til nye sprog i stedet for at tilføje lambda-udtryk og lignende til eksisterende. En væsentlig fordel ved funktionelle sprog er begrænsning af ikke-lokale effekter såsom læsning fra og skrivning til en global, delt tilstand. Det har særlig stor betydning, når man vil skrive massivt parallel kode, da delt tilstand kommer i vejen for parallelisme. Og man opnår ikke denne fordel ved blot at tilføje features til eksisterende sprog.

Men tillykke alligevel til Java med de anonyme funktioner. Nu skal vi blot fjerne den vanskeligt analyserbare (for både mennesker og computere) brug af delt tilstand.

Martin Bøgelund

Men tillykke alligevel til Java med de anonyme funktioner. Nu skal vi blot fjerne den vanskeligt analyserbare (for både mennesker og computere) brug af delt tilstand.

Er det ikke en lige lovlig akademisk idé med det funktionelle paradigme?

Da jeg lærte om paradigmet i datalogi, var det ikke engang ét paradigme blandt flere; det var den eneste måde at skrive rigtig kode på.

Men I mit professionelle liv har grænsen mellem funktionel og delt tilstand virket temmelig udflydende. Mest fordi mine funktionsparametre ofte indeholder en tabel med data, eller lange lister indeholdende forskellige datatyper, som igen kan refere videre til andre objekter.

Man kan naturligvis betragte henvisningen til tabellen (eller listen) som en funktionsparameter der er af en temmelig kompleks datatype, men jeg er tilbøjelig til at påstå, at en parameter der er et tabelnavn der dækker over 100 millioner dataceller minder mere om tilstand end om funktionsparametre.

Helt spicy bliver det, hvis jeg leverer en liste over forskellige inputs som funktionsparameter - for så kan jeg slæbe en "tilstandsliste" rundt i mit program, fyldt med tabel-navne lister og andre datatyper, vappe den ind som parameter til mine funktioner, og stadig pudse min funktionelle glorie.

Eller hvad?

Palle Simonsen

Eller hvad?

Jeg og andre havde fornøjelsen af at progammerer professionelt i Interlisp og Commonlisp i midt 80'er til start 90'erne. LISP udmærker sig i sin grundform ved at opfylde Antoine de Saint-Exupery's definition ved at være et endog meget lille sprog.

Jeg vil give dig ret Martin i at i virkelighedens verden er det svært at holde den funktionelle fane 100 % højt, da gængse realiseringer af delt tilstand bl.a. ofte har den umådeligt store fordel, at data kan genskabes på meget lidt tid, når program og/eller infrastruktur har ABEND'et. Men ellers kan man jo 'bare lige' køre programmet igen fra begyndelsestilstanden (hvis man har den) :)

Når det er sagt er det også min erfaring, at de der har anvendt funktionel programmering oftest tager nogle gode vaner med sig til andre sprog, der simpelthen udmønter sig i på mange paremtre mere effektiv programmering. Så investeringen på uddannelsen eller senere i at lære sig funkionel programmering er efter min mening givet rigtig godt ud.

Jens Kristian Geyti

Well - som XKCD siger: "Functional programming combines the flexibility and power of abstract mathematics with the intuitive clarity of abstract mathematics.". Jeg er personligt stor fan af lambda-udtryk, og muligheden for at "mixe og matche", for der er, som du illustrerer, masser af datastrukturer der er mere logiske at repræsentere på "gammeldags" vis.

Jesper Louis Andersen

Er det ikke en lige lovlig akademisk idé med det funktionelle paradigme?

Nej, ikke mere. I gamle dage var der en række forhold som gjorde det til en fordel at have imperativ kode. Dels var oversætterne til de funktionelle sprog dårlige og langsomme. Dels var maskinarkitekturen sådan at du ikke havde nogen fordel af at programmere andet end imperativt. Men effektiv oversættelse blev løst i 90'erne og med mange cores i de moderne maskiner, så er den enkelte performance på en core mindre vigtigt end hvor nemt det er at udnytte samtlige cores. Der har funktionelle metoder en klar fordel. Der findes andre paradigmer som har endnu mere fordel end det funktionelle, men det er måske også et for stort spring at tage lige nu.

Bemærk også at bare fordi du arbejder med det funktionelle paradigme, så udelukker du ikke nødvendigvis imperativ kode. Akkurat som du kan kode funktionelt i imperative sprog, så kan du kode imperativt i funktionelle sprog. Og du kan pakke imperativ kode ind så den ikke lækker ud over hele dit program og skader dem.

Esben Nielsen

og med mange cores i de moderne maskiner, så er den enkelte performance på en core mindre vigtigt end hvor nemt det er at udnytte samtlige cores.

Da jeg var i Bilka i går, havde de fleste maskiner 2 cores. Nogle 4. Dvs., at hvis du henter en performance på en faktor 2-4 på én core slår du en multi-core løsning. Og så kan du bruge de cores til noget andet...

Casper Bang

Bemærk også at bare fordi du arbejder med det funktionelle paradigme, så udelukker du ikke nødvendigvis imperativ kode.

Klart. Faktum er jo, at 100% funktionel kode ikke har mulighed for side-effekter, og skrivning til disk, skærm mv. er jo i høj grad en side-effekt.

Da jeg var i Bilka i går, havde de fleste maskiner 2 cores. Nogle 4. Dvs., at hvis du henter en performance på en faktor 2-4 på én core slår du en multi-core løsning. Og så kan du bruge de cores til noget andet...

Helt så firkantet er det jo bare ikke helt. CPU'er opererer i dag op imod TDP, hvor nogle kerner overclockes i perioder når/hvis andre ikke laver noget/nok. Jeg tror der vil gå en del tid, før det er normalt at kunne skalere enhvert problem, ud over mange kerner, nogenlunde effektivt. Men det er klart det vil komme, når det er mainstream at skulle holde 16-32 kerner i gang, selv om det ikke skalerer lineært.

Henrik Baastrup

Det er ikke cool at arbejde med Java, det er meget klart når man tager en tur, hvor de programøre er, som har en mening. Men hvis man kikker på Github er Java nummer 3 sprog (http://adambard.com/blog/top-github-languages-for-2013-so-far/) og hos Tiobe er det nummer 2 (http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html), hvorfor så det? Det har nok noget at gøre med, at der ting man kun kan gøre med main-stream sprog som Java og C/C++.

Lige fortiden arbejder jeg på et projekt, hvor jeg skal have 100.000 CDR ind I en database hvert sekund, med en forsinkelses på højs 1 minut (hver CDR er ca. 800 bytes). Jeg vil meget gerne komme op på 500.000 CDR/s og drømmer om 1.000.000. Jeg har ikke mange alternativer, det er Java eller C.

Da jeg købte mig et SheevaPlug for nogle år siden, ville jeg lave mig en web app. i Ruby on Rails for den, det var utrolig sexy at skrive appen, men den blev så langsom, at jeg blev nød til at gen skrive den i Java.

Min erfaring er at de "nye" sprog er, at de er utrolig hurtig at bruge, men har det lidt svært ved at skalere. Personlig bruger jeg dem for skripts, trods alt det er noget letter at skrive i Python, Ruby etc. end i Shell, og for at prøve nye features, men hvis det bliver for stort eller skal i produktion, bliver koden gen skrevet i C eller Jave, helst Java!

Jeg ser det som noget positivt at Java udvikler sig væk fra alt den boiler kode, så det bliver letter at bruge og læse, og jeg så også gerne at depricate atributen blev brugt lidt mere i de nye versioner.

Forresten - jeg synes også checked exception I Java er cool, så mit problem er nok at jeg er lidt gammeldags ;o)

Pelle Söderling

Men hvis man kikker på Github er Java nummer 3 sprog (http://adambard.com/blog/top-github-languages-for-2013-so-far/) og hos Tiobe er det nummer 2 (http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html), hvorfor så det?

Jeg tror snarere det skyldes at Java er det sprog stortset alle uddannelser fokuserer på som hovedsprog. Dvs. du har en meget stor gruppe af studerende som interesserer sig for sproget og som har massere tid til open source projekter og lign. :-)

Når det er sagt, så anvendes Java dog også stadig i stor stil i enterprise-verdenen, men det er nok ikke det som bringer det op på 2/3 pladsen.

Palle Simonsen

@Henrik: Enig med at Java ikke har haft godt af alt det boilerplate.

Jeg kan tydelig huske et ellers tolerant programmeringsteams reaktion på en af de første inkarnationer af J2EE. Det lader sig desværre ikke gengive i et pænt medie som v2:)

Nysgerrig: Hvorfor er programeringssproget en afgørende faktor i at gemme CDR'er i databasen? Er der noget billing/rating processering eller skal de 'bare' skovles fra et teleudbyder i/f og ned i databasen ?

Henrik Baastrup

"Jeg tror snarere det skyldes at Java er det sprog stortset alle uddannelser fokuserer på som hovedsprog"

Ikke enig!
Java is populær fordi det er et godt robust sprog, der funger på helt små enheder op til severs. Du kan bruge det for Android eller for en web app. Du kan bruge det til at føde database og XML, eller høj ydelse realtime apps, etc. etc. etc.

Henrik Baastrup

Nysgerrig: Hvorfor er programeringssproget en afgørende faktor i at gemme CDR'er i databasen? Er der noget billing/rating processering eller skal de 'bare' skovles fra et teleudbyder i/f og ned i databasen ?


CDRerne bliver skabt på vores prober hos teleudbyderne, en CDR kan indholde information fra foskelige protokoler (SIP, ISUP, DNS etc.) og skal korrelerers, så CDR er ikke det helt rigtige ord. Inde for brancen bruger vi ofte xDR. I sidste ende ved du helt præsis hvordan et opkald gik, hvile switches, media-gateways etc. var brugt, ja du kan næsten lokalisere brugeren. Det er en tung process hvor rigtig mange data er involveret or det skal ske i næsten realtime.
Når jeg bruger ordet database mener jeg ikke en normal RDMS men mere noget der kommer fra noSQL siden.
Programmeringssproget der bliver brugt er ikke vigtigt, men det skal være hurtigt og tillade mig at udnytte CPUen or dens core 100%, have en god kontol over cachen, etc. Mange ville nok vælge C for dette, men du kan faktisk gøre det i Java.

Uffe Seerup

Reactive Extensions blev primært udviklet af Erik Meier (som desværre ikke er hos Microsoft længere). Der er på codeplex implementationer af Reactive Extensions til JavaScript, Python og Ruby.

https://rx.codeplex.com/

Der er mange interessante anvendelser for paradigmet. Fx kan man lave en pipeline som genkender muse- eller fingergestikker blot ved at sætte flere kriterier efter hinanden.

Eller lave en pipeline som throttle'r hændelser så der ikke sendes events før der har været en pause på 0.5 sekund - noget man fx kan bruge til type-ahead søgning mm.

http://rxwiki.wikidot.com/101samples#toc30

Det kan også benyttes til asynkron programmering - men her er anvendelsesområdet efter async/await i C# (og VB) ikke helt så oplagt mere. Async/await er "future" programmering uden al besværet med at sætte callbacks op (det gør compileren for dig) og uden at din kode ender med at vende vrangen ud. :-)

http://msdn.microsoft.com/en-us/library/vstudio/hh191443.aspx

Peter Makholm Blogger

Det er ikke cool at arbejde med Java, det er meget klart når man tager en tur, hvor de programøre er, som har en mening.

Github er en relevant metrik, men jeg giver ikke fem flade øre for TIOBE.

Jeg mener dog ikke at jeg noget sted har givet udtryk for at Java er døende og beklager hvis nogen har opfattet mit oplæg således. Nærmere tværtimod, hvis Java var døende var det fuldstændig ligegyldigt hvilke trends Java-folk kastede sig over som en sidste krampetrækning.

Men jeg ser netop ikke Java som døende og derfor er trends inden for Java-udvikling en god indikation af hvilke trends der er mainstream.

Der er helt klart nogle fordele ved at udviklingen af et sprog er ret konservativt drevet, selvom avantgarden lidt tænker mehhhh engang imellem.

Henrik Baastrup

Hvis du kan lave det i Java så kan du også lave det i Scala. Kode der er skrevet ens i de to sprog performer stort set identisk.

Ja Scala er interessant da det tillader mig a bruger Java within. Men hvor cool er det at have Java statements i din Scala code? Hvis du spørge en programmør "der har en mening".
Det er jo en interessant udvikling med de mange "nye" sprog der køre på toppen a JVM.

Peter Makholm Blogger

Henrik, hvad er dit problem med at have en mening?

I min optik er det vigtigt at reflekterer over sit fagområde. Det er blandt andet derfor jeg er aktiv her på Version2, deltager på konferencer som GOTO og YAPC::EU og holder oplæg som til Peter Tofts Debugging-konference.

Men når jeg læser dine indlæg føler jeg lidt at du mener at denne reflektion over hvad jeg går og laver gør mig til en dårligere programmør. Kunne du måske uddybe dine "folk der har en mening" kommentare?

Hvad er din motivation for overhovedet at deltage her, hvis det ikek netop er for at have en mening (og forhåbentlig udvikle din mening)?

Baldur Norddahl

Ja Scala er interessant da det tillader mig a bruger Java within. Men hvor cool er det at have Java statements i din Scala code?

Du behøver ikke at bruge Java for at få Scala til at performe ligeså godt som Java. Du skal bare skrive algoritmen på samme måde som du ville have gjort i Java (det vil sige imperativt), så får du næsten den samme bytecode ud af det.

Bare pas på med ikke at lave premature optimisation. Kode i den funktionelle stil er ofte lidt langsommere end imperativ kode. Og i 99% af dit program er det ikke noget problem. Nøjes med at finde den 1% hvor det giver mening at optimere.

Nikolaj Brinch Jørgensen

Det giver ikke meget mening at tale om et sprogs stabilitet


Jo det giver i den grad mening. Hvis sproget hele tiden bliver lavet om, så ting forsvinder ud eller lavet om, som bryder kompatibiliteten (Python 2.X -> 3.X f.eks.), så er det svært at lave store investeringer i det. Derfor har Java en stor Enterprise tilslutning. Sproget er stabilt, og man kan opgradere til en nyere release uden de store omkostninger.

Henrik Baastrup

I min optik er det vigtigt at reflekterer over sit fagområde. Det er blandt andet derfor jeg er aktiv her på Version2, deltager på konferencer som GOTO og YAPC::EU og holder oplæg som til Peter Tofts Debugging-konference.

Men når jeg læser dine indlæg føler jeg lidt at du mener at denne reflektion over hvad jeg går og laver gør mig til en dårligere programmør. Kunne du måske uddybe dine "folk der har en mening" kommentare?

Jeg er meget enig med dig, vi skriver her fordi vi har en mening, og gerne vil udtrykke den. Jeg mener at folk som dig, der tager på konferencer og bagefter deller hvad de har oplevet, er vigtigt og stimulere folk til at havde en mening, du fik jo mig i blæk huset - ik?
Om du er en dårligere programmør kan jeg ikke på nogen måde vurdere, men jeg har lidt den samme følelse, når jeg læser dine artikle fordi jeg skriver i Java, så det har nok noget at gør med at vi ikke er enige.

Min emne valg "Er java et døden sprog?" er nok ikke det bedste, og når jeg skrive "folk der har en mening" kunne jeg nok have skrevet noget, så som "folk som ofte udtrykker sig stærk om programmeringssprog" eller lignende. I alle fald har mit indlæg fået folk til at udtrykker meninger omkring din artikle og mit indlæg.

Jeg udtrykker ikke så ofte min mening om programmeringssprog, fordi det tid ender med nogle lange lidt ubrugelige diskutioner. Jeg synes det er meget mere interessant at høre om hvilken cool ting folk laver med deres sprog, Jave, C, Scale etc. Så egentlig ville jeg heller bruge min energi på diskussioner, som den lille jeg havde med Palle Simonsen.
Personligt synes jeg du ikke skulle have brugt omkring 50% af din spalte plads, på et fordrag du syntes var kedeligt (Java Past, Present, and Future), men bruge den på noget der var intrasant (Functional Reactive Programming with RxJava). Men så havde vi jo nok ikke haft hele denne debat

Peter Makholm Blogger

Min emne valg "Er java et døden sprog?" er nok ikke det bedste,

Nu bruger jeg selv det meste af min arbejdstidtid med et sprog som folk har udråbt som døende i de sidste 10 år (om ikke længere). Men selvom alle overskrifterne enten handler om at sproget ikke er døende eller er retoriske spørgsmål i stil med dit, så efterlader det en stærk stank af død over hele debatten. Hvis man er velmenende gør man efter min mening sprog-communityet en bjørnetjeneste ved på nogen måde at gå ind på præmissen om at sprogen kan opfattes som døende.

Personligt synes jeg du ikke skulle have brugt omkring 50% af din spalte plads, på et fordrag du syntes var kedeligt (Java Past, Present, and Future),

Personligt måler jeg det op til at 11% af spaltepladsen omhandler Brian Goetz' keynote. Jeg skriver intet sted at foredraget var kedeligt, men jeg skriver at jeg kun gik til det fordi det var en keynote. Derefter fremdrager jeg den vigtigste pointe fra Brians foredrag: Funktionel programmering er ikke bare en nicheting i Java, Oracle går direkte efter at understøtte det i selve sproget.

Uden den pointe snakker jeg måske bare om en lille niche i communityet bestående at en ivrig Netflix-udvikler.

Peter Makholm Blogger

Sun og Oracle kunne have slået en streg i sandet, trykket på "reboot" engang så vi kunne få et moderne sprog at arbejde med. Toget er nu desværre kørt; guro'er og greenfield operatives (de fleste ThoughtWorks folk bl.a. ) er for længst hoppet over til alternative JVM sprog.


Jeg tror ikke på en reboot af et programmeringssprog i form af at man i løbet af Java9 og Java10 fjernede 15% af featurene. Specielt ikke i et sprog der på den måde er rettet mod at have et stabilt sprog.

Istedet burde man netop kaste sine krafter bag et af de alternative JVM-baserede sprog og melde ud at der slet ikke ville komme en Java9. På længere sigt kunen man så begynde at de-optimere JVMen til Java og optimere efter de nyere behov.

På den måde kan de konservative Java-brugere sove sødt om natte og mske over i årrække begynde at skrive ting i det nye sprog.

Log ind eller Opret konto for at kommentere