Tag Archives: Scala

Why should I care about Scala and Akka?

Posted on by

Java is great and I have been doing it for years. Why should I care about things like Scala and Akka?

The short answer could be:

  • Scala is the future
  • Akka is the killer framework

Scala is a language that runs on top of the JVM with a better object orientation compared to Java and with functional programming as well. The OO part of the language is pretty easy to learn for a Java developer, but the functional stuff is trickier. Scala has a dedicated community and the language is predicted to become a really strong alternative to Java if Oracle continues to alienate the Java community. Since Scala interacts seamlessly with Java and Java almost seamlessly with Scala both languages can be mixed in the same application.

Akka is a library in Scala aimed at robust and scalable parallel programming. Instead of the old thread model with synchronization and shared memory you have actors (active objects) and messages. The actor model is present in core Scala, but Akka shows how it perhaps should have been done from the start. The founders of Scala and Akka have recently joined forces in a new company.

Since our computer hardware gets more and more cores (ability to do parallel processing) every year and The Cloud consist of an almost infinite number of boxes it is interesting with a programming model for parallel computing that really scales and is robust. That’s why Akka is interesting.

I for one, am looking forward to learning more about Scala and Akka and to using them in real commercial projects. What is the next thing you plan to learn?

 

Scala Code Kata Roman Numerals

Posted on by

There’s a Scala User Group in Gothenburg that had several meetings during this summer.  In one of the meetings the group solved a Kata named KataRomanNumerals (A Kata is a small problem that you do over and over again to learn)

The KataRomanNumerals says you should write a function to convert from normal numbers to Roman Numerals: e.g.

1 –> I

10 –> X

7 –> VII

Unfortunately I could not attend at this meeting, so I had to do it on my own during a few summer nights when my family finally was asleep :-).

Here’s my solution:

object Program extends Application {

class RomanInt(number: Int) {

def toRomanString() = {

val ones = List(“”, “I”, “II”, “III”, “IV”, “V”, “VI”, “VII”, “VIII”, “IX”);

val tens = List(“”, “X”, “XX”, “XXX”, “XL”, “L”, “LX”, “LXX”, “LXXX”, “XC”);

val hundreds = List(“”, “C”, “CC”, “CCC”, “CD”, “D”, “DC”, “DCC”, “DCCC”, “CM”);

val thousands = List(“”, “M”, “MM”, “MMM”);

thousands(part(1000)) + hundreds(part(100)) + tens(part(10)) + ones(part(1))

}

def part(digit: Int) = {

number % (digit * 10) / digit

}

}

implicit def Int2RomanInt(number: Int) = new RomanInt(number)

println(154.toRomanString()) // prints ‘CLVIII’

}

Here’s the code with better formatting.

Please comment and correct if I didn’t write idomatic Scala or if you have suggestions for improvements.

/Hans

Lift 1.0 !!

Posted on by

Webbramverket Lift, skrivet i Scala, har precis släppts i version 1.0. Mycket spännande, tycker jag. Citat från Michael Galpin:

Lift is the only new framework in the last four years to offer fresh and innovative approaches to web development. It’s not just some incremental improvements over the status quo, it redefines the state of the art.

Actors Galore

Posted on by

När jag började lära mig Scala så stötte jag direkt på Actors, ett koncept snott från (om jag förstått det hela korrekt) Erlang. Actors är ett sätt att få till concurrency genom att skicka meddelanden, till skillnad från det vi alla under ett decennium svettats med i Java, trådbaserad concurrency. Tanken är att det ska vara ett lättare sätt att programmera inför den multi-core framtid vi står inför.

Att skriva om sin applikation så att den kan hålla ett par kärnor varma låter sig kanske göras, men hur ska en vanlig applikation rimligen få mer än en handfull kärnor att komma över rumstemperatur?

Så kom Kilim, och jag gjorde ett försök att skriva ett enkelt exempel, men min förståelse för hur Kilim fungerade var för ytlig för att jag skulle ro det hela iland. Jag försökte skriva om min primtalsberäknare från JavaSpaces till Kilim, men det visade sig att att ha en master och många workers inte är det gängse sättet att använda sig av actors.

