Let's also not forget documentation. Code shouldn't exist in a vacuum. If a case can be made for writing some trickery that produces a valuable DSL library, or a proprietary best practice is identified, or a well-known idiom is broken to make a concession for some specific reason -- why not? So long as it's documented well and a new engineer can be pointed to the materials that accompany the source, is this really that much different than learning internal libraries anyway? Just be consistent, or if not, take the time to explain things that aren't obvious and need to be understood by your successors.
Striving to express everything about the world in a single programming paradigm is a fool's errand, IMO. Alexey 2001 Honda CBR600F4i (CCS) 2002 Suzuki Bandit 1200S 1992 Kawasaki EX500 http://azinger.blogspot.com http://bsheet.sourceforge.net http://wcollage.sourceforge.net ________________________________ From: Lyle <[email protected]> To: [email protected] Sent: Fri, April 30, 2010 11:31:03 AM Subject: Re: [The Java Posse] Re: Seven Languages in Seven Weeks On Fri, Apr 30, 2010 at 5:53 AM, Rakesh <[email protected]> wrote: > >Perhaps you are the only author of the code for all eternity then fine. > >However, if you write code in an environment where there are many >developers who may have to maintain your code then I think you are >doing them a dis-service. On Fri, Apr 30, 2010 at 7:55 AM, Wildam Martin <[email protected]> wrote: > >From the practical point of view: Who cares >>of closures or whatever? My customers don't. I think the argument for writing idiomatic Java for the sake of being comprehensible to developers who deal with it after you're gone is important. So is the fact that the end goal is to create something useful that the customer is happy with. Of course we shouldn't write overly tricky code which only we understand - that's just good development practice. Of course the customer doesn't really care about the intricacies of how we create their solution. But, somewhat selfishly, *I* care about making my life easier and making the code I have to live in every day more pleasant to work with. But that self-interest directly benefits the customer when I'm more productive because I'm actively interested in making my life easier and more fun. I'm not in this line of work because I happen to be passionate about whatever business app I'm writing at the moment - it's because I love code, and I think it's good to be open to new ways to make things quicker, easier, and ultimately more maintainable, even if that means not writing to the lowest common denominator. There are far more bad-to-mediocre programmers out there than there are proactive, interested ones who subscribe to mailing lists and listen to podcasts, and there will always be some cost associated with innovating - I've seen people write Java blissfully unaware that generics or for-each exists until somebody more proactive brings that stuff into the codebase. So I don't think it'll kill people to deal with a small amount of evolution. But let's not sacrifice a bit of process improvement for the sake of not shocking 9-5'ers. More to Rakesh's point, I think maybe that's why a lot of people are interested in moving to Scala et. al. Because while you can certainly write more functional Java and incorporate useful idioms from other languages (and if you want you can wait for the language to slowly evolve in a favorable direction), coding *is* a social activity and it's probably more productive to hang out in a social scene with like-minded people than to try to push too much change on people who aren't that interested. -Lyle -- 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. -- 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.
