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 <reini...@gmail.com>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 <alex.buck...@sun.com> 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 <reini...@gmail.com> 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 <alex.buck...@sun.com> wrote:
> >
> > > > On Aug 13, 2:03 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> >
> > > > > About project lombok, in reply to:
> >
> > > > > On Aug 13, 7:50 pm, Charles Oliver Nutter <head...@gmail.com>
> 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 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
-~----------~----~----~----~------~----~------~--~---