Nå, för en dryg vecka sedan bloggade Sujit Pal om alla de Actors-ramverk som nu dykt upp som svampar ur jorden. Han har fungerande kodexempel för Kilim, Scala Actors, samt Jetlang, ActorFoundry och Actor’s Guild (hehe, fyndigt namn)! Har man en gång utvärderat ett bleeding edge ramverk av den här typen så inser man vilken herkulisk insats han har gjort för att utvärdera fem ramverk!!

Om man detaljstuderar exemplena så ser man en del eleganta detaljer, men också för varje ramverk en del som ger mig lite ont i magen och gör att jag slipar tänderna mot varandra med ett ohälsosamt ljud. Med lite tur sätter sig de olika programmerarna samman och gör en AOP, dvs mergar sina respektive ramverk på samma sätt som AspectWerkz (drivet av en av våra svenska superprogrammerare Jonas Bonér) och AspectJ slog sina påsar samman och skapade den industristandard som vi nu åtnjuter.

Dependency Injection i Scala

Posted on by

Jonas Bonér har bloggat om Dependency Injection i Scala. Han presenterar tre olika sätt att göra det på, och hans favorit är rätt elegant. Ingen XML, och helt statiskt typat, men det känns ändå som lite av ett hack. Att ha en trait innanför en annan trait? Hm… som lite av de hack jag såg när jag var djupt nere i C++ träsket.

Scala klättrar snabbt på Tiobes lista – nu före Groovy!

Posted on by

Senaste listan på programmeringsspråk från Tiobe bjuder på en snabb klättring på ca 10 platser för Scala, som nu återfinns på plats 37, strax före Groovy på plats 39.

Mina nyhetskanaler är lite skeva, men jag tycker ändå att det är rätt tyst runt Groovy. Ett halvintressant inlägg om Grails är det enda jag sett på länge. Har rörelsemängden försvunnit? Ett tag hypades ju Groovy som det bästa sedan skivat bröd.

Woohoo: Mixed Scala and Java projects in Eclipse

Posted on by

A few days ago Scala 2.7.2 RC2 was released. One of the new features is mixed Java and Scala support in both the compiler and the Eclipse plugin. I decided to try it out. Installation was very simple. I then set off creating a simplistic Java class side by side with the Scala object, in the same package. I then created such a Java object in my Scala code, and ran it. It just works!

My Scala-presentation is now online

Posted on by

Yesterday I held this Scala presentation at Javaforum in Gothenburg. About 140 persons attended the evening seminar. All in all I think my presentation went pretty well, but Niclas Nilsson pointed out afterwards that I got the definition of Duck Typing wrong. I have corrected this in my S5 slides, which are in Swedish. I’m releasing my slides in the no-nonsense WTFPL license.

Then a group of us went to The Bishop’s Arms at Kungsportsavenyn and drank a couple of beers. It was me, my relative Niclas Palmquist, Niclas Nilsson, Viktor Klang and John Nilsson. After about an hour Luke Hohmann  approached us and wondered if we were the Scala  geeks. I have no idea how he figured that out.  🙂 It was in all a really enjoyable evening. If you ever bump into Luke, ask him  to tell you his "credit card numbers as disk address" tale. It is absolutely hilarious!

Scala 2.7.0 släppt

Posted on by

Det JVM-baserade språket Scala har precis släppts i version 2.7.0. Den stora nyheten är fullt stöd för Java 1.5 generics. Vill ni läsa mer om Scala kan ni läsa boken skriver av Bill Venners, Martin Odersky (skaparen av Scala) och Lex Spoon.

Groovy (and Ruby) only solves half the problem

Posted on by

It is with some dismay I’ve been reading the latest Groovy discussions on JavaLobby. I’ve spent quite some time learning Scala, so it bothered me a bit that I minded another competing language a spot in the limelight. Why would I care? To me as a consultant, language fragmentation is great. Today only a few languages are in widespread use, and there is no problem finding a skilled consultant at a reasonable price. But if Java and C# fragments into JRuby, Groovy, Scala, Jython, F#, IronPython, etc, then I’m better off since I will probably be able to charge more per hour in such a fragmented market.

