blog.smart-java.nl
Ordina J-Technologies – Java Blog



Scala: too hot to handle?

By: Hedzer Westra, 29 January 2009

Het blog item van 21 januari sloot ik af met: “Ikzelf hoop binnenkort te komen met een bespreking van ‘Programming in Scala,’ het eerste boek over deze nieuwe en spannende programmeertaal.”

Prompt reageerde Jan-Kees van Andel: “Ik verwacht niet dat Scala verder zal groeien qua populariteit. Op de JVM Language Summit 2008 was de algemene opinie dat Scala het niet gaat worden omdat het te moeilijk is. En dat ‘te moeilijk’ komt uit de mond van hele capabele mensen (lees: JVM taalontwerpers). Zij waren vooral gecharmeerd van Clojure.”

Aangezien ik me ten doel heb gesteld om Scala dit jaar onder de aandacht te brengen bij mijn J-Tech collega’s, kan ik dat natuurlijk niet over mijn kant laten gaan :-)

Als je het hebt over JVM taalontwerpers: de auteur van Scala, Martin Odersky, is bedenker van Java generics, en ontwikkelaar van de Java 1.2 reference compiler. Zelf maakt hij dus ook deel uit van deze groep, en hijzelf is nog allerminst klaar met Scala.

Onlangs is bekend geworden dat Java7 geen closures zal krijgen – men kon geen beslissing nemen. Eind augustus/begin september postte Jan-Kees nog hoopvol een artikel waarin de drie onderhanden voorstellen behandeld werden, maar helaas zal geen ervan het licht gaan zien in Java7. Dat op zich is al een goed argument om naar Scala te kijken: daar zitten closures rotsvast in de basis van de taal.

Natuurlijk heeft Clojure ook closures (vandaar de naam…), maar als je kijkt naar de syntax van Clojure, zie je meteen waar deze voornamelijk op gebaseerd is: LISP. En dat staat niet voor niets voor Lots of Irritating Silly Parentheses (eigenlijk LISt Processing, maar je snapt waar ik heen wil). LISP stamt uit de jaren ‘50/’60 van het vorige millennium en heeft begrijpelijkerwijs een inmiddels verouderde syntax. De Scala syntax daarentegen is grotendeels op Java gebaseerd, wat de overstap Java -> Scala mijns inziens eenvoudiger maakt.

Een ander punt is dat ik een beetje gelogen heb toen ik zei “deze nieuwe [..] programmeertaal”: Scala is al sinds 2001 in ontwikkeling, en niet door de minste wetenschappers, en is zodoende al vergaand uitontwikkeld. Clojure begon pas in 2005.

Scala’s propositie is dat het een schaalbare taal is (‘SCAlable LAnguage’). Niet alleen in de zin van performance bij gebruik op multi-core systemen, maar ook – en veel belangrijker – schaalbaar naar het type applicatie dat je er mee wilt bouwen. Dat varieert van script via desktop applicatie tot enterprise systeem. De syntax ondersteunt al deze applicaties op dezelfde manier. Dat gezegd hebbende, is Scala een rijke taal, die je – naar wens – kunt gebruiken als ‘Java on steroids’, dan wel als een bijna-pure functionele taal à la Haskell. Als je dat laatste wilt, en momenteel alleen Java beheerst, is dat inderdaad nogal een klus, en kan ik me voorstellen dat je de taal als ‘te moeilijk’ bestempelt. Maar als je kiest voor het eerste, en je je de taal langzamerhand eigen maakt, kunt je zogezegd ‘opschalen’ naar een meer functioneel gerichte programmeerstijl. Kan allemaal in Scala.

Wat betreft de functionele programmeerstijl (FP): die is echt fundamenteel anders dan de imperatieve OO programmeerstijl die voor bijvoorbeeld Java de voorkeur geniet. Dat moet je dus leren, en leren is altijd (in meer of mindere mate) moeilijk – maar om daar meteen de taal de schuld van te geven? Als je overstapt van C naar Java moet je ook een nieuwe, in het begin moeilijke, stijl aanleren, maar uiteindelijk is dat de moeite dubbel en dwars waard. Voor FP geldt dat evenzogoed. Als je echt ‘hardcore’ puur FP wilt proeven, zou je eens kunnen kijken naar Haskell of ML. Maar dat is niet voor niets, ondanks jaren taalontwikkeling, nog steeds het domein van wiskundig opgeleide academici – programmeren in die talen wordt snel heel erg abstract (hoor ik iemand ‘Monads!’ roepen?). Scala is veel meer ‘down to earth’ en bereikbaar voor de gewone stervelingen.

