On Mon, Jun 13, 2011 at 9:44 AM, Mario Fusco <[email protected]> wrote:
> > I still find lots of things that I don't know that would > > give a much greater ROI if I spent some time in learning them. > > In my opinion there is an enormous ROI in learning Scala. You're just > looking for it in the wrong place. Let me make an easy example: why do > you spend so much time (I know you do) in configuring your building > tool? That's a very interesting example, because in my experience, the build problem is pretty much solved in the Java space while it remains quite immature in Scala. The amount of sbt bitching that happens on a daily basis on irc is quite impressive, with people either trying to make it work the way they want to or simply going back to Maven (not the best choice for Scala, but at least it works as expected). And there's the fact that Scala is also considerably slower to compile than Java. Yes, you have fewer lines of code in general, but while I haven't run any specific benchmark, my impression is that for build times, the two languages are pretty much on par (happy to be proven wrong or right by some data). Now consider Scala. You're right: none of your customer are asking for > it as much as none of them ask for a building tool or a test suite. > However, after I have been working with it for a few months, I can say > that in my experience the typical Scala program is more or less 3 > times shorter than the equivalent Java one. In other words, by using > Scala you have to design, write, test, debug, refactor and maintain > only one third of the LOCs. You seem to imply that the size of your tests is directly proportional to the number of lines of code. That seems wrong to me: you test functionalities and you test public API's. The language you use to implement those should not have a dramatic effect on the amount of testing that you need to do. Scala offers to implement the *same* functionalities in less code. Surely you want to test these functionalities just the same as you do in Java. > Don't you really see any ROI in it? > Another analogy could clarify (if necessary) my thoughts: just suppose > I could go to a car manufacturer and say I have a technology through > which he could build a given car with only 1,000 components instead of > the usual 3,000 ones. Don't you think he could be very interested in > it? I guess so and of course not because his customers asks for cars > with less components as possible (at least I didn't do that when I was > looking for my car), but because that gives him a big technical > advantage, by allowing to reduce the costs and the possibility of > defects and possibly to hit the market before of his competitors. > Assuming that these 1,000 smaller components cost less than the 3,000, which is rarely the case in manufacturing. And that they are easy to service, and reliable, and long-lasting, and easy to find, and that you can retrain your workers quickly to understand how they work and how to fix them You need to make a case for all these dimensions of the problem, it's not as simple as saying "1,000 vs 3,000". -- Cédric -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