As an anlogy, what if we all were driving either Fords or Mazdas – competition in the car mechanics market would be fierce since there would be so many that could fix our cars. Today we have dozens of car makers, and I can’t drive my Toyota to a Volvo mechanic and expect him to be able to fix it. Instead I have to drive to one of the few specialized Toyota mechanics that charge so much my nose starts bleeding when I open my wallet to pay.

What we all want is a more productive language, but we don’t want to throw away all our old frameworks and libraries. Which is where JRuby, Groovy and Scala comes in. Some people believe Groovy is the winner, because its syntax is so close to Java. But I think the only major difference, really, is where you declare the type:

// Java and Groovy
String a = "Xyz";

// Scala, knows it's a String by type inference
val b = "Xyz"

// Scala, if you wish to be explicit about the type
val c: String = "Xyz"

And, seriously, how hard can it be to learn the difference?

All these new languages have amazing features that Java doesn’t have, but dynamic typing isn’t one of them. Sorry, nobody can convince me that throwing away static typing is a good thing. Some argue that dynamic typing is preferrable during prototyping, when the code base is in big flux. At a later time, when the design has stabilized a bit, people claim you can re-implement it in a language with static typing. Sorry, that just don’t make any sense to me. During prototyping, when you’re fumbling around in the code to see where the abstractions are, is when I need static typing the most. Otherwise Liskov’s Substitution Principle will be the axe that chops off my fingers in the early morning when bright light shines on my nightly prototyping. (Sorry, I got a bit carried away there). Being sloppy about types is not an option.

Regardless, these new language features are way cool, and will hopefully be able to bring programming productivity up quite a bit. But don’t fool yourself – this productivity isn’t all that important, at least not for big projects. At Microsoft they write 1500 lines of code per year. Do you really think it matters much if it is in VB or F#? What really matters is readability. The reason they only write 1.5 KLOCs a year is most likely that their existing code is in such a mess that you need to be superhuman to understand it (and have 3 testers ready behind you at every moment).

And Java is pretty readable, IMHO. It is a rather simple language with few hidden surprises. At the moment my Scala reading skills is perhaps 10% of me reading Java. I hope to bring that up quite a bit, because Scala code isn’t 10 times more compact than Java.

The other half of the problem, if language features and compact readable code is the first half, is multi-core processors.

Most of us aren’t smart enough to manually split our applications into more than a few parallelly executing threads. We’re certainly not smart enough to spawn threads to keep 16 cores churning. In face of this problem, are we going to pick a new language with a rather immature VM (Ruby) or a language with a really complicated virtual dispatch scheme that complicates attempts of the VM to split jobs to several cores (Groovy)? It just doesn’t make sense to me!

Why not pick a language with immutable data structures and a really elegant actors library that gives us message passing concurrency? Why pick a language that makes it hard for the VM to parallellize, when we can pick a language where parallellization is a built-in feature from the start?

I think the choice is simple. Only one language solves the whole problem: Scala.

Automatic Resource Management Blocks i Scala

Posted on by

Joshua Bloch, som numera jobbar på Google, har gjort ett förslag på hur man i Java ska slippa behöva anropa close() på resurser i finally-satser. Ni vet:

BuffereInputStream bis = null;

try {

   BuffereInputStream bis = …;

   // Use bis

} finally {

   if (bis != null)

      bis.close();
}

Chris W. Hansen beslutade sig för att se om det gick att göra i Scala, utan att behöva ändra något på själva språket (vilket är vad Joshua föreslår). Resultatet är lysande, och enkelt!

Steve Yegge om hur språkvalet påverkar kodbasens storlek

Posted on by

Steve Yegge, som jag bara stött på vid några tillfällen tidigare, skrev strax före jul ett blogginlägg under rubriken Code’s Worst Enemy. Där försöker han, utifrån erfarenheten från ett spel han skrivit på egen hand i Java, argumentera för att det är Javas fel att hans kodbas nu är på 500 000 rader. Vilket han nu inte längre klarar av att underhålla.

Nu kan man ju undra hur en person över huvud taget kan skriva en halv miljon rader Java. Och premissen att det är Javas fel att det är så många rader kan ju också diskuteras. Men jag är nog böjd att acceptera att Java kanske inte är det tightaste språket på planeten. Men Steves beslut att skriva om allt i Rhino känns ju rätt bisarr.

