Recently, we've decided to use Scala as part of an enterprise software solution stack. And I'd like to mention a few things on how the hell that was allowed to happen.
The Grey Lens Man's View blog recounts the initial stages of transitioning to Scala in an enterprise development environment. (As an editorial aside, we prefer to refer to authors by name, not by blog title. However, we were unable to track down the true name of the Grey Lens Man.)
The problem the Grey Lens Man outlines is that of a massive legacy application that needs to be rewritten in some modern environment, and the search for a suitable language and framework:
This system is responsible for several billion in revenue. If the mainframe goes off line a few pagers chirp, but if that system goes off line, it's klaxons and battle stations.
Universal agreement, its got to go. It has been end-of-life scheduled more often then a serial killer on death row. IT leadership comes and goes, yet, a full decade later it sits there in the data center laughing at me like an evil essence hosting Steven King basement furnace...
Grey Lens Man's team at first considered Java:
Lets, just say it, Java, by design, is a pretty simplistic language, I would argue even a crippled language for uses other then its original design point, which was certainly not server side enterprise IT. As a result, the cottage industries around Java are practically their own Industrial Sectors.
Java is the Brier Rabbit of IT. Once touched you can't let go. Its simplistic enough to be inadequate in almost every situation. The commercial world just loves this aspect of Java as they exploit revenue streams from filling these gaps via endless Frameworks, Patterns, APIs, Annotations, IDEs and Toolsets.
The dirty secret of course is 25 - 50% of all of it is pure overhead, without direct value, but necessary to overcome the inherent limitations of Java.
On the other hand, the upside of Java for enterprise IT is pretty obvious. Any problem you might have can be solved with money and armies of plug and play bodies and you get mountains of buzz material for those presentations.
By contrast, an ideal language for this enterprise task would include the following characteristics, according to the Grey Lens Man:
Simple, clean and full featured.
Ready of concurrency, distributed applications on mult-core commodity boxes.
Allow for the explicit control of state and state mutation.
Support for modularity, and scaling in the large.
Multiparadigm to support mapping the commonality and variability of the domain problem to the code.
Capable of supporting Application Oriented Language / Domain Specific Language development (AOL/DSL).
Cross platform, with a large supporting tool suite universe.
Open and not subject to Vendor locking.
Fast
OO
Functional
Conceptual Integrity
Allow control of, if not out right banishment of the null pointer.
Rich libraries
Strongly Typed
Practical and Pragmatic
Accessible to the average developer, empowering to your A players.
Runs on a portable VM
Leverage existing extensive Java libraries
This is Scala.
The solution the Grey Lens Man outlines centers around JSON, OSGi, Scala, and HTTP.
The Grey Lens Man concludes that:
But bottom line, enterprise Java developers can transition to Scala. I know this, because I've directly observed it.
Do you share the Grey Lens Man's view that migrating to Scala is relatively straightforward for an experienced Java development team?
I've only used Scala a little bit, so take this with a grain of salt. It seems like an intriguing language.
But, if Scala were really designed to be migration friendly from Java, they shouldn't have, apparently deliberately, made the syntax so different. I'd prefer a more "Java-like" syntax that still advances the language design.
His first bullet point is a bit of a stretch: Simple, clean and full featured Scala maybe satisfies full featured.. maybe.. but simple and clean? Ahem. Scala will be simple only if his team members all ignore its full-featuredness. Perhaps some will, but some won't e.g., Ruby followers will write Ruby looking code in Scala -- because they can. Scala is not simple.
I'm not a dynamic language fan, but considering Scala's wildly complicated type system I have to agree with Guido's assessment "...if this is what it takes to have compile-time type-safety in a language, I'll take dynamic typing any day." Scala is clean only in the academic sense.
And how can anyone describe Scala as: Accessible to the average developer, empowering to your A players?? The features that "empower" the A players are the exact same ones that will totally alienate the average ones. The dirty little secret is that they'll also alienate the A players because the code can become incomprehensibly clever.
I'm a hobbist programmer, but I wouldn't reguard Scala as a profoundly difficult language to learn. Simple usage of the type system and traits can be started relatively early. The more advanced stuff (I'm still not there) you can skip and learn gradually. By comparison, you wouldn't discard C++ just because it had template metaprogramming (ok, maybe not the safest analogy to make:).
I don't think the list is meant to be taken seriously by programmers, given that the list includes no positives for Java (a proven language with a massive community and a ready supply of talent at all competence and wage levels) and no negatives for Scala (commercially unproven, miniscule community and support, no available pool of experienced programmers of any kind).
It's a sales list designed to convince his managers that Scala, despite the above, should be the language of choice for new developments.
Personally, I think if you want the managers of a commercial enterprise to bet the company on Scala, then (because it's a JVM based language) you want to use Java to open the door for Scala by selling the strengths (and mentioning the weaknesses) of Java and then demonstrating (with actual code) how Scala compliments those strengths and negates its weaknesses, thereby coming up with a stronger overall development environment.
> The features that "empower" the A players are the exact > same ones that will totally alienate the average ones. The > dirty little secret is that they'll also alienate the A > players because the code can become incomprehensibly > clever.
You can write incomprehensibly clever code in any language. Learning to avoid doing so is the mark of experience, good judgment, and effective code review.
As for advanced features alienating average programmers, this is only a significant risk if you can't do useful and idiomatic things in the language without those advanced features, or if those advanced features are not well-integrated with the basic features.
So long as the language allows a fairly smooth progression along the learning curve, I think your OK.
Speaking of learning curve, I hope the Eclipse plugin gets better soon. “Quick Fix” is a must. As it is now, Quick Fix doesn’t show any suggestions. The plugin also throws some weird UI errors in error log. Figuring out errors on your own, without IDE’s help, isn’t always easy.
> His first bullet point is a bit of a stretch: > Simple, clean and full featured > Scala maybe satisfies full featured.. maybe.. but simple > and clean? Ahem. Scala will be simple only if his team > members all ignore its full-featuredness. Perhaps some > will, but some won't e.g., Ruby followers will write Ruby > looking code in Scala -- because they can. Scala is not > simple. > > I'm not a dynamic language fan, but considering Scala's > wildly complicated type system I have to agree with > Guido's assessment "...if this is what it takes to have > compile-time type-safety in a language, I'll take dynamic > typing any day." Scala is clean only in the academic > sense. > I don't think complexity is as simple as that. It is definitely true that Scala's type system is more complicated than that of Python, but in exchange certain kinds of refactoring can be simpler in Scala than Python, figuring out what types are being passed to a method can be simpler in Scala than Python, and so on. The complexity of Scala's type system is there to make programmers lives simpler when they are actually programming, just as the complexity of the engine of your car is there to make the lives of drivers simpler.
I'll give you an example. In the old days, to start a car you had to use a manual choke. And you had to take into account the temperature outside, how long the engine has been turned off to estimate how cold the engine is, and the phase of the moon frankly, to try and get the car to start. If you got this wrong in the direction of too much air it wouldn't start, but if you got it wrong in the other direction of too much fuel you could flood it, making it even harder to get it to start. Nowadays the starters that come with new cars are more sophisticated (or as you might put it, "wildly complicated"), but in exchange for that complexity starting a car is pretty darn easy. You turn the key and it starts. I've been amazed at how reliable this has become. I used to have a lot of trouble getting cars to start when I was a teenager, but now it just always works.
What's most difficult about starters today, given their complexity, is building them. Using one is easy. Similarly, what the complexity of Scala's type system really makes most difficult is writing a Scala compiler. This also makes it harder to create IDE plug-ins and other tools such as bug finders that need to analyze Scala source code. But it is possible, and everyday programmers don't write such tools, they just use them.
One way tbe complexity of Scala's type system may in fact add some complexity to your programming life, however, is if you're designing a library. This is something application programmers will indeed do from time to time, though often on a team there will be more experienced folks designing libraries and frameworks that the rest of the team uses. So this task will often fall to more experienced developers. But regardless, in the process of designing a library you may find yourself scratching your head over a tricky type problem. This is the process of figuring out what the types should be for your library. I can give two specific examples of type challenges from when I was desgining ScalaTest that I found tricky if you're interested. I had to think about these a bit, but I was able to solve them, and they make using ScalaTest quite easy.
And that ease of use of ScalaTest has been my general experience with Scala libraries. Writing code in Scala that uses libraries is quite easy. You do need to learn the language, and you'll need some level of understanding of its type system to use it, but it isn't out of reach of most programmers I've worked with. I think if someone can program in Java they can learn to program in Scala. The one place the complexity of the type system can rear its ugly head for these folks is if you get a compiler error message that is complaining about a type error. Most of the errors you get, though, are simple enough, pointing out a "typo" in a method call or what not. Sometimes they aren't obvious, such as when they complain about not being able to resolve an overloaded method call. But in my experience very rarely does understanding a compiler error message require a sophisticated understanding of the type system. Most of the time the problem is you spelled a method name wrong. Things like that.
I know quite a few people who have done some actual programming in Scala, and they all have complaints about Scala. But you almost never hear them complain about "the wild complexity" of Scala's type system. It just doesn't turn out to be a problem in practice. The problems are elsewhere.
In my Devoxx talk from last December, which just came out on Parleys today, I tried to show some ways in which Scala makes your life simpler. You can get to it from here:
> This also makes it harder to create IDE plug-ins and other > tools such as bug finders that need to analyze Scala > source code. But it is possible, and everyday programmers > don't write such tools, they just use them. Hasn't one of Java's big advantages been that it is easy to write such tools especially relative to C++? This means we now have tools for just about any useful purpose.
> His first bullet point is a bit of a stretch: > Simple, clean and full featured > Scala maybe satisfies full featured.. maybe.. but simple > and clean? Ahem. Scala will be simple only if his team > members all ignore its full-featuredness. Perhaps some > will, but some won't e.g., Ruby followers will write Ruby > looking code in Scala -- because they can. Scala is not > simple. >
I've never bought that argument. You can write non-simple, and non-clean code just as easily or even easier in Java because you have so much boiler-plate noise. That's why you have team leaders and code reviews.
> I'm not a dynamic language fan, but considering Scala's > wildly complicated type system I have to agree with > Guido's assessment "...if this is what it takes to have > compile-time type-safety in a language, I'll take dynamic > typing any day." Scala is clean only in the academic > sense.
I believe Scala does have structural subtyping (or static duck-typing) if you will. Yeah, you're going to have some more syntactic noise to get it, but you do get the benefits of static typing.
> > And how can anyone describe Scala as: > Accessible to the average developer, empowering to your > A players?? > The features that "empower" the A players are the exact > same ones that will totally alienate the average ones. The > dirty little secret is that they'll also alienate the A > players because the code can become incomprehensibly > clever.
You get your cowbody coders in Java too. If they're truly A developers, then they should be smart enough to write usable APIs.
> Speaking of learning curve, I hope the Eclipse plugin gets > better soon. “Quick Fix” is a must. As it is now, Quick > Fix doesn’t show any suggestions. The plugin also throws > some weird UI errors in error log. Figuring out errors on > your own, without IDE’s help, isn’t always easy.
Yeah, on nightly builds I'm still getting red squigglys on strings and other places that don't make sense. And I wish I could get an interactive console. Getting the same level of functionality as the Java support sounds pretty hard though, especially in a language like Scala.
> I've only used Scala a little bit, so take this with a > grain of salt. It seems like an intriguing language. > > But, if Scala were really designed to be migration > friendly from Java, they shouldn't have, apparently > deliberately, made the syntax so different. I'd prefer a > more "Java-like" syntax that still advances the language > design.
I've only played with Scala a bit, but from what I understand, the "un-Java" syntax is meant to enable extending the Scala language in Scala itself (the most prominent example being the Actors framework), like defining new "keywords", etc.
> > Speaking of learning curve, I hope the Eclipse plugin > gets > > better soon. “Quick Fix” is a must. As it is now, Quick > > Fix doesn’t show any suggestions. The plugin also > throws > > some weird UI errors in error log. Figuring out errors > on > > your own, without IDE’s help, isn’t always easy. > > Yeah, on nightly builds I'm still getting red squigglys on > strings and other places that don't make sense. And I > wish I could get an interactive console. Getting the same > level of functionality as the Java support sounds pretty > hard though, especially in a language like Scala.
Nowadays, IDE support is one of the greatest "barriers to entry" for new languages. IDE support for Java is so great, that it somewhat offsets the verbosity and need for boilerplate code.
IMHO, for a new language to succeed in the Java ecosystem, it needs great IDE support (both content assist and quick fixes), because eg. Java + Eclipse is more productive then Groovy + Vim
> Nowadays, IDE support is one of the greatest "barriers to > entry" for new languages. IDE support for Java is so > great, that it somewhat offsets the verbosity and need for > boilerplate code. > > IMHO, for a new language to succeed in the Java ecosystem, > it needs great IDE support (both content assist and > quick fixes), because eg. Java + Eclipse is more > productive then Groovy + Vim
I agree and something apparently many people don't understand. In theory, Scala can have just as good code completion, quick fix, refactoring support as Java. Groovy, Ruby, Python and other dynamic languages can't.
> Groovy, Ruby, Python and other dynamic languages can't.
I don’t know, that’s going too far. Squeak has code completion. I started learning Squeak recently and I found eCompletion, a tool for code completion. You can see screenshots here: http://uncomplex.net/ecompletion/index.html
Apparently it was Eclipse IDE that inspired it! You just type Ctrl + Space to get a popup menu for class names, method names, variables just like in Eclipse. It is more fun learning that way.
Flat View: This topic has 18 replies
on 2 pages
[
12
|
»
]
Previous Topic
