Mats has posted 1 posts at DZone. You can read more from them at their website. View Full User Profile

Groovy (and Ruby) Only Solves Half the Problem

02.20.2008
| 18068 views |
  • submit to reddit
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.

Published at DZone with permission of its author, Mats Henricson.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Matt Raible replied on Wed, 2008/02/20 - 6:41pm

Are you implying that DZone should add a scala.dzone.com zone? While I hear a lot of folks beating the Scala drum, it just doesn't seem as exciting as Ruby and Groovy. Maybe this is because Scala doesn't have a kick-ass web framework? I know there's Lift, but it doesn't seem to have a whole lot of books and success stories plastered all over the web. I will admit that this post sounds intriguing though.

mark taylor replied on Wed, 2008/02/20 - 8:42pm

Undoubtedly, this is a Golden Age for languages on the JVM. But a couple of things really bug me about the current state of affairs. Ruby's scaffolding (compiler generated interfaces to rdbms') is an example of the power of dynamic languages; it removes a whole class of boiler plate code. So I think it's really depressing when Java/Groovy/JRuby/Scala folks talk about things like "look how language feature X makes writing this SQL query so much Easier!"

If the goal is to increase productivety by orders of magnitude it's not enough to think outside the box, the goal should be to completely destroy the box; in this case, stop writing SQL. This changes the game.

The other thing that bugs me is a bit harder to express. Scala's more esoteric features are firmly rooted in SML/OCaml. These languages are suited for manipulating very abstract data structures like tree's and graphs. In computer science literature SML is frequently used to implement denotational and operational semantics of programming languages. Often times a denotational representation of a language in SML is an executable interpreter of the language. In other words, in a language like SML, the ebnf of a language IS the language.

Scala inherits this capability by it's close connection to the ML's.  So my point is; 'yet another web framework' that lets the user write 'Scala server pages' should not be the goal (I'm not saying Matt R. says this, I'm just extrapolating the tone of the conversation in the blogsphere). The goal should be to change the game. Like maybe building web applications with Continuations? I have no idea how this would work so I won't elaborate (if I had the next 'big thing' I wouldn't be writing about it here anyway!)

Michael Kimsal replied on Wed, 2008/02/20 - 11:07pm

@mark - groovy is a language and ruby is a language.  I may be missing something, but I've not seen scaffolded interfaces done with plain old ruby - it's the rails framework that does that.  Similarly, Grails provides the same level of abstraction with Groovy.  I've written a few small apps without having to writen any SQL at all.  I'm debating starting a new one (small/medium size) and I expect I may not have to write any SQL, or at most 3-5 manual queries.  Grails does the rest of the heavy lifting for me.

I've not seen enough of Scala yet to have much of an opinion.  The little I've seen has seemed way too "computer sciency" and not practical enough.  I didn't see any problems presented in any Scala documentation that spoke to any domains I've worked in, so there's been no 'ooh, gotta have that' factor.  Groovy had that for me, as I wanted to do more Java (for a variety of reasons), but coming from the PHP world, plain old Java has always been way too cumbersome.  Groovy/Grails spoke to problems I've had and showed a better option than what was out there before. 

Mats, is Scala really reaching people with specific problems with a better answer?  Apparently it's done it for you, but it didn't do it for me.  

Mats Henricson replied on Thu, 2008/02/21 - 3:38am

@Matt: I'm split on the issue of creating a scala.dzone.com. I think that would open up the gates of hell. We'd be forced to create a X.dzone.com for every language X that runs on the JVM. On the other hand I hate the cross-posting fanboys of various languages. Do you remember all the "C# will kill Java within a year" posting to JavaLobby in the early 2000? I wished they could go play in their own sandbox.

I've read the lift tutorial, and I found it very exciting. It rubbed me the right way about Ajax, Comet and Actors. Very very elegant. Ajax and Comet wasn't bolted to the hull as it is was done for JSF and oh so many other frameworks.

@Mark: Scalas Actors framework (a port of the Actors framework in Erlang), is built (I think) using continuations and the new fork/join threading framework in Java 5. But don't quote me on that... hm, this posting will be spidered by Google, which means... wait a minute! ;-)

@Michael: Yes, far too many Scala examples are computer sciency, and I hope that will change. But it IS used for real, making real web sites. David Pollak is using lift with Terracotta on Amazon EC2 clusters. I could pay to work on that.

John J. Franey replied on Thu, 2008/02/21 - 8:57am

@Matt - Why should it be necessary for a JVM based language to demonstrate itself with a 'kick-ass' web framework? A very big selling point of JVM based languages is that all existing java based code is accessible. This would include framework libraries. In theory, any JVM based language can be used in any existing JVM based web app development frameworks.

An imagined example, since scala cleanly supports java annotations verbatim, it ought to be possible to write Seam business components in scala. (I'm not trying to exclude any other jvm based language in this hypothetical.)

I'm not taking the position that java lobby should have 'zone' for scala. I think the absence of a scala zone in javalobby isn't depriving web readers of information on the language.

Within the extent of JVM languages, what justifies the implied binding between a language and web framework? How does a language specifc framework (e.g. scala on rails) give credance to JVM based language?

Regards,

John

 

 

 

Reid Atherton replied on Thu, 2008/02/21 - 9:11am

What makes Scala Actors so much better than Groovy Actors?

josef betancourt replied on Thu, 2008/02/21 - 12:02pm

You stated:

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

But, alternativly, you could use the following in Groovy:

// Groovy
def a = "Xyz";

 

Mike P(Okidoky) replied on Thu, 2008/02/21 - 1:37pm in response to: josef betancourt

I'm not a Scala or Groovy expert, and I could be wrong here, but I think the difference is that in Scala 'a' actually becomes a typed String object, whereas in Groovy 'a' becomes a dynamic variable.  Typed variables have big advantages for catching mistakes at compile time.

Sean Song replied on Sat, 2008/02/23 - 1:50pm

In real project, I do not use language without IDE supporting refactoring, debugging, data type hierarchy, call type hierarchy, intellisense, extension/implementation search, etc.

Groovy has JetBrains and JRuby has Sun.

Who does Scala have?

replied on Sat, 2008/05/03 - 9:01pm in response to: mark taylor

lift does in fact offer a different approach to web frameworks... one influenced by Seaside and WebObjects as well as Rails.

Most notably:

  • lift binds form fields to functions such that you don't need a front-controller and you get the same benefits as you get with continuations
  • lift binds Ajax-based form fields to functions that can return JavaScript so you get "live" Ajax code in a single file (and sometimes in a single line)
  • lift assigned form field names in a non-repeatable way which makes replay attacks and CSF attacks near impossible.
  • lift has the best Comet support around. The developer need only write the "Actor" that responds to event and the draw commands (or full component redraw) associated with the change (and it support Ask/Answer deligation to other components.) Here's the entire code required to do a clock that updates the browser every 10 second:

class Clock (info: CometActorInitInfo) extends CometActor(info) {

  def defaultPrefix = "clk"
  ActorPing.schedule(this, Tick, 10000L) // schedule a ping every 10 seconds so we redraw

  private lazy val spanId = uniqueId+"_timespan"

  def render = bind("time" -> timeSpan)

  def timeSpan = (<span id={spanId}>{timeNow}</span>)

  override def lowPriority : PartialFunction[Any, Unit] = {
    case Tick =>
      partialUpdate(SetHtml(spanId, Text(timeNow.toString)))
    ActorPing.schedule(this, Tick, 10000L) // schedule an update in 10 seconds
  }
}

 

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.