HTML

asdf

Scala @Devoxx 2012

2012.12.07. 13:39 tvk

Ma már egy Java konferencia nem múlhat el Scala előadások nélkül, így volt ez az idei Devoxx-on is. Az első university nap egy teltházas First Steps with Scala-val kezdődött Dick Wall és Bill Venners tolmácsolásában. Ezt kihagytam, mint ahogy az esti bratyizós és rejtvényfejtős session-öket is. A Scala-s rejtvények nagyon gonoszak tudnak lenni, nem egy fárasztó nap végére valók. De lehet hogy igazából nem is rejtvényfejtés volt, hanem a scalakoans-on nézegették a gyakorlati Scala feladatocskákat.

Kedden viszont már bementem az Advanced Concepts and Best Practices-re, ami nem pont arról szólt, mint ami meg lett hirdetve. A hamarosan jövő 2.10-es verzió újdonságait mutatták be és néhány jótanácsot adtak. A poszt végére biggyesztettem egy konklúziót, úgyhogy akinek a Scala vagy a funkcionális programozás viszonylag új vagy magas, az rögtön oda tekerhet. Itt olyan dolgok következnek, amiket magamnak firkáltam le:

  • Az implicit konverziók durván meg tudják növelni a fordítási időt és jelentősen nehezítik a kód olvashatóságát mások számára. 2.10-ben explicite importálni kell majd bizonyos language feature-eket, mint pl. ezt is. Találtam egy jó kis doksit ezzel kapcsolatban. Az implicitek szkópját minimalizálni kell, pl. egyáltalán nem szabadna őket importálni. (?)
  • Lesz 2.10-ben applyDynamic, azaz ha olyan metódust akarunk hívni ami nincs meg egy objektumon, akkor ez a metódus hívódik meg. A Scala továbbra is marad szigorúan típusos, ez viszont egyfajta nyitás a dinamikus nyelvek felé. (Ruby-ban van ilyen, például.)
  • Lesz implicit class, automatikus wrapper osztályokat lehet más osztályok köré tenni. Szép, de általános típusokra nagyon nem kellene ezt alkalmazni, és nem szabad túlzásba vinni.
  • Currying már eddig is volt, azaz egy függvénynek több paraméterlistája lehet egymás után. Ami viszonylag új, hogy az utolsó paraméterlista lehet implicit. Nem is tudtam, hogy Haskell-ben minden függvény currying-et használ, aminek egynél több paramétere van. Újabb érdekes adat.
  • Lehet majd olyan annotációkat csinálni, amik fordítási idejű hibát kényszeríthetnek ki, ha egyébként lefordulna a program, de valamilyen feltétel nem teljesül. A scala compiler egyébként 19 lépésben csinál a forráskódból bájtkódot. Szép nagy szám.
  • Nagyon hangsúlyozták a null-mentes szerkezetek (monádok) és az Option osztály használatát. "A null is an error waiting to happen."
  • Változókat (var) nem szabadna használni, de szűk szkópban, pl. kisebb függvényekben lokális változónak megengedett lehet bizonyos esetekben. Optimálisabb kódot lehet vele esetleg elérni. Néha jobb imperatív szerkezeteket használni függvényeken belül, nem muszáj foggal körömmel ragaszkodni a funkcionális paradigmához. "Use 'def' for abstract members. (Not 'val'.)"
  • Inkább immutable collection-öket kellene használni ahol lehet. Ha mutable, akkor wrappelni kellene. (Ez java-ra is igaz mellesleg.) A Vector osztályt ajánlották, mint nagyon kényelmes szerkezetet. Java-s collection-ök átalakításához a JavaConverters-t érdemes használni.
  • A for kifejezés a barátunk. A for yield is. Amilyen collection típus bemegy, az jön ki a yield-del.
  • A visszatérési értékek típusait nem mindig muszáj kirni Scala-ban, de érdemes, mert sok szívástól megment. Nemcsak olvashatóbb lesz a kód, de a compiler értelmesebb hibaüzenetet tud adni ha valami hiba van. Ha nincs kiírva a visszatérési típus, lehet hogy még le is fordul a program, de nem arra, amit gondoltunk. Visszatérési érték inkább ne legyen Tuple, legyen inkább case class.
  • A case class-okban az öröklődés használata bonyodalmakhoz vezetett (equals, hashCode), úgyhogy ilyenekből nem lehet majd örökölni. Tehát csak az öröklési fa levelei lehetnek majd case class-ok.
  • Inkább csináljunk trait-eket, mint class-okat amikor lehet.
  • A tömegből bekiabálták a scalex.org honlapot, ahol gyorsan meg lehet találni Scala függvényeket.
  • A név szerinti paraméterátadás annyira nem jó ötlet (pedig szerettem), mert azt hiszem nagyon lassítja a fordítást. Default paraméterek vs ad-hoc overloading közül pedig mindkettő jó, de nem szabad keverni ugyanarra a metódusra.
  • Említésre került a Scala build tool, az sbt, ami bonyolult viszont viszonylag gyors, de ez van és ezt kell szeretni. Még az első nap voltam a Play web framewörk prezentációján, ami nekem úgy tűnt hogy túlságosan is épít az SBT-re. Emiatt annyira nem jött be.

