On 13 June 2011 22:23, Fabrizio Giudici <[email protected]>wrote:
> In response to Mario's point about the ROI of Scala, let me tell you a > short anecdotal story which expresses well my point. It's not about Scala, > but about people's _perception_ of what's effective, efficient, easy and > intuitive (E3I from now on). > > The past week I've run an exercise together with a customer, where we > designed a prototype of a webapp. The main purpose was to reduce the > evaluation uncertainty about the feasibility of some parts, in particular > the integration with an existing back end, and the uncertainty about what > should be really done. In fact, they asked for an estimate of the costs for > the whole app and I always refuse to make an estimate without spending a few > days to build a prototype. At the same time, I took the chance to introduce > a number of things into the prototype, from design practices, to a deeper > use of some technologies such as Spring - that the customer only used at a > minimum level - to the introduction of Maven. Extreme satisfaction of the > customer (and mine, as I had fun and was even get paid for that). > > For sure in this mailing list there will hardly be two persons with the > same opinion on my design decisions ;-) but I think that everybody gives > thumb up on a point: the app is made by several tiny classes, averaging > 10-20 LoC each, Single Responsibility Principle applied to full extent, > everything interchangeable and injected; tell don't ask and domain classes > without getter. Perhaps everybody agrees on the goodness of these points. > > The customer's code is usually made of very long classes, 500+ LoC and some > more than one thousand. He was already aware that this is evil, but needed > some exercising to understand how to get to a design process with better > metrics. He liked what was produced in this week. > > Still, the guy has got doubts that this style of design can be applied to > his developers. When I introduce the many-small-classes to people who's > accustomed to less-fat-classes, for instance, I note that they have troubles > to navigate the tree (for instance, to pick the proper class where to make a > change). The solution is, of course, to be picky and consistent with name > schemes. In turn, this requires training - and there's a personal attitude > thing, for which some people will find it natural at a certain point, others > not. I've seen code where people didn't refactor the method names when, > slowly, they started to do things that were different to the initial one - > and this operation only requires a ^R. So: that good design, in abstract, is > more effective than a design with longer classes. It's even easier for me, > but not for my customer, at least now. And since he doesn't feel at ease > with it, at the moment, he won't be more efficient with it. > Interestingly, this is one area where Scala would help both you and your customer. One early decision taken by the language was to abandon Java's "one class, one file" rule. Java's decision has some obvious logic, by naming directories after packages and files after classes, it becomes ridiculously easy to locate any given class Unfortunately, this can also lead to large monolithic classes as developers follow a natural tendency to keep related logic in one place. Time passed... We saw the Gang of Four and the rise of patternitis. Composition became favoured over inheritance, and there was an explosion of classes as software designs were decomposed according to these principles. It was an improvement, but it wasn't perfect; composition (and the lack of multiple inheritance) required a lot of delegation to be implemented over and over again, while it became harder to follow the logic of a design as it was now scattered over multiple classes. Perhaps the most vicious example of this in practice is the visitor pattern. IDE's came to the rescue, making it easy to find all given implementations of an interface. Ironically, IDEs also became the downfall of the very pattern they rose to help with - the argument for "one class, one file" is now _much_ weaker. With Scala, we can put multiple classes in a single file, once again logically grouping related functionality in the same place. Scala also goes beyond this. By using algebraic data types, sealed classes and pattern matching, many designs can be expressed more cleanly still. (I'm not parading pattern matching as a panacea for all that ails you here, there are times when it's the wrong choice, but it certainly leads to far more understandable and maintainable code in the vast majority of cases where a visitor would otherwise be considered) So you can have your cake (no pun intended) and eat it too. As a designer you get to choose a clean fine-grained composition, and your customer is spared a sprawling and hard-to-navigate codebase that would otherwise result from this approach. > I call this "karma" levels. A given karma, to my definition, is a set of > practices that you are acquainted to and you can master. A karma level n-1 > is made by practices that we can agree are better than ones at karma n; but > people used to karma n would find it difficult to work at karma n-1. For > instance, karma 5 could be use getters and setters (JavaBeans, JPA, etc..). > Karma 4 could be not to use them. You can't abruptly bring people used to > karma 5 to karma 4: they will panic. You can do with the proper pace and > training. I think that not all people can work at higher karma levels. After > all, everybody can learn to drive a small utility car, not everybody is able > to drive a F1 car. > This is a slippery slope. You've already had calls to define your karma levels objectively, soon the topic of certification will rear its ugly head - and we all know how useful that works out to be in practice. > So, you could convince me that Scala is at a higher karma than Java. We of > course agree that a number of people could be taught to work at a higher > karma - but this would require training. You might disagree, but I don't > think some people will find ever at ease at higher levels. Consider also the > motivational aspect: not everybody is passionate about his work. I know > people that code just for a living and leave at 8 hour of work o' clock. > They are marginally interested in working better, especially considering > that they feel they aren't below the average and that, in a war or another, > they get the job done. > > In this scenario, how can I have a ROI with Scala? > Higher productivity, more powerful test frameworks, and more maintainable code :) -- 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.