Över huvud taget ska man, enligt min ödmjuka mening (IMHO) tänka sig för innan man börjar skriva ett stort system i ett dynamiskt språk. Dels får man betala detta med "continuous tax", samt att man inte kan få något riktigt solitt refactoring stöd. (Båda länkar går till blog-inlägg av husguden Cederic Beust).

Så min rekommendation, om man är rädd för att begrava sig själv i sin kodbas, är att välja Groovy, där man i alla fall kan slå på statisk typning om man vill, eller Scala som är statiskt typat. Och båda kommer med bra webbramverk i form av Grails och lift. Utan ett sådant är ett språk rätt kört.

Hur som helst så har Steves inlägg genererat en otrolig mängd med inlägg av många rätt kända personer. Har ni några timmar till övers så är det värt en titt.

Terracotta clustering of Scala Actors

Posted on by

I Scala finns ramverket Actors, som ska vara en nära mappning av Erlangs framgångsrika motsvarighet med samma namn: ett meddelande-baserat ramverk för concurrency. Nu har Jonas Bonér kopplat ihop Scalas Actors med Terracotta, vilket ger oss transparent klustring av dessa Actors!

David Pollak, skaparen av webramverket lift för Scala lät hälsa:

This is most awesome news. I’ll do some work seeing if we can scale Skittr to 50M users on an EC2 cluster.

Jag har ganska svårt att föreställa mig en häftigare applikation: Scala, lift, Actors, Terracotta och EC2. Ring mig om ni har ett Scala-uppdrag i fickan!

Intressant intervju med Scalas Martin Odersky

Posted on by

Skaparen av det nya coola språket Scala, Martin Odersky, blev intervjuad på JavaPolis som gick av stapeln i Beligien för nån vecka sedan. En halvtimmes snack som man kan lyssna på när man plockar med disken. Det gjorde jag. Det verkar, som jag misstänkte, att Actors är precis det ramverk som kan ge oss det stöd vi behöver för transparent distribuering av våra program på multi-core processorer. Yay!

Varför Scala kan vara nästa stora programmeringsspråk

Posted on by

Jag har funderat ganska länge på vad nästa stora språk skulle kunna vara. Jag var tidigt med på resan från C++ till Java. Åkte på den första JavaOne konferensen i San Francisco, och trodde redan då att Java skulle ta över. Så fort det var möjligt lämnade jag C++ bakom mig, trots att jag skrivit en bok om C++ och suttit i standardiseringskommissionen för C++.

Men Java varar inte för evigt, och jag har på egen hand samlat på vad jag tror är viktigt för att något ska bli "nästa stora språk":

  1. Dess syntax får inte vara för olika det som gäller idag, dvs Java, för annars kan man inte få speciellt många att migrera.
  2. Det måste bygga på en virtuell maskin, troligen endera JVM eller Microsofts CLR. De ger den portabilitet vi kräver idag. (CLR är ju kanske inte så portabel, men i teorin finns ju Mono.)
  3. Det måste ha inbyggt stöd för multi-core. Då menar jag inte bara det språkstöd som finns i Java och andra språk för att skapa och starta trådar, utan inbyggt stöd så att virtuella maskinen kan bryta loss delar av det som ska exekveras till olika cores i framtidens processorer. Om 5 år har vi ju kanske 16 cores som standard i en processor, och att manuellt skriva kod som utnyttjar dem är för svårt för annat än experter.
  4. Det måste ha stöd av ett stort företag som kan ställa upp med resurser att skriva verktyg, bibliotek, marknadsföring, konferenser, böcker, etc.
  5. Det måste ha bra prestanda. Visst, Javas prestanda var inte bra från början, men det fanns inget skäl till att det skulle behöva vara långsamt, och idag har Java väldigt bra prestanda, förutom startup tid.
  6. Det bör helst inte överge tidigare investeringar i redan existerande kod.
  7. Det bör vara statiskt typat, för annars blir det svårt att bygga bra verktyg för bland annat refaktorering, vilket är nödvändigt för större projekt.
  8. Det måste vara objektorienterat – det är otvetydigt så att det är det paradigm som fungerat bäst för att bygga stora system.

