Tag Archives: c++

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.

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.

Gratiskurs: Java för C++ programmerare

Posted on by

För ett år sedan höll jag en endags kurs om Java för en grupp C++ programmerare. Sedan dess har materialet legat på hårddisken oanvänt. Så jag putsade till det lite, skrev lite nytt material och lade precis upp det på nätet i S5 format.

Man kan med viss rätta tycka att jag är ett decennium för sent ute, men Java är ett rörligt mål, och jag är ganska nöjd med resultatet. Jag tycker att det är en grundlig genomgång av vad Java är och hur det skiljer sig från C++. Jag har en gedigen bakgrund inom C++, så jag tror jag fått med det mesta, förutom att jag inte hängt med så bra i vad som sker i C++ svängen de senaste åren. Även C++ är ett rörligt mål, tydligen.