« Return to Thread: [scala] Risks of using Scala in a large application?
Re: [scala] Risks of using Scala in a large application?
by James Iry-2
::
Rate this Message:
On Tue, May 6, 2008 at 9:33 PM, Ashley Aitken <mrhatken@...> wrote:
Language design is as much about what you don't put in as what you do. Scala ditched or changed several of the shakier concepts in Java. For instance, do you really need both if/else and the ternary (?:) operator; can't one construct do both? Isn't return just syntactic noise in most places? Hasn't "switch" with fall-through been a known source of bugs since the days of C?
I don't see Java fixing these things. In other words, no matter how much is added to it, Java will probably never be Scala.
There are substantial productivity gains to be made, though, and that can help offset risks. E.g., applications often get replaced about every 5 years anyway - so what could you gain in 5 years with double productivity? If for some reason you have to replace after only 3 years, won't you still have come out ahead?
Scala can "consume" any normal Java code, extend a Java class, etc. There are some challenges in some cases where libraries use byte code enhancement. In those few cases, people have been writing a few parts of their code base in Java.
The converse takes more effort. Java can consume Scala code as long as it more or less sticks to the Java-like subset of Scala.
In a theoretical sense neither language will create a hard limit, of course. Anything you can accomplish in one you can accomplish in the other. In practice the interaction with 3rd party libraries is a bit different and you just can't afford to reinvent all those wheels. The good news is that Java's slow change rate and the vast size of the existing code base for Java mean that you shouldn't have to worry about Java dependencies disappearing for a good long time. Since you can consume pretty much all of that from Scala right now, you're set for awhile.
For now just assume you won't find Scala developers and that you will have to train. Some back of the envelope estimates indicate, to me at least, that the ROI is very good on this investment - e.g. you might have to keep a developer for only 4 months for training time to pay off. But that's very back of the envelope. While there's much anecdotal evidence on the increase in productivity with Scala there's been no attempt to do a real study. And how long it takes to retrain a Java programmer in Scala is anybody's guess.
IDEs and other tooling are making huge progress. But remember, the reports of productivity increase have come with tools as they exist now. As for longevity of Scala - well the bits aren't going anywhere. Even if your team turns into the only one on the planet that uses Scala, you'll be able to keep going for a long time while you figure out if, when, and how to replace it.
Scala seems to me, from my quick introduction, what Java may be like in 5+ years.
Language design is as much about what you don't put in as what you do. Scala ditched or changed several of the shakier concepts in Java. For instance, do you really need both if/else and the ternary (?:) operator; can't one construct do both? Isn't return just syntactic noise in most places? Hasn't "switch" with fall-through been a known source of bugs since the days of C?
I don't see Java fixing these things. In other words, no matter how much is added to it, Java will probably never be Scala.
So using Scala can give one a competitive advantage. However, there is often risk associated with such a decision.
There are substantial productivity gains to be made, though, and that can help offset risks. E.g., applications often get replaced about every 5 years anyway - so what could you gain in 5 years with double productivity? If for some reason you have to replace after only 3 years, won't you still have come out ahead?
What are the risks of using Scala in a large Enterprise application? Mostly I mean in relationship to compatibility with Java, interaction with Java libraries (will Scala limit this) and tools, Java interaction with Scala classes etc.
Scala can "consume" any normal Java code, extend a Java class, etc. There are some challenges in some cases where libraries use byte code enhancement. In those few cases, people have been writing a few parts of their code base in Java.
The converse takes more effort. Java can consume Scala code as long as it more or less sticks to the Java-like subset of Scala.
The low risk situation would be that Java and Scala are completely interchangeable, if I write something now in Scala it won't limit me and I could replace it with Java in the future if need be (e.g. if/when Java catches up and/or Scala doesn't catch on) without any trouble.
In a theoretical sense neither language will create a hard limit, of course. Anything you can accomplish in one you can accomplish in the other. In practice the interaction with 3rd party libraries is a bit different and you just can't afford to reinvent all those wheels. The good news is that Java's slow change rate and the vast size of the existing code base for Java mean that you shouldn't have to worry about Java dependencies disappearing for a good long time. Since you can consume pretty much all of that from Scala right now, you're set for awhile.
Of course there are other risk: finding developers that are competent enough in Scala, IDE tooling for Scala, longevity of Scala, and any discussion of these would also be appreciated.
For now just assume you won't find Scala developers and that you will have to train. Some back of the envelope estimates indicate, to me at least, that the ROI is very good on this investment - e.g. you might have to keep a developer for only 4 months for training time to pay off. But that's very back of the envelope. While there's much anecdotal evidence on the increase in productivity with Scala there's been no attempt to do a real study. And how long it takes to retrain a Java programmer in Scala is anybody's guess.
IDEs and other tooling are making huge progress. But remember, the reports of productivity increase have come with tools as they exist now. As for longevity of Scala - well the bits aren't going anywhere. Even if your team turns into the only one on the planet that uses Scala, you'll be able to keep going for a long time while you figure out if, when, and how to replace it.
« Return to Thread: [scala] Risks of using Scala in a large application?
| Free embeddable forum powered by Nabble | Forum Help |
