2008/12/28 James Iry <[email protected]> > > Believe me, I've tried and so have many others. We've tried > educating, pleading, belittling, you name it. He literally either > doesn't understand the issue or doesn't care. The challenge with Tony > is that he's usually right about matters of fact, but usually oh so > wrong in his manner of presenting it. So instead of fixing the > unfixable, the rest of us try to go around presenting a more reasoned, > less combative approach. >
I understand and thank you for your efforts. > > > The thing that makes me most > > uncomfortable is, that I've been looking at Scala over the last couple of > > years and I still find that I can't skim across code the way I can in > other > > languages. Perhaps a daily immersion in the language is required, perhaps > > I'm just not up to the job. > > Scala is definitely not a language that one can skim after merely > looking at it for awhile. Scala is something you need to get your > hands dirty with. But I find the same true of the more interesting > bits of Ruby and Python and Haskell and Scheme. And can you really > skim sophisticated usage of Java generics, or deeply nested inner > classes, or crazy patterns of break/continue? That's where I'd have to disagree with you a little. When I'm reading someone else's code (or even my own code I wrote a few months ago), I want to be able to understand at a glance what the author was trying to do. The code should scream out its intention - I think Ruby, Python, Scheme, Groovy, Smalltalk and Lisp are are excellent at this. Java isn't bad, but sometimes the boiler plate gets in the way. I rarely encounter archaic Java code with the potentially problematic constructs you mention because people generally know better than to write code like that these days (and I'm lucky enough to be in a position to re-educate where they do). I remember seeing truly grotesque Java a decade ago, but those days are thankfully gone. I guess at heart this is why Java took over from C++; you could have some hope of understanding other people's code. Everyone who's ever had to fix a production show-stopper bug in someone else's code whilst the original author is half way through a seven day assent of K2 knows the joy of readable code and the sorrow of obfuscated Perl. I read recently, (I'm afraid I can't provide a source, and even if I could the statistic may be one of the 87.2% of statistics that are made up on the spot) that in team environments 5 times as many hours are spent reading code as writing it. As I said, I've no idea if this is a real number, but it feels ball-park-right to me. A language that trully increases productivity, effectivness and efficiency is a language that provides the author with the tools to quickly write code that others may easily read. I think this is one of the reasons that Ruby caught people's imaginations after Rails garnered some publicity. Everyone could look at ActiveRecord code and say "hey, I know what that does and I don't know any Ruby". The theory that developers are writing code primarily for other developers to read, and the fact that it has to also satisfy the compiler, is one to which I heartily subscribe. So, in summary, an enterprise suitable language is one where, given an average group of diligent developers, the output of the team will not diminish over time because a language inherently leads to hard to understand code. I can't say if Scala meets my definition or not, I've never written Scala that has been consumed by anyone but me. I do know that going back to a piece of code six months later has led to some "OK, cool, that's what it does" moments and some "WTF was I thinking when I wrote this mess?" moments in equal measure. My core question: Will a team of average developers (some good, some great, some terrible, mostly .. average) have more long term success with Java, Scala or something else? Thanks, R. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
