On 30 April 2010 13:55, Wildam Martin <[email protected]> wrote: > On Fri, Apr 30, 2010 at 13:56, Kevin Wright > <[email protected]> wrote: > > As for "Best Practices", they change! > > Of course they can, but I think as they mature they change less. > > > > Boilerplate in Java risks getting ever more burdensome as new > > features are added (like having to specify type params twice when > > instantiating a variable using generics) and Frameworks and developers > are > > increasingly saying ENOUGH! > > What is interesting: Although I found it annoying in C(++) to deal > with the header files nobody is complaining about that. And I never > even thought about a boilerplate-code issue before I was learning > Java. Then I noticed, yes, there is code I could consider to be > boilerplate also in my VB programs. I didn't ever notice that before. > OK, when I was doing COBOL and thought of writing english poems, that > was just a single thing of boilerplate. After that everything was just > short. :) > > Or, as I now think of it: Capitalization Of Boilerplate Oriented Language :) But more seriously, the essential vs accidental complexity argument really does have a great deal of merit, it's all to do with maintainability.
> > > Consider that the terms "Dependency Injection" > > or "IoC" were almost unheard of when Java was originally created, should > we > > therefore not use these patterns on the grounds that they're not > traditional > > idiomatic Java? > > No, we should not ignore such idioms or ideas. But as with many other > things, I hear everybody talking and writing about those things > although I think that a lot of those idioms (not necessarily the two > you mentioned above) make sense only in particular situations. As of > inversion of control I do see disadvantages also. None of these idioms > will fix the problem with the hunger in the world (I mean, none of > these idioms will solve everything without drawbacks at other ends). > > I would go even further: I would even say, that while discussing those > language features other maybe more important topics are not discussed. > For instance: Everything that has been there for WYSIWYG web > development in NetBeans has been withdrawn although such tools would > be more important. Last week two customers with new projects and guess > what: Part of the specification was that it must be implemented in MS > Access because non-programmers can then easily change forms or tables > if they need an additional field later and don't want us to contact > whenever that is necessary. - Even on Windows and VB I had a free tool > for form design that I could integrate with my applications and > customer IT was able to make smaller changes themselves without the > need being a programmer. - From the practical point of view: Who cares > of closures or whatever? My customers don't. They want things like > more tight integration with their OS for instance. I was so glad when > Java 6 introduced the system tray feature. Works fine on Windows and > Gnome as well (did not test it on KDE or Mac but imagine it works). > Now waiting for the file notification API in Java 7 but there is more > to do. Those things are IMHO much more important than reducing a > little boilerplate. I am sure that you all loose much more time by > trying to get some tricky things to work that touch limits of the Java > platform (if it is by using Ruby, Scala or Java). > > To be sure, customers don't care if you're using closures, or if you're using a language with a 100% semantic overhead due to boilerplate. but they do care if the time between updates is too long, or if updates are often accompanied by new bugs, caused by unnecessary duplication and boilerplate in the language which harms maintainability, and Java here really does have more than "a little" Case in point, what proportion of your java code now seems to be generated by your IDE? property getters/setters, equals, hashcode, etc.? All of that is just repetitive *fluff* that you're then forced to also update when performing a refactoring. Most IDEs will take care of all that for you, some will even refactor references in comments, spring config files, web.xml, etc. But it's still easy to overlook something crucial in that mound of spaghetti. Worse still, it's an absolute nightmare trying to read through such a file and piece together a mental model of the essential functionality. > And here it comes to my understanding of Joe's position when he put > the focus on the customers. > If the developer has to write a few more code has NO effect on the > customer. So the customer and the management can't care less about > that. On the other hand the possibility to write automated tests for > your application was a real gain because it reduces testing time and > costs by increasing reliability. And guess what: It needs even more > code to be written than before! > Or tools like Findbugs help increasing code quality - which means > reducing bugs and that has effect on the customer. > > Yes, it does have an effect. Maybe not at the time of writing, but the technical debt WILL catch up with you at some point in the future. If anything, tools like FindBugs become more effective as your codebase gets smaller with less boilerplate, and therefore less code to emit non-essential warnings about. It's very difficult knowing where to start if FindBugs throws over 200 "problems" back at you. > > > Books on best practices always risk being out of date the very moment they > are printed, > > and the real state of the art exists in blogs and mailing lists and the > > source code for the various frameworks we use. > > While I think you are right about the state of the art being found in > blogs - or forums like this ;-), I also think you are fairly > exaggerating when you assume most of books like "Effective Java" being > out-of-date as soon as available. > > I only said that some books risk being out of date, not that they're all guaranteed to! Interesting though, I think that those which pass the test of time are oriented more towards larger-scale design concepts, and less towards specific minutae of syntax. i.e. They're not so strongly tied to just the one programming language. The advice to favour immutable objects would fall into this category. > > > How much of "Effective Java" > > do you think will still remain a best practice once we have closures and > > method handles in Java 1.7? > > For that particular case I do already very seldom inline defining of > classes as I have only very seldom a class that isn't useful in either > 5 other places. I design my classes multi-use - that's a core idea of > object orientation, isn't it? So I do not really care about closures. > I would use them in rare conditions only, I think. > > This is what method handles are for :) Instead of having to define an entire class and implement an interface for the specific purpose of holding just one function you can pass a reference to the function directly. If anything this will REDUCE the need for creating anonymous classes to implement e.g. a swing event handler. This style of programming is both powerful and addictive. For example, allowing you to painlessly implement behaviour to be performed on each and every member of a collection, which I don't think is a rare thing to do! Google collections let you do this, but the code is pretty noisy due to the limitations of Java's syntax. > > > If it is to survive and prosper as a language, then it seems important > that > > Java should evolve as newer programming paradigms mature. > > Agree - as they _mature_! > Functional Programming is older than Java, surely it must be ripe by now? > -- > Martin Wildam > > -- > 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]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Kevin Wright mail/google talk: [email protected] wave: [email protected] skype: kev.lee.wright twitter: @thecoda -- 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.
