Frank Sommers
Posts: 2642
Nickname: fsommers
Registered: Jan, 2002
|
|
Re: A Business Case for New Languages
|
Posted: Apr 18, 2011 10:21 PM
|
|
This is an issue I'm dealing with right now. I personally like a Scala a lot, and have been writing all of my new (server-side) code in Scala for the past 1.5 years. I can personally see big efficiency gains, better code quality, better design, possibly more scalability, more agility of the codebase - I can see all that using Scala.
That said, I suppose the discussion about Scala as a business keys should be qualified as using Scala to write new code - old code, by definition is already written - or even in a new project.
If we restrict the discussion to new code or a new project, then I think almost any business today has to consider time to market as a key criterion for architectural, including language, decisions.
With that narrower context, the question then is, To what extent does Scala help you deliver a project / product to market quicker than technology / language X?
That more defined question then brings into play some of the considerations a business manager would have to weigh, such as: How easy is it to staff the project (given a finite budget)? How do the language and tools support reliable delivery in the face of a changing specifications and requirements, which are common in new projects? How easy is it to leverage existing infrastructure from the language (as compared to language / framework X)? And what kind of developers would Scala attract compared with, say, language X, and are those the kind of developers the project really needs? Etc.
Answers to some of these are more obvious than to others. Clearly, good luck trying to find experienced Scala developers (at an affordable rate, compared to, say, Java developers). Scala IDEs truly lack behind mature Java IDEs (even with the recently released excellent Eclipse Scala IDE and IntelliJ) -- expect those tools to get in the way quite a bit still, which will waste time. But Scala may attract some of the top developers to a project, so that's a huge plus, provided that your project needs top-notch developers (every project needs them, of course, but few can afford them!).
Introducing anything new, of course, causes a temporary dip in productivity. The question is, can you make that up as you gain more experience, given that your competitors may be working on similar solutions using some other technology which they may be experts in already? My experience is definitely "yes" -- however, it would be a mistake to underestimate the Scala learning curve, which may be bigger than the Java learning curve was for C++ or COBOL programmers.
You *will* traverse down blind alleys in design and implementation, and will end up throwing away code and redoing work, as Scala dictates fundamental design choices that only become apparent with experience. That's great for learning, of course, but there's a time factor involved. (Even after 1.5 years of writing mostly Scala code, I would not consider myself an expert. That was definitely not my experience moving to Java - first learning Java in 1995, by 1997 I certainly felt mastery of all the Java language and design constructs.) You definitely have to consider available training as a business requirement.
My experience is that Scala is still 1-2 years away from the tipping point where using it in general would make a compelling business case. The inflection point maybe a truly great IDE, some API or framework, I'm not sure. Once that point is reached, though, lots of business managers will be ready to embrace Scala, because the benefits will be obvious to them.
|
|
Previous Topic
