No, I didn't learn Scala just for that, it was simply the most concise example I could think of. In general, I've been following a trend of moving towards smaller lighter objects, using composition instead of inheritance, making less implementation private and instead favouring testability, etc... Scala was just another step along this axis, and taught me some additional tricks that I was able to port back into Java.
As for "Best Practices", they change! EJB v1 used to be a best practice. Then Spring came along and made everything more lightweight, then EJB3 and Guice - the trend here is pretty obvious. 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! 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? You only have to look at how google collections uses type inference via static factory methods to see how much nicer it's possible for things to be, or the way that Spring's db templates will convert the (checked) SqlException type to a more relevant runtime exception. 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. 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? When I conceive the design of a system, I first think at a higher level of what the various parts are and how they interact. Only later will I translate that design into the specific restrictions of my target language, using the language as necessary to fit my mental model. The goal is always to get as close as possible to clearly expressing the essential complexity inherent in the problem, and minimising the accidental complexity (boilerplate, etc) that the language introduces. If a newly documented design pattern or a concept learnt from another language helps me in this then I will use it, regardless of whether or not it was last year's best practice. If it is to survive and prosper as a language, then it seems important that Java should evolve as newer programming paradigms mature. And, yes, that almost certainly means deprecating ideas that were once advocated, as well as accepting some cross-fertilization from other languages. Even if the only reason to do this is to better take advantage of concurrency on processors that have ever-more cores then it's no bad thing. On 30 April 2010 12:10, Wildam Martin <[email protected]> wrote: > On Fri, Apr 30, 2010 at 12:12, Rakesh <[email protected]> wrote: > > The code written by these people is very strange to a Java-only dev > > and I don't think for the better. > > The risk of writing bad code is certainly higher when knowing a lot of > language just a little because you are more likely you mix best > practices from those languages. With the focus on one or few languages > you are more likely of writing better code - if it is simply because > of knowing more best practices and having more experience. - So no > wonder for me that you experienced that. > > I learned that when you learn a language you need to get a feeling > about several intentions of the language design and if you do much of > "language hopping", you might tend to mix things (up). > > > > A small example is the use of final everywhere. Is the code really > > better? Really? How did you cope before? Did you find lots of bugs > > that were due to not using final? > > I think while it may make a lot of sense applying ideas from other > languages where it fits new idioms should not be applied blindly. > WHERE IT FITS is the key here. - Apart from that depending on some > "philosophic viewpoints" code may look very different. > > Sample: There are people who find dealing with checked exceptions > simply boilerplate and always use unchecked/runtime exceptions. Others > have the religion of using checked exceptions and again others try to > avoid both by using good old return codes. - So even if you have only > developers how ever only did Java you might find totally different > code styles. - My opinion for this example is again, that it depends - > mostly also depending on the context. In one case if a file is not > found you might want to throw a runtime exception because that is a > major config file and in other cases you might want just to return a > "false" because the method was just examining a certain status. > > > > So, in summary, I think learning about other languages is ultimately > > good experience from a personal point of view but be very careful how > > it affects the code you write in other languages. > > Whatever language you are using you should not take care only about > syntax, but also about best practices and other "soft" parameters. > > > On Fri, Apr 30, 2010 at 12:38, Kevin Wright > <[email protected]> wrote: > > My Java style definitely changed since I learned Scala, and for the > > better. I can give one clear example. > > [...] > > Do you really needed to learn scala for that? This is plain valid Java. > You could either use just > public int x; > public String s; > - who cares? > > The thing is, that with getters and setters you have control over > "dependencies". > If just defining the above way you later don't have the option of > changing other internal object status if the user of the API changes x > for example. > > > Using getters/setters and making class instance variables private is > > an established Java idiom. I mean its in Effective Java (Item 14). > > The use of getters and setters is just a best practice - even if > defined by a man who should really know. But the nature of best > practices is also that they are suggestions and not rules - to not > apply them where it does not fit. But I guess, in this case, several > frameworks rely on the case that you use them, so it might become a > constraint. > -- > 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.
