all, That last email was meant for Reinier and Alex only. I apologize for whatever harm may have been caused.
iPhone user #fail Maybe they should make a "do you really want to send this to everyone?" annoying popup for folk like me. Sent from my iPhone On Aug 14, 2009, at 5:32 PM, Josh Suereth <[email protected]> wrote: > I'm not sure how others feel, but I think pretty soon this > conversation will be finished with any kind of technical merit and > turn into name-calling and one-uping. I usually reserve cuddle > pictures of kittens (Everyone Loves Kittens) just for this kind of > debate when it hits the Scala mailing lists. Being somewhat new to > this mailing list, I feel I possibly shouldn't do so, but I hope the > authors of these messsages feel sufficiently chastised! Please take > this debate offline (emailing each other). > > Reinier, I've had enough arguments with you that I know I should not > engage, but I do have to say that sometimes you need to tone down > your words so that people will listen to what you're saying rather > than take offense to what they hear. You do have lots of techinical > merit, and good ideas, but there's also a lot of emotion in the > emails. We all do that, we're passionate about our jobs. I'm > also one of those people that stopped following the COIN list when > <exageration>every other email showed Author: Reinier Zwitserloot</ > exageration>. You may be right, but sometimes gentle words turn > opinions better than declarations of truth. > > > - Josh > > "If the whole world is rallied against you, stop yelling at it" > > P.S. I also really really want to see ARM in java. Although I > have Scala available at work now, so perhaps I don't really care > anymore. This is also the reason I didn't immediately download > lombak and start using it. > > > On Fri, Aug 14, 2009 at 5:20 PM, Reinier Zwitserloot <[email protected] > > wrote: > > Hey, I have some lofty goals. I don't know if lombok can get there. I > sure hope so, though. > > The sheer amount of 'coin isn't making changes fast enough' sentiment > here and in the rest of the java community is -staggering-. But, apart > from that, if lombok gets some traction and adds a bunch of useful > features, but this one much touted feature that everyone wanted (let's > say, for argument's sake, closures) ends up blowing feet off left and > right, that'd be rather fruitful information for coin and any other > snoracle led java language improvement. Features which seemed only so- > so in coin and end up seeing a lot of use should similarly be very > useful information. > > it's already paid out for me; the sheer amount of clean code + bug > avoidance I've managed to create in my own projects by using @Cleanup, > which is pretty close to the ARM protocol that's spawned hundreds of > emails on the coindev list, is FAR greater than I originally thought. > I'm convinced that ARM is, by far, the most crucial thing on the > entire coin short list. I just didn't know that until I actually wrote > a bunch of real life code with a simple ARM tool at my disposal. I've > even designed APIs differently with the knowledge that resource > cleanup is now no longer an annoying hassle. > > What, exactly, was my mistake in regards to the relationship between > java and the JVM? Was it my statement that checked exceptions are a > figment of the javac compiler, similar to generics? Because I stand by > that statement. Or, was it my proposal that 'source' and 'encoding' > keywords become part of the language, which I also stand by, and which > I believe can be integrated into the JLS without any problems. We > could hold that discussion again, if you'd like. Calling them > 'sweeping and incorrect' is just wrong. They aren't. I've dropped the > discussion on coindev, because the sheer amount of, well, I'll have to > call it for what it is: *HATRED* against even daring to touch the > checked exception system meant I was never going to get anywhere in > that regard, and the source/encoding thing wasn't important enough for > me to start a long debate about why adding a source keyword does not, > in fact, require sweeping changes to the JLS. > > > I'm getting tired of your insults. In what way is 'central body that > picks known cases' laughable? Back up your statements, or stop > insulting me. > > NB: Lombok is hardly 'driven' by the annotation framework. It's a > tool. They are there, they fit the bill, I used it. If they hadn't > existed, lombok would still be here, it would just have used a > javaagent for javac as well, and, obviously, would have had to do a > little more work to hack keywords into the grammar. Annotations are > however _very_ useful and, like all the other java 1.5 features, full > of win. I don't think we should raise Joe's handling of project coin > to sainthood just because he's proven he can implement a lean and mean > annotation framework, though. If we take your thinking to its logical > conclusion, as we're all playing in a garden (java) provided by sun, > we should never question anything sun ever does with it, as we aren't > 'worthy'. That does not strike me as a productive idea. > > > On Aug 14, 7:26 pm, Alex Buckley <[email protected]> wrote: > > True, I should have said 'use an annotation to trigger the > rewriting'. > > That's my issue: you can only try out language features that are > > concerned with declarations, since that's all you can annotate. It's > > like being a sports car designer but insisting you can only work > with > > an automatic transmission - your product will be easy to drive but > > incredibly frustrating. > > > > Yes, prototyping is great. What you've implemented in Lombok is non- > > trivial. Getting the generated boilerplate 'just right' is > important. > > But you claimed your goals are much more: "A java.next for the > rest of > > us. Closures, more literals, probably extension methods and operator > > overloading, properties, lots of boilerplate elimination". The > > implication is that you can just hack up these features and blow > away > > the ponderous inscrutable design-led Coin project. Sun has long > > experience with features that look simple but have horrible edge > cases > > or deeply affect parts of the language one might characterize as > > 'tense' or 'brittle'. (Seehttp://bugs.sun.com/bugdatabase/ > view_bug.do?bug_id=6863462 > > for a recent discovery that manages to be impressive and > depressive at > > the same time.) Hence Coin concentrated on deep discussion of > > proposals, *especially* when the author claims it's really easy. The > > irony of your cynical sniping at Joe when Lombok is driven by his > > annotation processing framework is rather hard to bear. > > > > I will also comment that you have a propensity for making sweeping > > incorrect statements about the Java platform. A couple of weeks > ago it > > was the technical relationship of the Java language and the Java VM, > > and then Java compiler compliance with the JLS. Below it's the > > language evolution process itself. ("no > > central body that picks known cases with no issues and adds them to > > the language spec") Again, laughable. > > > > Alex > > > > On Aug 13, 7:34 pm, Reinier Zwitserloot <[email protected]> wrote: > > > > > > > > > Alex, you seem to misunderstand a thing or two about lombok and > APs. > > > The two obvious mistakes: > > > > > - An Annotation Processor that is registered to listener for > > > everything is called, both on initialization and for each class, > even > > > if there are no annotations anywhere in the entire source code > base. > > > You seem to think that they can't trigger unless there's an > annotation > > > someplace. This is incorrect. > > > > > - Lombok DOES in fact hack ecj directly. It just does so in a > fashion > > > which does not require you to change any files in your eclipse > > > installation, other than eclipse.ini. It has to for the reasons > you > > > stated: the AP API isn't even remotely close to complete enough to > > > serve as generic toolkit for IDEs; IDEs use all sorts of > optimization > > > tricks (case in point: eclipse doesn't parse method bodies when > it's > > > just rolling through a class to gather method signatures to e.g. > fill > > > an auto-complete dialog. But a generated getter method should > > > obviously be listed, so lombok has to run even for a source file > > > that's being "diet parsed" like that). > > > > > Onwards to the meat of your arguments: > > > > > I don't see how the issues with rewriting 'a == b' to an equals > call > > > are specific to lombok. Any programming language that wishes to > be so > > > close to familiar java syntax that you can get started right > away is > > > going to run into a problem if it wants to redefine the meaning of > > > code which, in java, has a perfectly valid but entirely different > > > meaning. > > > > > Annotations, -where they fit well-, have few disadvantages > (rather a > > > lot of at signs in your code, for one), and many advantages > > > (namespaced, and serve as a documentation pointer. Also by > definition > > > trivially grammar compatible, and backwards/migration compatible > as > > > well, at least as far as syntax is concerned). The things lombok > can > > > manage today all seem to be a great fit for annotations, even > @Cleanup > > > (lombok's variant on Automatic Resource Management), which when I > > > started out with project lombok wasn't something I thought would > work > > > with just an annotation. It's not for every feature (I don't > really > > > see how they'll be any help with a list comprehension or > closures, to > > > name a few), but where they are a good fit, I'll gladly take em. > > > > > As to your last paragraph, I presume that you did not intend to > piss > > > all over somebody's hard work to build a prototype and provide a > > > (mostly) convenient framework for others to experiment as well. > > > > > On Aug 13, 11:53 pm, Alex Buckley <[email protected]> wrote: > > > > > > On Aug 13, 2:03 pm, Reinier Zwitserloot <[email protected]> > wrote: > > > > > > > About project lombok, in reply to: > > > > > > > On Aug 13, 7:50 pm, Charles Oliver Nutter > <[email protected]> wrote: > > > > > > > > Project Lombok seems to be mostly a set of annotations for > common Java > > > > > > patterns, rather than a new language. What I'd like to see > is someone > > > > > > take javac, hack all the missing features into it, and > call it > > > > > > something new. > > > > > > > Annotations for now because they are nice and namespaced, > but there's > > > > > nothing in the lombok framework that _requires_ annotations. > lombok > > > > > could rewrite every instance of 'a == b' where both a and b > are > > > > > objects, to 'a == null ? b == null : a.equals(b)' if you > wanted it to. > > > > > > And then you wouldn't be able to use an annotation processor to > > > > trigger the rewriting. Charlie's point about hacking javac > wasn't that > > > > you should eschew IDEs and push people back to notepad. It was > that a > > > > language change is properly made in a compiler where the > grammar can > > > > be tweaked without limit and where the change benefits from > other > > > > parts of the compiler's pipeline, e.g. definite assignment > analysis. > > > > By implementing Lombok as an annotation processor, it's > constrained to > > > > a small part of the pipeline so has to reach out and basically > > > > vandalize the compiler's AST. Since both Eclipse and Netbeans > > > > ultimately call into ecj and javac directly, it would be much > better > > > > if you just hacked that ecj or javac instance directly. > > > > > > A related point is that your attacks on Coin (and Joe in > particular) > > > > are tiresome and offensive, and your shilling for Lombok as > the savior > > > > of the everyman Java programmer is laughable. > > > > > > Alex > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
