I second that. Having never enjoyed the Posse as much as when engineering issues floats up to the top and they speak their mind from a technical perspective, for that truly represents the community I consider myself part of which is all about pushing state of the art.
It's not easy to cater to everyone, certainly I'm known to give them a hard time (which can come out brutally honest and hit harder than intended) but I reckon that's because we all care. It's down right refreshing to hear the Posse tackling controversial issues and if you look around, they really do appear to represent the community which is asking these tough questions independently. /Casper On 17 Sep., 14:44, hlovatt <howard.lov...@gmail.com> wrote: > Bob, > > I think you are being a bit hard on the Posse and Dick in particular. > They produce a podcast in there own time for little reward (OK the > occasional free Beer form Atlassian), surely they are allowed to > express their views - part of the entertainment is disagreeing with > them! > > Just a nit picking point - Sun does get some money from Java and they > have said in the past that they think it is valuable to the company > (they even went as far as to change their ticker). It therefore seems > to me likely that they have more resources than most to put into Java. > > Keep up the good work Posse, > > -- Howard. > > On Sep 15, 9:20 pm, Bob Lee <crazybob...@gmail.com> wrote: > > > Dick, > > > It really irks me to see you bully Joe from your pulpit like this. > > Comparing your job to his is comparing apples to oranges. I'm quite > > certain you wouldn't get paid to work on your *closed source* product > > if it didn't make a profit. The fact is, Sun doesn't profit from > > adding features to the Java programming language. You are not a paying > > customer. Sun is not a charity. Luckily for us, Sun open sourced Java > > so other companies can contribute, and other companies do. Google is > > actually behind 4 out of 7 of the proposals in project Coin. > > > It's also worth noting that Project Coin doesn't have a monopoly on > > language changes. It's just one JSR with the stated purpose of > > combining a small # of small language changes. If you don't like the > > way Project Coin is run, submit a separate JSR for your language > > change. > > > I personally wrote the Simplified Varargs Method Invocation proposal. > > What at first seemed like the simplest proposal (just moving some > > warnings around) turned out to be anything but. Compare: > > > Initial > > proposal:http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000217.html > > > > Followup:http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000316.html > > > The first proposal failed to account for edge cases like overriding a > > varargs method where the varargs have a non-reifiable component type > > with a method that takes an array with a reified component type. If > > unaddressed, these kinds of holes can easily result in a change doing > > more harm than good, a change that ultimately hurts Java instead of > > helping it. It's not enough just to consider the benefits of a change. > > You also have to consider the negative consequences. If we can't come > > up with a design where the benefits outweigh the drawbacks greatly > > enough, we just have to live without that feature until we come up > > with a better design. > > > Finally, I'm tired of hearing BGGA described as a perfect language > > change with no negative consequences. Sun did anything but ignore > > BGGA. In fact, three of the four letters in BGGA correspond to Sun > > employees. The main problem with BGGA, in my humble opinion, was that > > the final remaining author refused to consider a simpler proposal that > > didn't mandate custom control constructs. If he had, chances are good > > we'd have closures already. > > > I'm personally not fond of custom control constructs. To support them, > > you need non-local returns; I think non-local returns are a recipe for > > puzzlers. It also appeared as though BGGA had two separate custom > > control construct syntaxes that focused on two specific use cases (one > > of which is already addressed by a purpose-built construct). I didn't > > think BGGA did as good of a job as the purpose-built constructs, and > > it did even worse for a third construct I tried it against. While I'm > > generally supportive of closures, it's my personal opinion that Java > > has too much cruft already and we shouldn't complicate it further with > > custom control constructs. Simpler closures get us far enough. Of > > course, others vehemently disagree, but it doesn't matter what either > > of us think individually. The point is, we all share one language, and > > I don't think it's fair to add features to the language when there is > > so much disagreement. > > > Thanks, > > 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 -~----------~----~----~----~------~----~------~--~---
