Geen enkele programmeertaal is het ‘nec plus ultra’ en ook Java blijft voor verbetering vatbaar. Of zelfs vervanging. Want de zoektocht naar makkelijker en meer efficiënte methodes van softwareontwikkeling gaat gestaag door.
De wereld van programmeertalen is geen starre, dooie bedoening. Integendeel, ook vandaag is het onderzoek naar nieuwe concepten en aanpakken erg levendig. Dat onderzoek kan het werk zijn van bevlogen individuën, maar ook van voortgezet onderzoek aan universiteiten. Zo leidt professor Eric Steegmans aan de KU Leuven in het departement computerwetenschappen een onderzoeksgroep (SOM – Software Development Methodology) met als doel “nieuwe concepten te ontwikkelen om programmeertalen te verbeteren.” In de voorbije jaren hebben doctoraatsstudenten onder zijn leiding hun resultaten op prominente congressen kunnen voorstellen. Dat gebeurde bijvoorbeeld op het bekende OOPSLA (Object-Oriented Programming, Systems, Languages and Applications – sinds 1986 de vooraanstaande OO-conferentie).
Inspirerend
Het blijft dan wel de vraag of die nieuwe concepten ook hun plaats vinden in bestaande talen? “Niet meteen,” merkt Eric Steegmans op. “Het gaat om concepten voor bestaande talen, maar er is natuurlijk ook de invloed en impact op nieuwe programmeertalen.” Zo kan iets allicht niet in Java opduiken, maar wel in bijvoorbeeld ‘nieuwkomers’ als Ruby of Scala. Die talen worden eerste gebruikt door personen in de onderzoekswereld, om vervolgens in de industrie hun opwachting te maken. Kortom, “het zal dus niet meteen Java of C# zijn die de nieuwe concepten zullen omarmen, omdat zij stevig vastzitten in een aantal basisconcepten voor terugwaartse compatibiliteit.”
Ook de weg van een JSR – een Java Specification Request, zoals aanvragen voor nieuwe elementen in Java worden geformuleerd – ligt niet voor de hand voor nieuwe concepten. Zelfs een concept als ‘clo-sures’ – ooit het onderwerp van een JSR die mee werd ingediend door de Belgische Java user Group BeJUG – veroorzaakte teveel tweespalt, om aanvaard te worden in Java. En dan is ‘closures’ een concept dat al dateert uit de jaren zeventig en tachtig, uit talen als Lisp en SmallTalk, merkt Steegmans droogjes op. “Als het al moeilijk is voor gevestigde concepten, wat moet het dan niet zijn voor nieuwe? Closures zitten wel van bij de aanvang in Scala en daar vormt dat dus geen probleem.” Dat zal trouwens een deel van de boodschap zijn in Steegmans’ presentatie over ‘generics’ op de komende editie van Devoxx. “Ook de implementatie van generics in Java heeft zo zijn problemen omwille van de terugwaartse compatibiliteit en de vraagtekens die door een aantal beslissingen worden opgeroepen. Programmeurs hebben er dan ook problemen mee, omdat generics er niet van bij de aanvang in zat.”
Dan met z’n allen maar overstappen op een taal als Scala? “Scala is één van de talen waar naar wordt gekeken, maar ik ben niet echt onder de indruk,” verklaart Eric Steegmans, die er wat meer zou willen mee experimenteren.
Java ‘end of life’?
Als Java het moeilijker krijgt om zich aan te passen aan de specifieken noden en verwachtingen in dynamische en gedistribueerde omgevingen, is de taal dan ‘end of life’? Java heeft toch al meer dan 15 kaarsjes uitgeblazen….
“De hype rond Java is [inderdaad] voorbij,” antwoordt Steegmans gevat. “De focus richt zich dan ook meer op de ‘virtuele machines’ van Java en C#, en de programmeertalen rond die virtuele machines. Zo draait Scala op het VM van Java. Over vijf jaar kan dat meer marktaandeel hebben ten opzichte van Java en C#. De VM’s zijn goed en dan vormt het geen groot probleem om van de ene taal naar de andere over te stappen.”
Kortom, bedrijven moeten meer aandacht besteden aan de VM’s, want die vormen de ware ruggengraat? “Ja! En dat gaat ook meer en meer gebeuren. VM’s zullen steeds dominanter worden, met projecten die naast Java ook andere talen aanwenden, terwijl de uitvoeringssnelheid nog zal stijgen.” Een stelling die overigens ook keurig in de evolutie naar meer virtualiseing van omgevingen en een groeiende aandacht voor het cloudgebeuren past, respectievelijk een beter benutten van hardwareontwikkelingen als ‘multicore’-processoren.
Efficiënter ontwikkelen
Ook Eric Steegmans en zijn medewerkers buigen zich over het vraagstuk om de productiviteit van de ontwikkelaars op te krikken, met onder meer onderzoek naar methoden voor meer modelgerichte aanpakken. Waarbij hij overigens wel een nuchtere kijk op de zaak houdt. Er dienen zich altijd ideeën aan die na een eerste fase van enthousiasme toch weer bekoelen. Zo was er ‘aspect programming’, een aanpak die een grotere modulariteit van oplos-singen nastreefde door programma’s op te breken in ‘concerns’ (samenhangende gebieden van functionaliteit). Er waren prototypetalen als AspectJ, maar toch is “ook die hype al weer wat voorbij,” oordeelt Steegmans. “Er zullen altijd nieuwe ideeën zijn en als die doorbreken kan dat een enorme vooruitgang zijn, maar achter de schermen wordt het dan toch weer duidelijk dat het niet werkt. Zoiets schudt wel iedereen wakker en het helpt om vooruit te gaan, in kleine stappen.” Immers, een meethode of programmeertaal die “de productiviteit met meer dan 50 procent laat stijgen, bestaat niet. Een taal als Java mag het dan mogelijk maken wat sneller te programmeren of een hogere productiviteit te hebben, tegelijk groeien ook de eisen die aan de projecten worden gesteld. Enkele percenten per jaar productiviteitsverhoging zou dan ook al veel zijn,” klinkt het nuchter.
Niet dat het ooit anders was, want zelfs met de overgang van bijvoorbeeld Assembler naar een hogere taal als Fortran werd ook niet zo’n gigantische vooruitgang geboekt. Doorheen de geschiedenis van de ict zijn er wel een aantal mijlpalen geweest, die diepgaande veranderingen brachten zoals “gestructureerd programmeren, modules, abstracte datatypes, objectorientatie, maar dat is vooral een evolutie.”
De vraag of het dan een eeuwige zoektocht naar een heilige graal blijft, onthaalt Steegmans op gelach en de opmerking dat dit het “leuk maakt!” Aan de KU Leuven wordt overigens ook nog door andere groepen gesleuteld aan aspecten van softwareontwikkeling, onder meer met het oog op meer security, inherent correcte logica, transacties in gedistribueerde systemen en dies meer. Aspecten waarvoor “ondersteuning in de taal nodig is,” aldus Steegmans. “Raamwerken en dies meer zijn moeilijke technologieën om zich eigen te maken en steken ook niet altijd goed in elkaar,” naast lock-in-risico’s en mogelijke legaatproblemen. Hij verwijst daarbij naar de grote verschillen tussen de eerste versie van EJB’s (Enterprise Java Beans) en de huidige versie, EJB3.
Post-Java
Java als taal is niet dood, maar Steegmans verwacht ook geen grote veranderingen meer. “Generics was de laatste grote toevoeging, met hier en daar nog wat bijschaven.” Het is veeleer de beurt aan nieuwe technologieën en talen en “dat zal niet meer lang duren,” meent Steegmans.
Maar welke taal het wordt, gedefinieerd door wie? “Dat is een zaak van een goed concept en een goede marketing. Je moet de mensen immers overtuigen om in die taal te schrijven! Java slaagde daarin omdat Sun hiervoor tools en ondersteuning bood. Dat is bijvoorbeeld misgelopen met Eiffel, hoewel dat academisch gezien een betere taal was. Maar daar is het misgelopen met de ‘marketing’.” Concreet betekent dit de noodzaak om snel een grote ‘community’, zeg maar een grote gebruikers- en ontwikkelaarsgroep, te vormen, en ondersteuning in omgevingen (als bijvoorbeeld Eclipse) te bieden. Voorts moet de taal ook platformonafhankelijk zijn, benadrukt Steegmans. Scala lijkt vandaag de favoriete koploper te zijn, ook al omdat de taal de twee werelden van iteratief/OO en fundamenteel programmeren verenigt. “Niet optimaal, maar toch,” oordeelt Steegmans. Een taal als Haskell is dan weer puur functioneel en zal allicht niet zo’n hoge vlucht nemen als Scala. Toch denkt Steegmans niet dat Scala het zal halen als de opvolger, want dan “had dat al gebeurd moeten zijn.” Het ziet er meer naar uit dat alle opgedane ervaring en de nieuwe inzichten worden gebundeld in een nieuwe taal!
Guy Kindermans
Scala lijkt vandaag de favoriete koploper te zijn, ook al omdat de taal de twee werelden van iteratief/OO en fundamenteel programmeren verenigt.
Fout opgemerkt of meer nieuws? Meld het hier