Mocht je nog niet overtuigd zijn dat Scala toch echt wel wat meer aandacht verdient, check dan de Wiki die ik ingericht heb (helaas alleen voor Ordinamedewerkers). Daarop vind je een powerpoint van een presentatie die ik onlangs gaf bij een architectuur intervisie meeting, een draft cookbook en een Eclipse workspace met veel kleine codevoorbeeldjes. Wel eerst even de Scala plugin installeren!

Een special meeting Scala zit in de koker. Ook kun je extra blog items van me verwachten over bijvoorbeeld Liftweb en Sweet, twee web frameworks in Scala. A propos: ik ben nog op zoek naar reviewers voor mijn kookboek! Wie meldt zich aan als proeflezer?

Hedzer Westra

Hedzer Westra

2 reacties op “Scala: too hot to handle?”

  1. Jan-Kees van Andel zegt:

    LOL, ik heb iemand op zijn pik getrapt volgens mij. ;-)

    Maar serieus, ik sluit me helemaal bij Brian aan qua moeilijkheid van Scala. Ik heb Scala een tijd terug serieus de kans gegeven. Heb onder andere de 10-delige (ofzo) reeks artikelen van Ted Neward op DeveloperWorks gelezen en met de features zitten spelen, maar ik kon niet zeggen dat ik er echt van gecharmeerd was.

    En waarom? Voorbeeldje: In die artikelen op developerworkd werd keihard ontkend dat Scala operator overloading heeft (want dat zit in C++ en is slecht, was de stelling). Scala heeft immers object overloading en alles in Scala is een object, ook operators. Dan is het spontaan een nuttige feature. Maar waar het om gaat, dat je vreemd gedrag kunt toekennen aan operators waarvan je verwacht dat ze zich “normaal” gedragen, wordt negeerd.

    Zie: http://www.ibm.com/developerworks/java/library/j-scala02198.html

    Ik zie het al voor me dat je de volgende code in een bestaande applicatie tegenkomt:
    var today = “hello ” + new Date(1,1,1) + 1.5;

    Tel daarbij de support voor interne DSL’s, closures, etc. op en je krijgt een mix van taalconstructies waar uiteindelijk je applicatie niet doorzichtiger wordt. Kijk maar wat generics (en dan vooral de problemen met wildcards) met de taal gedaan hebben.

    Het lijkt erop dat ze één van de belangrijkste kernwaarde van Java, namelijk (code lezen is belangrijker dan schrijven), met Scala compleet overboord gegooid hebben.

    Ik zie ook wel positieve punten in Scala, zoals de betere generics, traits en val/var, maar het zou fijn zijn als ze de functionaliteit wat terug zouden schroeven, want ik moet er niet aan denken dat ik een Scala applicatie in onderhoud moet nemen.

    Nee, tenzij ze van Scala een soort Java on steroids maken is het wat mij betreft een stap terug, namelijk C++ op de JVM.

    Maar misschien kun jij me beter dan Ted Neward overtuigen dat Scala the way to go is, dus ik wil me wel aanmelden om het cookbook te reviewen. :)

    Ps. Ik ben wel benieuwd wie er nog meer met Scala gespeeld (of gewerkt) hebben en wat de ervaringen waren.

  2. Hedzer Westra zegt:

    Ach nee, gepikeerd voel ik me zeker niet. Maar ik ben altijd bereid om beargumenteerd aan te geven waarom ik denk dat Scala niet zonder meer afgeserveerd zou moeten worden.

    Dat je in Scala niet-onderhoudbare code kunt schrijven, is zeker waar. Maar we weten allemaal dat dat in Java ook geen enkel probleem is… Ik geef toe, omdat Scala meer mogelijk maakt dan Java, kun je ook een grotere rotzooi creëeren, maar je taal zo ver inperken zodat je maar geen (stijl)fouten kunt maken is mijns inziens teveel van het goede.

    Ik heb puristen horen zeggen dat ze boxing, foreach en generics in Java maar onnodige toeters en bellen vinden, maar ik val niet voor hun argumenten. Alles wat je taal typesafer, compacter én tegelijk leesbaarder maakt steun ik van harte. (Eén subtiliteit realiseerde ik me onlangs pas: waarom is het zo dat een foreach een NullPointerExc geeft als je over een null object wilt itereren? Logisch gezien zou itereren over een lege, of een niet-bestaande lijst hetzelfde op moeten betekenen, nl. de body niet uitvoeren. Maar goed, dat terzijde.)

    Jan-Kees: als de tijd rijp is stuur ik je een review-verzoek. Alvast hartelijk dank voor de opbouwende kritiek, waarvan ik zeker weet dat je daar veel van zal hebben ;-)

Laat een reactie achter