Java har idag allt detta, förutom 3, och det oroar mig en del. Så fick jag höra talas om Scala och dess ramverk som heter Actors. Det hävdades att det skulle hjälpa till med just detta med multi-core. Har ännu inte läst in mig på just Actors, men jag blev nyfiken på Scala och läste in mig på det.

Scala är ett statiskt typat objekt-orienterat språk med en syntax som är tillräckligt lik Java för att man ska luras att ta en närmare titt. När man väl sett på vilket sätt det också är ett funktionellt språk, med dess annorlunda syntax (som jag tror måste till av ren nödvändighet för att ge ett sådant stöd), så har man redan svalt kroken, sänket och hela korken.

Scala ligger ovanpå Javas virtuella maskin, och Java-klasser kan användas rakt av. Java-kod är inte automatiskt giltig Scala-kod, på det sätt som all C för 15 år sedan var giltig C++, men man kan ta med sig existerande Java-kod in i den Scala kod man skriver.

Tyvärr har inget större företag ställt sig bakom Scala ännu, men det finns riktigt många projekt som jobbar på verktyg och ramverk. Det finns en rätt bra Eclipse-plugin, ramverk för enhetstestning, ett mycket intressant webbramverk som heter lift, en mycket aktiv och hjälpsam mailinglista, och ett par böcker på gång. En av böckerna kan man precis förbeställa!

Scalas prestanda är mycket bra, kan till och med med vara snabbare än Java.

Här står jag själv just nu. Jag ska läsa den nya Scala-boken över julhelgen. Just nu är jag mest en entusiastisk amatör som tror jag hittat något som kan bli riktigt stort.

Webbprogrammering med Scala och lift

Posted on by

Språket Scala har sedan något halvår tillbaka haft ett webbramverk kallat lift.

  • Comet support is easy to add and scalable
  • Mapping between databases and code is easy (Rails)
  • Content and code are well separated (Wicket, TurboGears)
  • Forms are secure by default (Seaside)
  • Convention over configuration is emphasized, no xml hell (Rails)
  • Component model makes pages elements easier to create and maintain (Wicket)
  • Prebuilt classes are provided for standard functions, e.g. User (Django)
  • Semantic information carries from model to enable smart display. e.g. postal code, social security number, email address
  • State machine support for model objects, including timeouts. e.g. after 3 days w/o confirmation, delete this new account
  • Site Map provides site wide navigation and access control support

Bättre start är ju svår att få. Jag bara önskar att jag hade något roligt projekt att testa det på.

X10? No, I don’t think so

Posted on by

En artikel på Sys-Con, Multi-Core and Massively Parallel Processors, fångade precis mitt intresse. På slutet av artikeln, som annars visade sig vara rätt ointressant, presenteras språket X10, ett språk som bygger på Java men där man lagt till ett antal konstruktioner för att stödja multi-core processorer. Min första tanke var "suck, ännu ett språk jag borde kolla upp", men en titt på deras mailinglista för användare ger vid handen att den under 2007 haft sammanlagt 65 email, dvs 2 i veckan eller så. Inget signifikant kan växa ur ett så magert intresse!

Jämför det med mailinglistan för Scala som har ca 7 mail om dagen, dvs ca 25 gånger mer.

Scala 2.6.0 släppt

Posted on by

Massor av buggfixar, och några smärre språkändringar. Go Scala Go!

Detta har hänt i sommar

Posted on by

