On Tue, Sep 7, 2010 at 13:12, Glenn Bech <[email protected]> wrote: >>And no I don't see an overall business benefit for a large team moving to >>Scala from Java at this point. >>Given reasons previously stated you need to look at macro benefits not 'I am >>a developer and I like it' mentality. > > Amen! The best thing for producitivity is to stick in one technology, > get to know it well, and use it project after project. > I often see no, or little cost/benefit analysis when adopting new > frameworks or technology.
What is true for languages is true for framework stacks in a similar way, I would say: Switching or adopting something new it just takes a good while until you get really productive. I would say, for a programming language it is approximately a year - if you have much time. The last time for me it took even longer because only a slight transition was possible due to a lot of living projects that I also had to serve that were still written in VB. So learning Java for me took longer than when I learned VB because back then I had a lot less other legacy projects and I was still studying - so much more time for learning the new language. My experience tells me that before switching the benefits should be enough and for me it went quite good sticking with a language at least 5 years. That said, I sticked with Magic II about 6 years and with VB about 14 years. And those were the two languages I was most productive with. > I've never seen a team deliver value faster than on a stack of Struts > 1, Hibernate 3 and Jetty/Tomcat. I think that it only partly has to do with the particular stack chosen. Of course some stacks take less time to learn or are more flexible than others. On Tue, Sep 7, 2010 at 14:03, Kevin Wright <[email protected]> wrote: > The world is littered with stories of technologies that were ahead of > their time. Just look at the history of aviation, and how Frank > Whittle had to develop the jet engine despite a lack of military > funding. The people who could have helped found it impossible to > imagine that you could improve on something like the Spitfire. I think we need to distinguish between research and productive projects. I am working at a small company. Working for a year on learning a new language or stack and trying that on a new project would be critical for the whole company if the experiment fails. When I was still in school and at university (and of course did not have wife and family) things were different. I had more spare time and invested in trying different new stuff (and there were attempts hopping on real new stuff that completely failed). On Tue, Sep 7, 2010 at 15:34, Kevin Wright <[email protected]> wrote: > And therein lies the crux of the debate. :) > The problem is that Java is too verbose, laden with boilerplate, and poorly > suited to a natural expression of several concepts that we find incredibly > easy to think about. Don't tell me of "natural expression", when I don't find Scala very "natural" although l know a lot of languages so far. Don't see those concepts where it fits so well - not for my type applications. > One of these two examples is easier to comprehend: > //Java > List newList = new ArrayList<Integer> > for(Integer item : oldList) { > newList.add(item * 2) > } > //Scala > val newList = oldList map {_ * 2} 1. In your Scala sample I don't see what that type of items list contains or should contain. 2. Your example is a typical simple sample you would give when learning or teaching Scala. In realtime there would be more in the brackets part and hence make it less readable. 3. I only have to type "newo<tab>" and "fore<tab>" in NetBeans to get the java "boilerplate". So I not really have to type much to get the "verbosity" which I consider as information rather than boilerplate. 4. If I need such things more often I would write a function like this: public static ArrayList<Integer> multiplyListItems(List<Integer> oldList, int n) { ArrayList<Integer> newList = new ArrayList<Integer>(); for (Integer i : oldList) { newList.add(i*n); } return newList; } Which means, doing the multiplications then would also be a one-liner: List<Integer> newList = multiplyListItems(oldList, 2); One-Liner + clearly defined contents. For the case you come up with the argument that this is additional and Scala can it do out-of-the-box that short way: I don't know any programming language that offer even approximately the common stuff I need so anyway I have to create my common libraries containing all the stuff needed for my real work. Don't understand me wrong: It is nice to have an out-of-the-box way to do some things shorter - but you need to offer me more substancial advantages to make me switch. And for the case you do mention now the functional stuff - I can do this in Java too if I want but basically I don't like the functional coding so this is even no advantage for me. > The concept is "double every item in a list", and I believe the Scala > example comes far closer to expressing the underlying idea. > Java can do some of this, through google collections or lambdaJ, but neither > solution is as elegant as Scala's, or as easy to combine with other language > features. I didn't use any of those in the sample above. So why should I bother about google collections or lambdaJ if I can do it with plain Java? - I am not talking about the "idea" - I am talking about the _result_. > I want to create software that more closely matches how I'm thinking about > that software. That's a benefit, it makes it easier to write and, crucially, > much easier to read. This is just your opinion. Other people think different and don't share your opinion about readability. > Developers who come after me will be able to read what I *meant*, not what I > was forced to write so that I might satisfy the compiler. ROTFL! Why do you think that laws are written in so awful long texts? Because leaving too much room for *interpretation* mostly does not bring the intended result. It is already hard to read somebody else's code (that is why many people rather do a rewrite of a code instead of fixing the old code) - if you expect me to understand what you "meant", I just say: Be clear in what you code. This includes that you specify the intended content of your list for example. > I'll happily go to the extra effort of writing rich Scala APIs/DSLs, with > operator overloading, type classes, implicits, etc. If that means that code > using such a library them becomes easier to read/write/maintain. Have fun. I did C++ a long time ago at school and at university. I never needed operator overloads for example. What I would need is real good browser integration in Swing GUI for example. I hardly expect Scala offering me this. Or I would need an easier use of SOAP and REST webservices. Fortunately NetBeans already helps in generating stubs from wadl and wsdl - does Scala a better job here? My focus is practical results, so I am only interested in things that give me a boost there. > To me "just creating software" is about using tools that are as > natural-feeling as possible, not about struggling with > complicated/nonintuitive frameworks, regardless of how well I may have > memorised them. I fully agree with you that there are plenty of complicated and nonintuitive frameworks. But don't blame the core language for that. On Tue, Sep 7, 2010 at 18:20, Jan Goyvaerts <[email protected]> wrote: > Without thinking about somebody in particular - but I think it's sad so many > threads turn to waste these days... :-( I would not say, it is waste - I rather think that there are some boiling issues and many discussions somehow push the buttons to bring some controversial topics on the plate. I think, in general, developers have a hard time these days. On one hand you need to focus on the other hand you need to have an overview and there is so much overwhelming news that one has difficulties to sort out the irrelevant stuff and to navigate ones career. When I look back to my history, software development got only more complex through all these years. Without the tools (most important the IDE) getting better and better I would be completely lost (in the sense of having such a poor productivity that nobody would be that expensive stuff). On Tue, Sep 7, 2010 at 18:48, Kevin Wright <[email protected]> wrote: > Did I miss something? Did the discussion suddenly turn to project > management while I blinked, or to the issues of delivery and operations? I can't see that project management focus yet. > My understanding is that we were talking of the specific agile practice of > regularly learning a new programming language, the reasons to do so, the > problems with various programming languages, the benefits of specific > choices, and the solutions that they're able to offer. In my initial post I was mentioning a new programming language I read about in a news post just because I know that there are so many trying to learn a new language each year. I find this far from being productive and I already mentioned this a few times. So far nobody could convince me to a different opinion. So I was far from trying to discuss this again. > By all means, I'd be happy to discuss the wider picture of why I think a > highly maintainable language is relevant [...] Not sure what you mean with "highly maintainable language" but anyway, yes, there could be many fields of improvement to Java and other languages to get the one best-fit-for-all language - but IMHO we are still far away from the next big thing. > and how it all boosts shareholder value. To boost shareholder value often the most stupid things are done. I really don't want to participate with the "gamers". > There's another big picture that you're missing here. Namely that brevity > is not a goal, time spent typing is such a small portion of programming that > there's really no benefit in just reducing keystrokes. On the other hand, > comprehensibility and flexibility are very important - for all the reasons > stated above. If brevity goes hand in hand with these goals (and it does > seem to), then so be it! I agree with you - until the last sentence. I do not really think that brevity goes hand in hand with comprehensibility and flexibility. -- Martin Wildam http://www.google.com/profiles/mwildam -- 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.