Bill Venners egyébként a Programming in Scala című könyv egyik szerzője. Dick Wall pedig Javaposse tag és az Escalate software egyik alapító tagja. Ők USA szerte csinálnak Scala tréningeket.

Mégegy prezentációra sor került egy másik napon Effective Scala címmel Joshua Suereth-től, a Scala in Depth című könyv szerzőjétől. Nagyjából ugyanazok hangzottak el, mint az előző alóadáson, csak néhány szakkifejezést sorolnék fel, amiket valamikor talán majd kifejtek: option wall, container traits, cake pattern, companion objects, implicit view: antipatternm, type trait, Future object, monadic workflow. Ezek kb. mind megérdemelnének egy külön blogbejegyzést. A kérdezős szekcióban olyan kérdések hangzottak el, amit még az előadó sem nagyon tudott néha követni - valami logikai fejtegetések a különböző nyelvi szabályok interferenciájáról.

Update 2012.12.15: Bill Venners tartott még egy előadást "Simplicity In Scala Design" címmel. Valójában a unit tesztelős Scala framewörkjéről beszélt, a ScalaTest-ről. Volt néhány megfontolandó javaslata: A könyvtárakat úgy tervezzük meg, hogy akik használni fogják lehet hogy határidőik lesznek és golyók fognak süvíteni a fejük mellett. Könnyen hibáznak majd, nem akarják folyton a doksit bújni, nem akarnak expertek lenni a könyvtárunkkal kapcsolatban, csak a munkájukat akarják majd rendesen elvégezni. Legyen nehéz hibát véteni, legyen egyértelmi hogyan kell megoldani valamit, legyenek könnyen kitalálhatóak a dolgok, legyenek ismerősek máshonnan.

Konklúzió: Ahogy látjuk a Java 8 terveit, egyre gyakrabban előkerül a poén, hogy a 10-es Java a Scala lesz. Olyan nyelvi feature-ök, amiket épphogy tervezgetnek a Java-ban, a Scala-ban a kezdetektől fogva benne vannak. Meló közben is előjön néha, hogy milyen egyszerű elegáns lenne valamit Scala-ban megoldani. Másrészről pedig a Scala egyáltalán nem egyszerű nyelv, sőt elég bonyolult. Martin Odersky is azt vallotta, hogy a Scala olyan fejlesztőknek való, akik tényleg jók. Viszont azt tapasztalom, hogy az átlagos programozóknak még a Java is túl bonyolult időnként. Talán vadul hangzik, de van egy olyan érzésem, hogy a nyelv (de nemcsak a Scala) többfelé fog osztódni. A base library-k fejlesztői használni fogják a bonyolultabb nyelvi feature-öket, de a magasabb szintű modulok programozói már csak a nyelv egy egyszerűbb részhalmazát fogják használni. Statikus kódanalízissel ezt könnyű lesz ellenőrizni. Olyasmi ez, mint amikor J2EE-ben az egységsugarú programozó nem kellene hogy saját ClassLoader-t írjon, vagy Reflection-t használjon, vagy explicit szálkezeléssel törődjön. A 2.10-es Scala-ban már láthatóak törekvések ebben az irányban. Az is megoldás lesz majd, hogy az alkalmazások egyes moduljai Scala-ban fognak íródni, másik részük Java-ban. Ebben az esetben fokozott jelentősége lesz a Java-Scala együttműködés ismeretének. Nagyjából ez az a dolog amivel én is tervezek kicsit foglalkozni, amint lesz időm. Remélem lesz, de addig is megírok még egy-két posztot a Devoxx-ról. Stay tuned.

2 komment

Címkék: konf scala

A bejegyzés trackback címe:

https://kodzaj.blog.hu/api/trackback/id/tr384951136

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

kjozsa 2012.12.09. 19:33:02

nem tudom ér-e kötözködni h a monad nem null-mentes szerkezet :) de a szemem megakadt rajta azért. SBT jövőjéről nem volt szó? Vagy fél éve volt valami rebesgetés egy Typesafe fejlesztésű új irányról..

köszönjük a beszámolót!

tvk · http://kodzaj.blog.hu 2012.12.15. 09:54:11

Helló! Az SBT jövőjéről nem volt szó, bár a Typesafe ott volt a konferencián. A monad-dal kapcsolatban nekem ez jött át, de bevallom hogy nem értem teljesen mi az. Ha tudsz valami jó leírást róla jöhet!