On Tue, Sep 15, 2009 at 1:06 PM, Dick Wall <dickw...@gmail.com> wrote:
> Firstly, perhaps folks out to go back and listen to the first 20 > minutes of episode 277. The emphasis of that discussion was in no way > bullying anyone from the pulpit, not negative in context, it was more > of a "hey, isn't this Lombok a clever way around the current obstacles > facing engineers that want to cut boilerplate in Java code". > It should be clear from my comments (comparing your job to Joe's) that I was responding to your email, not the podcast. > Somehow this got personal, and I assure it was not us that made it so. > In your email, you presume to tell Joe what his job is and how he's doing it incorrectly. The Coin changes weren't picked out of mid air with no regard for what users want. Many of the changes are backed up by exhaustive searches of huge code bases and objective measurements of how much the change would help (lines of code saved, reduction in errors, etc.). It doesn't take a compiler expert to do this work. It just takes time, time that you will take if you're passionate about a particular feature. I know because I did this legwork in a couple cases, and I am by no means a language expert. > Other threads in this group tell a larger story. Lombok does not seem > to be popular with some folks and they are very negative about it. > Who was negative about Lombok or at least the general approach? In his blog post, Joe rightly recommended generating a superclass or subclass instead of depending on internal javac APIs. The code generayion approach will work on other platforms, it will continue to work even if the javac internal APIs change, and it will be easier for users to debug. I'd hate to see someone combine multiple Lombok-style approaches in the same code and end up debugging javac's internal AST to figure out why their code doesn't work. > Returning to the comments about BGGA, I think the issue here is not > the closures themselves, but more that Neal put in a tremendous amount > of work and did everything by the book, and the result of the refusal > of closures has harmed the perception that putting in that much work > will make a difference. I already explained why I think closures didn't go forward. If you agree with my theory, there's no reason for BGGA to serve as a deterrent for others. Also, Java 7 isn't the end of the line. Just because a feature doesn't make it into 7 doesn't mean it will never make it in. Neal has also stated here and on other blogs > about this issue that he not only had a working prototype of the > exception multi-catch language change but also volunteered time to > complete it in isolation of closures, and that point has not been > addressed by anyone, either to explain why he was not taken up on the > offer, or to correct the record. If someone with the skills and energy > of Neal doesn't get his chance, is it any wonder people are looking > for more reliable ways to make a difference? > I don't know where multicatch stands. You'll have to ask Neal and Joe. If it's out, I'm sure there's a good reason. Bob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
