Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Do You Want BGGA Closures? Read this.
At 10:48 AM on Dec 14, 2007, Mikael Grev
wrote:
Fresh Jobs for Developers Post a job opportunity
If BGGA closures is to be added to Java, at least we need to add them with our eyes open. They are immensely powerful, but can be equally complex and bug prone. Java will not be the same, but that can be both good and bad.
Put yourself in the know of both sides and browse Joshua's slides here:
http://www.javac.info/bloch-closures-controversy.ppt
The BGGA proposal is here:
http://www.javac.info/closures-v05.html
Cheers,
Mikael Grev
191 replies so far (
Post your own)
Re: Do You Want BGGA Closures? Read this.
> The problem is that both> sides twist their examples to match exactly what they
Worse is language like "do we really want X?" which gives a naturally different response to "do we want X?". Consider:
Do we really want ice-cream?
Do we want ice-cream?
Only one 'side' uses that kind of emotive speech.
> If BGGA closures is to be added to Java, at least we
> need to add them with our eyes open. They are
> immensely powerful, but can be equally complex and
> bug prone.
All features can be bug prone if you use them without understanding them. switch without break, = in conditionals, i++ called for its result, etc. What specific bugs can BGGA cause? Note that at least one of Josh's examples of BGGA bugs is wrong. See if you can find it.
Complexity, again, there needs to be a concrete explanation of what is complex about BGGA. What do you find complex about it? Is there a precedent in a similar language to Java that doesn't have the complexity that you pick out?
Have fun,
Ricky.
Re: Do You Want BGGA Closures? Read this.
Jushua is right, why do people want Java to be Scala--?I love Scala, but Java's strength is that you see what you code instantly. That's why I still use it most times, but with that changing I might completely move to Scala..
Re: Do You Want BGGA Closures? Read this.
So, as I have read this, I get BGGA Closures in Java?Josh's slides are interesting but of course tainted. He shows carefully selected examples for presenting many cons but few pros. I agree with some of what he says, as any language change will have pros and cons (at least I know of no pro-only change). The most important to me seems the lack of documentation abilities for function types, but in many cases you don't need to document them. Recently, I created a number of dummy interfaces so I can pass callbacks around. They are named "UnaryFunction" or "BinaryProcedure", because I have to name them. Their only purpose is to take arguments of generically definable type and maybe return something. There is no further semantic, which is common in the calls of the method. One can compare it with having to give each iterator for a loop a name.
Linking Joshua's slides and the BGGA proposal does not make a fair comparison. You would need to link to Neal's talk on closures instead, which provides much more information on why they chose to propose closures the way they do.
Re: Do You Want BGGA Closures? Read this.
> Jushua is right, why do people want Java to be> Scala--?
Why does Scala exist, when it's got so much from Haskell? Shouldn't its users just use Haskell?
Why does Haskell exist, when it's got so much from theory provers? Shouldn't its users just use theory provers and generate code?
Why do theory provers exist, when they have got so much from mathematicians? Can't people afford their own personal mathematician?
There are advantages to staying within Java too, such as IDE support, not learning new stuff (this is actually an advantage in some circles!), not having to persuade non-technical management to let you change to another language, maturity, etc.
> I love Scala, but Java's strength is that you see
> what you code instantly.
Do you mean that it's explicit? Here's a few examples where Java isn't explicit:
String s="hello "+new World(); //implicit .toString() call and implicit StringBuilder use.
Integer i=127; //autoboxing
class X //extends Object
{ }
int i='c';
float f=16777217; //actually gets rounded to 16777216!
Some of these are good, some not. Being implicit isn't itself a bad thing, as long as the rules are straightforward.
> That's why I still use it
> most times, but with that changing I might completely
> move to Scala..
Scala's good, but I'm not sure it's ready for the COBOL crowd yet.
Re: Do You Want BGGA Closures? Read this.
> The most> important to me seems the lack of documentation
> abilities for function types, but in many cases you
> don't need to document them.
Where you need to document them you're better off writing an interface. It's like asking how to document an intermediate value, like the square root given in the following:
double x=sqrt(y)+a;
If you want a place to add docs, you name sqrt(y) using a temporary variable; the same goes for function types:
If {int => boolean} doesn't satisfy you, you can write interface Predicate extends {int => boolean} and now you have a place to write your comments.
Re: Do You Want BGGA Closures? Read this.
I'm pleased that Josh is still fighting his corner on this one. He is often very far sighted on issues of Java I find. Unfortunately the sense I have is that we are getting BGGA Closures whether we want them or not simply because of the sponsors – Gafter, Gossling et al. I hope I'm wrong on this because, whilst I concede that they are useful (as expertly illustrated by Neal Gafter's talk here http://www.infoq.com/news/2007/08/catching-up-with-closures) I think they add greatly to the complexity of the language in a way that is probably unhelpful.Re: Do You Want BGGA Closures? Read this.
> Where you need to document them you're better off> writing an interface.
Right. That's to write my comment in a short sentence
The problem some people see, is the misuse of features (e.g., why write an interface if I can use a function type?). But for writing bad code, everything is already in the language since it's first version
Clean up Generics first
My view is that Sun (or anyone else for that matter) doesn't get to add any more controversial features into the JDK until they clean up Generics. I am all in favor of type safety but Generics has made Java code much less readable.Shouldn't we clean this up before even considering closures which the community is clearly divided on? Shouldn't Neal and others be focusing more energy on a cleaned-up syntax for Generics? Please consider this seriously.
Re: Clean up Generics first
> My view is that Sun (or anyone else for that matter)> doesn't get to add any more controversial features
> into the JDK until they clean up Generics.
What specifically is the problem with generics? What would you suggest?
> I am all
> in favor of type safety but Generics has made Java
> code much less readable.
All Java code? It's made mine more readable, because the semantics are in the code rather than the runtime.
Re: Clean up Generics first
> What specifically is the problem with generics? What> would you suggest?
They work quite well for well-understood simple problems, such as Collections, but fail miserably for anything more complex. I've actually emailed Gilad Bracha once with some code I had added Generics to and to paraphrase his response he said "Generics aren't necessarily right for everything. In your case I'd say you'd be better off with the more readable type unsafe version". I had classes that take 5 type parameters. Consider having to type:
every single time you wanted to declare a new variable. It is totally unmanageable!
Here are some concrete criticisms I have:
1) Most people don't understand wildcards. class Enum is the simplest example of how unreadable they can get (and I've seen much worse). To make matters worse, when you screw up wildcards you get a horribly unreadable compiler errors.
2) Because Generics were implemented with erasure, quite often you have to play games with the compiler, forcing it to ignore warnings for situations you know can never occur.
3) Some people have asked for self-types because currently Generics makes it impossible to express type kinds of constraints.
There were many other problems I don't remember off the top of my mind but others can add to this list.
> All Java code? It's made mine more readable, because
> the semantics are in the code rather than the runtime.
I agree Generics works very well for simple use of Collections, but even that gets very ugly if you end up with nested generics such as:
Quite often I find myself (and others) omitting Generic parameters just to avoid the headache. Many JDK methods now return Class<?> yet how often do you see people bothering to do this? Frankly it is damn unreadable and doesn't add any value above "Class".
Anyway, I think getting rid of Generics "erasure" and introducing full-blown reification would go a long way towards more readable Generics code. I would love to hear more proposals from Neal and others as to how to improve the Generics syntax to make it more readable and intuitive to the lay-man. Joshua Bloch often speaks of "high power-to-weight ration" and I think he's quite right in his slides when he says that Generics wildcards fails to deliver on that front.
Type-safety *is* very important. I'm just saying that the power-to-weight of Generics-by-erasure makes it hard to justify its existence. I'm sure you could get the same type-safety with a much more readable syntax which would make a lot developers happier to use it. Just my 2 cents.
Re: Do You Want BGGA Closures? Read this.
Without even looking at Josh presentation, just reading the BGGA proposal, I am horrifiedNeil Gafter had a way better/simpler solution for closure! His "syntax sugar" solution is elegant and powerful. It also makes writing concurrent code a lot easier, ref. Java and Built-in Concurrency (Javalobby Post) .
What happened to his original proposal?
-- Javolution: Everything should be made as simple as possible... -- JScience: But not simpler!
Re: Clean up Generics first
Assuming you mean that basic generics are fine, but once you get into wildcards, they become too ugly. I completely agree, and I think it's great the Bloch uses that as an example of what Java needs to avoid.As a silver lining, people's views on closures probably match their views on generics. Those who don't mind generics wildcards probably don't mind BGGA closures. They want maximum power and don't care if it can get ugly, because *any* construct can get ugly. Those who cringe at generics wildcards also cringe at the BGGA proposal.
I'm in the second camp. Remember those memos that said "Thou shalt not use the following C++ features..." ? Closures may be the first such Java feature if BGGA passes.
Re: Do You Want BGGA Closures? Read this.
> Without even looking at Josh presentation, just> reading the BGGA proposal, I am horrified :(
You better not read Josh's presentation until tomorrow...one can only take so much horror in one day.
I find the BGGA proposal so distressing because I have such respect for Bracha, Gafter, Gosling, and von der Ahe. I'd hate to have to put them into the same category as Stroustrup in my brain. That's the "really smart and knowledgable, but having no clue as to what real-world programmers find difficult and ugly."
I've always believed that some people are just too smart to be programmers. Because they're so smart, nothing is difficult and so they write terribly ugly (to everyone but them) code.
So if you don't find generic wildcards ugly, and you don't find the BGGA proposal ugly, congratulations, you're smarter than the rest of us. Now please back away from the language-design whiteboard before someone gets hurt
Re: Clean up Generics first
> As a silver lining, people's views on closures> probably match their views on generics. Those who
> don't mind generics wildcards probably don't mind
> BGGA closures. They want maximum power and don't care
> if it can get ugly, because *any* construct can get
> ugly. Those who cringe at generics wildcards also
> cringe at the BGGA proposal.
So, your main problem with closures is, that the BGGA syntax is or can get ugly? So, maybe, I am in camp 1 of your definition, because I don't care that much about ugliness but usefulness. You can do ugly without Generics and Closures, it's not a matter of tools given but a matter of craftsman available.
If it's about ugly syntax only, but you'd like to see the abilities added to Java, think about some less ugly syntax. The BGGA proposal is a proposal not a manifest.