För er som inte knarkar tekniknyheter lika okontrollerat som jag gör har jag nöjet att få summera de senaste 5-6 veckorna inom områdena Java, Ajax, Scrum och annat av intresse. Tro mig, jag har gallrat stenhårt.

  • JUnit 4.4 släpptes nyligen. Nyheterna var inte speciellt upphetsande.
  • En av mina favoritbloggare, Cederic Beust, har skrivit om dynamiska och statiska språk. Inte mycket text, men mycket intressant. Väl värt ett par minuter.
  • Av någon anledning är kodformattering mig nära hjärtat, så det var med visst nöje jag noterade att Slashdot hade en tråd om detta i somras. David Herron har bloggat i samma domäner, vilket är kul, även om han verkar ha snott titeln på sitt inlägg från mig.
  • Medlemmar från Ajax-ramverket Dojo har skrivit en artikel med namnet "Why Dojo", som jag tror alla som står i valet och kvalet att välja Ajax-ramverk nog bör läsa. Dojos event-modell är väldigt cool, och tydligen har den blivit extra bra i senaste 0.9 versionen av Dojo.
  • En annan Ajax-artikel med namnet "Write scalable Comet applications with Jetty and Direct Web Remoting" borde intressera alla som försöker välja Comet-ramverk. Go DWR Go!
  • ThoughtWorks har släppt en "agile project management software" med namnet Mingle. Vet inget mer om detta, men Henrik kanske känner sig manad?
  • Matt Raible har summerat "Open Source Web Frameworks’ Mailing List Traffic – June 2007", dvs hur mycket trafik är det på de olika ramverkenas mailinglistor. Ganska intressant, om man försöker avgöra vartåt det blåser. Till min stora glädje ligger Wicket bra till, Liksom GWT, men mest trafik har Ruby on Rails, vad man nu kan dra för slutsatser av det?
  • W3C funderar på att inte låta HTML 4 övergå till XHTML, eftersom de verkar vilja göra en femte version av HTML. Vad ska man tro om det?
  • Specifikationen för Java EE 6 har släppts. Troligen kommer de första implementationerna först i början av 2009.
  • Jag försöker hålla ett öga på vad som skrivs om Scala, då jag fått intrycket att det kanske är ett bra språk för framtidens multi-core processorer, så artikeln "Is Scala the new Groovy" kunde jag naturligtvis inte undvika. Sedan finns det de som tror att Terracotta är rätt väg att skriva multi-core applikationer i Java, så "Hello Terracotta" kanske är rätt ställe att börja?
  • Vill man läsa mer om JavaScrips framtid så kan man läsa här. Daniel?
  • För oss anhängare av Google Calendar är nog artikeln "Black belt scheduling with Google Calendar" oundviklig.
  • Vad kommer efter social networking? Själv har jag inte en aning, eftersom jag känner mig helt bakom flötet när det gäller Facebook, YouTube, MySpace, Twitter, etc etc etc.

Privat har jag varit en vecka i Småland, 4 veckor i Thailand, samt en vecka i Västerbotten, där jag och mina två söner besteg fjället Jengegietje, 1477 meter över havet, i lysande väder. Shorts och T-tröja räckte på toppen!

Kanske är det Scala?

Posted on by

Jag har tidigare bloggat om vilket språk som kanske kan ta oss med i multi-core racet. Erlang skulle kännas som ett nederlag (några av er kanske förstår varför). Ruby hypas ofta som nästa stora språk, men är det något att hålla i handen när man surfar loss på flera cores? Jag tvivlar, av ren princip, utan att egentligen veta. När ska man få vara ologisk och partisk om inte vid valet av nästa språk att riskera sin karriär på?

Så nyss bankade jag pannan i en artikel skriven av Bill Venners, Martin Odersky och Lex Spoon med namnet First Steps to Scala. Inledningen är mycket intressant:

Scala is a statically typed, object-oriented programming language that blends imperative and functional programming styles. Scala is designed to integrate easily with applications that run on modern virtual machines, primarily the Java virtual machine (JVM). The main Scala compiler, scalac, generates Java class files that can be run on the JVM. However, another Scala compiler exists that generates binaries that can be run on the .NET CLR, as Scala is designed to integrate with both the Java and .NET worlds. In the Java world, the Scala language can be used alongside the Java language—either as an alternative to Java—to build applications that run on the JVM.

Scala was developed starting in 2003 by Martin Odersky’s group at EPFL, Lausanne, Switzerland. Previously, Martin had been active in the Java field. He co-designed the first version of Java generics and was the original author of the current javac compiler. The work on Scala was motivated by the desire to overcome limitations imposed by backwards compatibility with Java. So Scala is not a superset of Java, but it retains seamless interoperability.

Mmmm, kanske en Rocket Day om detta i Crisps regi?