I'm not at Javapolis but a friend is and he reports that Bloch held a
talk about BGGA and the very very confusing puzzlers that could result
from it. Perhaps not entirely fair, as puzzlers are generally rather
contrived. However, as Bloch is one of the two main contributors to
CICE, I wouldn't say the spirit of CICE is totally dead as Stephen
Colebourne suggests.
That's very circumstantial, perhaps we should wait for a bit more
substance before debating that. Puzzlers are plentiful in Java, any
new language construct is almost certain to introduce new ones -
nothing surprising about that.
/Casper
On Dec 14, 6:36 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> I'm not at Javapolis but a friend is and he reports that Bloch held a
> talk about BGGA and the very very confusing puzzlers that could result
> from it. Perhaps not entirely fair, as puzzlers are generally rather
> contrived. However, as Bloch is one of the two main contributors to
> CICE, I wouldn't say the spirit of CICE is totally dead as Stephen
> Colebourne suggests.
Though too many puzzlers is generally a sign of a complex feature, i.e. one with plenty of downside. The question in the end is whether the upside is bigger than the downside :-)
Casper Bang wrote: > That's very circumstantial, perhaps we should wait for a bit more > substance before debating that. Puzzlers are plentiful in Java, any > new language construct is almost certain to introduce new ones - > nothing surprising about that.
> /Casper
> On Dec 14, 6:36 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
>> I'm not at Javapolis but a friend is and he reports that Bloch held a >> talk about BGGA and the very very confusing puzzlers that could result >> from it. Perhaps not entirely fair, as puzzlers are generally rather >> contrived. However, as Bloch is one of the two main contributors to >> CICE, I wouldn't say the spirit of CICE is totally dead as Stephen >> Colebourne suggests.
> I'm not at Javapolis but a friend is and he reports that Bloch held a
> talk about BGGA and the very very confusing puzzlers that could result
> from it. Perhaps not entirely fair, as puzzlers are generally rather
> contrived. However, as Bloch is one of the two main contributors to
> CICE, I wouldn't say the spirit of CICE is totally dead as Stephen
> Colebourne suggests.
I was there too, at Josh Bloch's presentation. I have not followed the
closures proposal(s) closely, but I always assumed that closures would
probably be an interesting feature to have in Java. But that
presentation changed my mind. The "big guys" should be very careful
with what they add to the language. It looks like closures have the
potential to make Java a lot more complicated and confusing, and the
advantage of closures is questionable.
I was especially shocked by the utterly confusing and ugly non-local
returns. Is that feature really necessary?
I think it is not a good thing if this is added to Java, it will make
Java much too hard for the beginning and average programmer. Java
should remain a practical language, it should not morph into an
academic research language with obscure, overly complicated and
totally unnecessary features.
In my opinion, if this is what closures are going to do to Java, then
the advantages certainly don't weigh up to the disadvantages.
non-local returns are a crucially important feature if you want to use
closures to create your own language constructs.
BGGA is all about creating new language constructs - it isn't just
some sugar to more easily implement Runnables and ClickListeners
(that's more CICE territory).
I want non-local returns to be marked. something like return
somelabel: somevalue; (analogous to 'long breaks') or possibly
someMethodName.return someValue; (analogous to SomeClassName.this
notation).
Consider writing foreach using closures. In pseudocode.
we write:
public static <T> void foreach(Iterable<T> iterable, {T => void}
closure) {
Iterator<T> i = iterable.iterator();
while ( i.hasNext() ) {
T t = i.next();
closure.apply(t);
}
}
voila. done. Now there's no need for the foreach construct at all;
just import static this foreach method and you can do stuff like:
Great! However, let's now try this same trick to 'find' something in a
list. We want to loop through the list, and the first string that
contains the substring 'foo', we return. In other words, given
['xyzzy', 'quux', 'foobar', 'glorp'], we want foobar back. With the
java5 foreach construct:
for ( String x : someList ) if ( x.contains("foo") ) return x;
return null;
let's try this trick again with our closure version of foreach:
foreach(someList) closure(x) {
if ( x.contains("foo") ) return x;
}
return null;
whoops. Wrong. That won't compile; the closure is of type T=>void, in
other words, it doesn't return anything. The return statement,
assuming its a local return statement, is illegal. This is -really-
annoying, because it prevents a whole host of interesting DSL-like
language constructs you could have made with closures. Imagine for
example a closure solution to resource management - the idea that
instead of writing the convoluted:
FileInputStream in = null;
try {
in = new FileInputStream("someFile");
//do stuff with in
} finally {
if ( in != null ) try {
in.close();
} catch ( Throwable ignore ) {}
}
you could just write, using a closure:
File.readFile("someFile") closure(in) {
//in is a FileInputStream. Whatever we do, it gets closed.
};
great! Much cleaner!
However, without long returns, this code is limited; we can't actually
return anything out of it. We'd have to jump through the considerable
hoop of assigning the value to something defined outside the closure
first (which has the same problems as long returns if the closure gets
delayed), or throwing an exception just to early-escape out of the
closure block. In fact, we must go to the exception, because in the
previous example of the foreach loop, quitting when we find what we
were looking for is the idea.
And now you know what a 'long return' really is. it's syntactic sugar
for symmetric throw/catch blocks that allow transfer of data out of
the closure. A 'long return 10;' is really just throw new
EscapeFromClosure<Integer>(10); with, around the code statement that
contains the closure: try { /* statement */ } catch
( EscapeFromClosure<Integer> e) { return e.value; }
The problems with long returns are myriad, but, mostly, it totally
makes no sense if the closure is delayed or run in another thread, as
in what would happen with Timer.runLater(1000, someClosureToRunlater);
or with something like button.addClickListener(someClosure); or even
new Thread(someClosureAsRunnable).start(); unfortunately, java isn't
typed enough to know that a closure is being used in such a way that
it might be delayed. Therefore, generating a compile time error if you
try to long return in a closure which is not guaranteed to run
immediately isn't feasible. A runtime exception is in the cards, at
least.
I'm in favour of long returns as long as they are marked. It has to be
conscious decision and it has to be obvious when you look at it. Then
I'm fine with them.
Note that CICE can be adapted quite easily to work with long returns
(especially labelled long returns), though the current proposal
doesn't include it.
On Dec 14, 10:15 pm, Jesper de Jong <jes...@gmail.com> wrote:
> I was there too, at Josh Bloch's presentation. I have not followed the
> closures proposal(s) closely, but I always assumed that closures would
> probably be an interesting feature to have in Java. But that
> presentation changed my mind. The "big guys" should be very careful
> with what they add to the language. It looks like closures have the
> potential to make Java a lot more complicated and confusing, and the
> advantage of closures is questionable.
> I was especially shocked by the utterly confusing and ugly non-local
> returns. Is that feature really necessary?
> I think it is not a good thing if this is added to Java, it will make
> Java much too hard for the beginning and average programmer. Java
> should remain a practical language, it should not morph into an
> academic research language with obscure, overly complicated and
> totally unnecessary features.
> In my opinion, if this is what closures are going to do to Java, then
> the advantages certainly don't weigh up to the disadvantages.
Same for me! I totally agree that we should rather use another
language on top of the JVM instead of adding more "features" to Java.
Here's an image (not the best quality) of the whiteboards at
JavaPolis, which give you a rough idea of what part the community
think about the new features:
> I was there too, at Josh Bloch's presentation. I have not followed the
> closures proposal(s) closely, but I always assumed that closures would
> probably be an interesting feature to have in Java. But that
> presentation changed my mind. The "big guys" should be very careful
> with what they add to the language. It looks like closures have the
> potential to make Java a lot more complicated and confusing, and the
> advantage of closures is questionable.
> I was especially shocked by the utterly confusing and ugly non-local
> returns. Is that feature really necessary?
> I think it is not a good thing if this is added to Java, it will make
> Java much too hard for the beginning and average programmer. Java
> should remain a practical language, it should not morph into an
> academic research language with obscure, overly complicated and
> totally unnecessary features.
> In my opinion, if this is what closures are going to do to Java, then
> the advantages certainly don't weigh up to the disadvantages.
Just rereading my own code and I just realized that long returns
aren't quite that needed, if generics inference on closures is strong
enough. Here's a fun little (scary - but then, this isn't nearly as
scary as some of the generics constructs in the core code - this isn't
code your average joe needs to look at) signature (note that this
assumes Void becomes a legal entity as a generics type, and there's
even a singleton instance of it, which, if returned, is the same as
just 'return;':
public static <T,R> R foreach(Iterable<T> list, {T => R} closure) {
Iterator i = list.iterator();
while ( i.hasNext() ) {
T t = i.next();
R r = closure.apply(t);
if ( !(r instanceof Void) && r != null ) return r;
}
}
Hmm, but now you can't return null as that is used as a marker that
you don't wish to return anything. I'll have to think on this some
more.
On Dec 15, 10:20 am, David Linsin <dlin...@gmail.com> wrote:
> Same for me! I totally agree that we should rather use another
> language on top of the JVM instead of adding more "features" to Java.
> Here's an image (not the best quality) of the whiteboards at
> JavaPolis, which give you a rough idea of what part the community
> think about the new features:
> On Dec 14, 10:15 pm, Jesper de Jong <jes...@gmail.com> wrote:
> > I was there too, at Josh Bloch's presentation. I have not followed the
> > closures proposal(s) closely, but I always assumed that closures would
> > probably be an interesting feature to have in Java. But that
> > presentation changed my mind. The "big guys" should be very careful
> > with what they add to the language. It looks like closures have the
> > potential to make Java a lot more complicated and confusing, and the
> > advantage of closures is questionable.
> > I was especially shocked by the utterly confusing and ugly non-local
> > returns. Is that feature really necessary?
> > I think it is not a good thing if this is added to Java, it will make
> > Java much too hard for the beginning and average programmer. Java
> > should remain a practical language, it should not morph into an
> > academic research language with obscure, overly complicated and
> > totally unnecessary features.
> > In my opinion, if this is what closures are going to do to Java, then
> > the advantages certainly don't weigh up to the disadvantages.
> Same for me! I totally agree that we should rather use another
> language on top of the JVM instead of adding more "features" to Java.
> Here's an image (not the best quality) of the whiteboards at
> JavaPolis, which give you a rough idea of what part the community
> think about the new features:
> On Dec 14, 10:15 pm, Jesper de Jong <jes...@gmail.com> wrote:
> > I was there too, at Josh Bloch's presentation. I have not followed the
> > closures proposal(s) closely, but I always assumed that closures would
> > probably be an interesting feature to have in Java. But that
> > presentation changed my mind. The "big guys" should be very careful
> > with what they add to the language. It looks like closures have the
> > potential to make Java a lot more complicated and confusing, and the
> > advantage of closures is questionable.
> > I was especially shocked by the utterly confusing and ugly non-local
> > returns. Is that feature really necessary?
> > I think it is not a good thing if this is added to Java, it will make
> > Java much too hard for the beginning and average programmer. Java
> > should remain a practical language, it should not morph into an
> > academic research language with obscure, overly complicated and
> > totally unnecessary features.
> > In my opinion, if this is what closures are going to do to Java, then
> > the advantages certainly don't weigh up to the disadvantages.
TBT wrote: > >From reading the grease board, Java properties and the dot notation to > the properties got more No votes than Yes.
Dot notation for properties is patently insane as best I can tell.
If I have foo.a that has always meant a reference to the field "a" -- both inside foo's implementation and elsewhere.
Using dot notation for properties violates this long held understanding. Reading "foo.a" in the code suddenly means method calls (!) -- that's an abrupt and unkind change to all Java code readers alive today. Worse, use of dot notation necessitates some other nuanced mess to unambiguously say "hey, I really want to refer to the *field* 'a', not go through any getter or setter as I'm in the implementation of "foo" or in a helper in the same package or such.
I have no issue with a more formal notion of properties, but I believe they absolutely *must* use a new syntax if they're going to implicitly use getters and setters when present. I believe "->" is the best candidate of those I've seen.
> Too bad - I almost went and would have voted yes for both! Sorry Joe!
I can't see how anyone can support dot notation -- it is this sort of "oh gosh it is convenient in some case or another" (but causes horrific effects in all sorts of other cases I personally don't care about in my environment) feature that I sincerely hope Sun does not let into the Java language. Autoboxing/unboxing's about as close as I think we should get to this!
-- Jess Holle
P.S. I'm not even sure we need a "property" keyword. The compiler could take foo->a and construct a new bytecode that on runtime linking would look for the appropriate accessor and then look for an accessible field "a" -- it could even use JavaBeans info to do so when available. This grandfathers in everything and requires nothing more than -> and a special bytecode/linker bit. JavaBeans info is clunky, so you could add annotation support as well -- though I know some of the big-wigs say anything this important can't be done via annotations...
How sad to see properties being so low on the list. It's the most
obvious candidate to add to the language as any - Java's current
pseudo-properties is something that's used a *lot* so it should be in
the language, not formed by applying patterns and name mangling
schemes.
/Casper
On Dec 15, 10:20 am, David Linsin <dlin...@gmail.com> wrote:
> Same for me! I totally agree that we should rather use another
> language on top of the JVM instead of adding more "features" to Java.
> Here's an image (not the best quality) of the whiteboards at
> JavaPolis, which give you a rough idea of what part the community
> think about the new features:
> On Dec 14, 10:15 pm, Jesper de Jong <jes...@gmail.com> wrote:
> > I was there too, at Josh Bloch's presentation. I have not followed the
> > closures proposal(s) closely, but I always assumed that closures would
> > probably be an interesting feature to have in Java. But that
> > presentation changed my mind. The "big guys" should be very careful
> > with what they add to the language. It looks like closures have the
> > potential to make Java a lot more complicated and confusing, and the
> > advantage of closures is questionable.
> > I was especially shocked by the utterly confusing and ugly non-local
> > returns. Is that feature really necessary?
> > I think it is not a good thing if this is added to Java, it will make
> > Java much too hard for the beginning and average programmer. Java
> > should remain a practical language, it should not morph into an
> > academic research language with obscure, overly complicated and
> > totally unnecessary features.
> > In my opinion, if this is what closures are going to do to Java, then
> > the advantages certainly don't weigh up to the disadvantages.
I think if it should be added, then using a keyword. After all that's,
IMHO, what Java is all about: expensiveness. However, I know that it
adds more clutter to a language introducing more keywords, but it'll
make things more clear.
I do agree, that foo->a would be more appropriate than using the dot
notation.
On Dec 16, 12:07 am, Jess Holle <je...@ptc.com> wrote:
> TBT wrote:
> > >From reading the grease board, Java properties and the dot notation to
> > the properties got more No votes than Yes.
> Dot notation for properties is patently insane as best I can tell.
> If I have foo.a that has always meant a reference to the field "a" --
> both inside foo's implementation and elsewhere.
> Using dot notation for properties violates this long held
> understanding. Reading "foo.a" in the code suddenly means method calls
> (!) -- that's an abrupt and unkind change to all Java code readers alive
> today. Worse, use of dot notation necessitates some other nuanced mess
> to unambiguously say "hey, I really want to refer to the *field* 'a',
> not go through any getter or setter as I'm in the implementation of
> "foo" or in a helper in the same package or such.
> I have no issue with a more formal notion of properties, but I believe
> they absolutely *must* use a new syntax if they're going to implicitly
> use getters and setters when present. I believe "->" is the best
> candidate of those I've seen.> Too bad - I almost went and would have voted yes for both! Sorry Joe!
> I can't see how anyone can support dot notation -- it is this sort of
> "oh gosh it is convenient in some case or another" (but causes horrific
> effects in all sorts of other cases I personally don't care about in my
> environment) feature that I sincerely hope Sun does not let into the
> Java language. Autoboxing/unboxing's about as close as I think we
> should get to this!
> --
> Jess Holle
> P.S. I'm not even sure we need a "property" keyword. The compiler could
> take foo->a and construct a new bytecode that on runtime linking would
> look for the appropriate accessor and then look for an accessible field
> "a" -- it could even use JavaBeans info to do so when available. This
> grandfathers in everything and requires nothing more than -> and a
> special bytecode/linker bit. JavaBeans info is clunky, so you could add
> annotation support as well -- though I know some of the big-wigs say
> anything this important can't be done via annotations...
> Same for me! I totally agree that we should rather use another
> language on top of the JVM instead of adding more "features" to Java.
> Here's an image (not the best quality) of the whiteboards at
> JavaPolis, which give you a rough idea of what part the community
> think about the new features:
> On Dec 14, 10:15 pm, Jesper de Jong <jes...@gmail.com> wrote:
> > I was there too, at Josh Bloch's presentation. I have not followed the
> > closures proposal(s) closely, but I always assumed that closures would
> > probably be an interesting feature to have in Java. But that
> > presentation changed my mind. The "big guys" should be very careful
> > with what they add to the language. It looks like closures have the
> > potential to make Java a lot more complicated and confusing, and the
> > advantage of closures is questionable.
> > I was especially shocked by the utterly confusing and ugly non-local
> > returns. Is that feature really necessary?
> > I think it is not a good thing if this is added to Java, it will make
> > Java much too hard for the beginning and average programmer. Java
> > should remain a practical language, it should not morph into an
> > academic research language with obscure, overly complicated and
> > totally unnecessary features.
> > In my opinion, if this is what closures are going to do to Java, then
> > the advantages certainly don't weigh up to the disadvantages.
I finally got a long enough break to really dive into Josh's talk -- and re-reading the BGGA proposal right before it.
Overall, I'm very happy Josh is bird-dogging this.
After listening to Neil's talk on BGGA at JavaOne, I was pretty bullish about BGGA closures -- albeit without any experience trying to use them.
Now I have to say that there are a number of really onerous bits that stick out:
* Local return syntax in the middle of a non-trivial closure is extraordinarily inconsistent with inner class syntax, especially when combined with non-local returns. This reads like Ruby, not Java -- and that's a very bad thing in my book. [Let Ruby read like Ruby -- Java should read like Java.] Plus the entire "only one local return" bit is rather onerous. I'd rather see no non-local returns and require "return" for all returns! * The rat holes you can fall into with rules for BGGA seem endless -- you could sink down into a trying to correct one line of slightly miswritten code for an entire day. Folk complain about generic wildcards today (which I'm quite fine with), but these are kindergarten exercises when compared to grokking BGGA's fine points. * Having control invocation and loop abstractions that look so much like they're built-in seems extraordinarily likely to cause no end of confusion. Josh worries about "dialects" of Java. I worry that many, many developers won't even understand what's built in and what's not and what a "for xxxx( x, y : z ) { ... }" construct is doing -- when it is a simple built-in iteration and when they should look for some rocket-science closure stuff doing god-knows-what when they're troubleshooting stuff. * I /really/ like the idea of a function type system. In particular, I'd like to be able to produce a "method reference" from an object and its "int apple(double)" method and another such reference with an different object and its "int banana(double)" method -- and have them both be treated as {double =>int} method references divorced of their type and naming. I'm not convinced that one needs all the other baggage of BGGA to get this, though. [I just wish there was a version of the Method class that was decoupled from the defining class and the method name and a means to obtain one given an object and a Method. That would /almost /suffice -- some better handling of throws clauses is still really needed, though.]
As for ARM and CICE...
* I'm fine with CICE as far as it goes, but I'm not emphatic on saving keystrokes -- I have an IDE to insert method signatures, etc, and I prefer explicitness to questions from junior programmers of "what the @#$@# is going on here?". * ARM would be /really /nice to have.
Overall, I've beome convinced that closures need to be investigated at /much /greater length via /multiple/ prototypes (not just an "oh, we got BGGA working so let's do that") prior to inclusion in Java.
> non-local returns are a crucially important feature if you want to use
> closures to create your own language constructs.
> BGGA is all about creating new language constructs - it isn't just
> some sugar to more easily implement Runnables and ClickListeners
> (that's more CICE territory).
> I want non-local returns to be marked. something like return
> somelabel: somevalue; (analogous to 'long breaks') or possibly
> someMethodName.return someValue; (analogous to SomeClassName.this
> notation).
> Consider writing foreach using closures. In pseudocode.
> we write:
> public static <T> void foreach(Iterable<T> iterable, {T => void}
> closure) {
> Iterator<T> i = iterable.iterator();
> while ( i.hasNext() ) {
> T t = i.next();
> closure.apply(t);
> }
> }
> voila. done. Now there's no need for the foreach construct at all;
> just import static this foreach method and you can do stuff like:
> Great! However, let's now try this same trick to 'find' something in a
> list. We want to loop through the list, and the first string that
> contains the substring 'foo', we return. In other words, given
> ['xyzzy', 'quux', 'foobar', 'glorp'], we want foobar back. With the
> java5 foreach construct:
> for ( String x : someList ) if ( x.contains("foo") ) return x;
> return null;
> let's try this trick again with our closure version of foreach:
> whoops. Wrong. That won't compile; the closure is of type T=>void, in
> other words, it doesn't return anything. The return statement,
> assuming its a local return statement, is illegal. This is -really-
> annoying, because it prevents a whole host of interesting DSL-like
> language constructs you could have made with closures. Imagine for
> example a closure solution to resource management - the idea that
> instead of writing the convoluted:
> FileInputStream in = null;
> try {
> in = new FileInputStream("someFile");
> //do stuff with in} finally {
> if ( in != null ) try {
> in.close();
> } catch ( Throwable ignore ) {}
> }
> you could just write, using a closure:
> File.readFile("someFile") closure(in) {
> //in is a FileInputStream. Whatever we do, it gets closed.
> };
> great! Much cleaner!
> However, without long returns, this code is limited; we can't actually
> return anything out of it. We'd have to jump through the considerable
> hoop of assigning the value to something defined outside the closure
> first (which has the same problems as long returns if the closure gets
> delayed), or throwing an exception just to early-escape out of the
> closure block. In fact, we must go to the exception, because in the
> previous example of the foreach loop, quitting when we find what we
> were looking for is the idea.
> And now you know what a 'long return' really is. it's syntactic sugar
> for symmetric throw/catch blocks that allow transfer of data out of
> the closure. A 'long return 10;' is really just throw new
> EscapeFromClosure<Integer>(10); with, around the code statement that
> contains the closure: try { /* statement */ } catch
> ( EscapeFromClosure<Integer> e) { return e.value; }
> The problems with long returns are myriad, but, mostly, it totally
> makes no sense if the closure is delayed or run in another thread, as
> in what would happen with Timer.runLater(1000, someClosureToRunlater);
> or with something like button.addClickListener(someClosure); or even
> new Thread(someClosureAsRunnable).start(); unfortunately, java isn't
> typed enough to know that a closure is being used in such a way that
> it might be delayed. Therefore, generating a compile time error if you
> try to long return in a closure which is not guaranteed to run
> immediately isn't feasible. A runtime exception is in the cards, at
> least.
> I'm in favour of long returns as long as they are marked. It has to be
> conscious decision and it has to be obvious when you look at it. Then
> I'm fine with them.
> Note that CICE can be adapted quite easily to work with long returns
> (especially labelled long returns), though the current proposal
> doesn't include it.
> On Dec 14, 10:15 pm, Jesper de Jong <jes...@gmail.com> wrote:
> > I was there too, at Josh Bloch's presentation. I have not followed the
> > closures proposal(s) closely, but I always assumed that closures would
> > probably be an interesting feature to have in Java. But that
> > presentation changed my mind. The "big guys" should be very careful
> > with what they add to the language. It looks like closures have the
> > potential to make Java a lot more complicated and confusing, and the
> > advantage of closures is questionable.
> > I was especially shocked by the utterly confusing and ugly non-local
> > returns. Is that feature really necessary?
> > I think it is not a good thing if this is added to Java, it will make
> > Java much too hard for the beginning and average programmer. Java
> > should remain a practical language, it should not morph into an
> > academic research language with obscure, overly complicated and
> > totally unnecessary features.
> > In my opinion, if this is what closures are going to do to Java, then
> > the advantages certainly don't weigh up to the disadvantages.
Puzzlers are plentiful in any non childish language.
I find it very annoying that a book even exists.
I am just about to give up Java. We need a new VM language (which I
know people have been saying, but now I kind of realise is needed)
which tools vendors can focus on (everyone forgets about the tooling,
but tooling is nice !). With better language design. Lose the "J"
from "VM" and forget this horror ever happened.
On Dec 15, 5:51 am, Casper Bang <c...@brunata.dk> wrote:
> That's very circumstantial, perhaps we should wait for a bit more
> substance before debating that. Puzzlers are plentiful in Java, any
> new language construct is almost certain to introduce new ones -
> nothing surprising about that.
> /Casper
> On Dec 14, 6:36 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> > I'm not at Javapolis but a friend is and he reports that Bloch held a
> > talk about BGGA and the very very confusing puzzlers that could result
> > from it. Perhaps not entirely fair, as puzzlers are generally rather
> > contrived. However, as Bloch is one of the two main contributors to
> > CICE, I wouldn't say the spirit of CICE is totally dead as Stephen
> > Colebourne suggests.
> Puzzlers are plentiful in any non childish language.
> I find it very annoying that a book even exists.
> I am just about to give up Java. We need a new VM language (which I
> know people have been saying, but now I kind of realise is needed)
> which tools vendors can focus on (everyone forgets about the tooling,
> but tooling is nice !). With better language design. Lose the "J"
> from "VM" and forget this horror ever happened.
> On Dec 15, 5:51 am, Casper Bang <c...@brunata.dk> wrote:
> > That's very circumstantial, perhaps we should wait for a bit more
> > substance before debating that. Puzzlers are plentiful in Java, any
> > new language construct is almost certain to introduce new ones -
> > nothing surprising about that.
> > /Casper
> > On Dec 14, 6:36 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> > > I'm not at Javapolis but a friend is and he reports that Bloch held a
> > > talk about BGGA and the very very confusing puzzlers that could result
> > > from it. Perhaps not entirely fair, as puzzlers are generally rather
> > > contrived. However, as Bloch is one of the two main contributors to
> > > CICE, I wouldn't say the spirit of CICE is totally dead as Stephen
> > > Colebourne suggests.
> Puzzlers are plentiful in any non childish language.
> I find it very annoying that a book even exists.
> I am just about to give up Java. We need a new VM language (which I > know people have been saying, but now I kind of realise is needed) > which tools vendors can focus on (everyone forgets about the tooling, > but tooling is nice !). With better language design. Lose the "J" > from "VM" and forget this horror ever happened.
> On Dec 15, 5:51 am, Casper Bang <c...@brunata.dk> wrote: > > That's very circumstantial, perhaps we should wait for a bit more > > substance before debating that. Puzzlers are plentiful in Java, any > > new language construct is almost certain to introduce new ones - > > nothing surprising about that.
> > /Casper
> > On Dec 14, 6:36 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> > > I'm not at Javapolis but a friend is and he reports that Bloch held a > > > talk about BGGA and the very very confusing puzzlers that could result > > > from it. Perhaps not entirely fair, as puzzlers are generally rather > > > contrived. However, as Bloch is one of the two main contributors to > > > CICE, I wouldn't say the spirit of CICE is totally dead as Stephen > > > Colebourne suggests.
On your last point about the function type system, you should check
out the alternative FCM proposal (and optional JCA control abstraction
extension), which takes this idea as its core.
> * I /really/ like the idea of a function type system. In
> particular, I'd like to be able to produce a "method reference"
> from an object and its "int apple(double)" method and another such
> reference with an different object and its "int banana(double)"
> method -- and have them both be treated as {double =>int} method
> references divorced of their type and naming. I'm not convinced
> that one needs all the other baggage of BGGA to get this, though.
> [I just wish there was a version of the Method class that was
> decoupled from the defining class and the method name and a means
> to obtain one given an object and a Method. That would /almost
> /suffice -- some better handling of throws clauses is still really
> needed, though.]
I'm just a lowly posgraduate, not yet engineer, but what if instead of
closures we adopted a combination of method literals and python
generator expressions:
http://www.python.org/dev/peps/pep-0289/
Surely an implicit generator expresion like this:
sum(x*x for x in range(10))
is much, much cleaner that the stupidity of creating yet another block
level type {=> } thingie.
This combined with better generics would satisfy *everything* in my
mind, except maybe keeping a *reference* to the generator expression,
or returning it. That is just stupid in my mind so i don't mind. sure
it creates a need for a limited lookahead in the compiled. but so do
fucking what.
And its lazy by default, just requiring the creation of a *hidden*
yield construct (the whoopla about the role of return in the BGGA).
Only this return is *HIDDEN* like it should be.
I get tired of people explaining that java is the way it is by design,
and to keep it simple for the "80%" - the fact is it is mostly by
accident. Most of the features were intended to be added but Sun where
in a real hurry at the time.
Sorry if I sound bitter but I am getting tired of trying to improve
things. I don't know how people like Stephen Coulebourne have the
patience for this, my hat goes off to people like that.
As I am not an expert in languages, I should just shut up and let the
experts work it out, as long as they know there is "a problem" and "a
fix" is needed (either a new language, or growing the existing one and
living with the consequences).
I would like other non experts (read 99% of people to do the same) -
but experience has shown that silence equals compliance, which is not
what we want, and why we are starting to get heated now.
On Dec 18, 10:14 pm, "Peter Becker" <peter.becker...@gmail.com> wrote:
> Puzzlers are even more plentyful in childish languages ;-)
> Seriously: I think a large percentage of Java's problems is due to the fact
> it never had time to grow up.
> Peter
> On Dec 18, 2007 4:18 PM, Michael Neale <michael.ne...@gmail.com> wrote:
> > Puzzlers are plentiful in any non childish language.
> > I find it very annoying that a book even exists.
> > I am just about to give up Java. We need a new VM language (which I
> > know people have been saying, but now I kind of realise is needed)
> > which tools vendors can focus on (everyone forgets about the tooling,
> > but tooling is nice !). With better language design. Lose the "J"
> > from "VM" and forget this horror ever happened.
> > On Dec 15, 5:51 am, Casper Bang <c...@brunata.dk> wrote:
> > > That's very circumstantial, perhaps we should wait for a bit more
> > > substance before debating that. Puzzlers are plentiful in Java, any
> > > new language construct is almost certain to introduce new ones -
> > > nothing surprising about that.
> > > /Casper
> > > On Dec 14, 6:36 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> > > > I'm not at Javapolis but a friend is and he reports that Bloch held a
> > > > talk about BGGA and the very very confusing puzzlers that could result
> > > > from it. Perhaps not entirely fair, as puzzlers are generally rather
> > > > contrived. However, as Bloch is one of the two main contributors to
> > > > CICE, I wouldn't say the spirit of CICE is totally dead as Stephen
> > > > Colebourne suggests.
There are clearly different theories and goals for language evolution. Some time ago, I read Stroustrup's book on C++'s design and evolution with great interest. While I don't agree with all the decisions, I now understand his motivations. There are clear design goals and tradeoffs involved in any language's evolution and these dramatically shape the language over time.
Coming back to Java, Java could easily follow the "every nifty language feature someone feels would be nice now and then" course that C++ followed for a while and C# seems to be following now. On the other extreme Java could go the standard Pascal route and be so averse to evolution for the sake of simplicity that all real usages of the language are non-standard extensions.
For the sake of developer productivity and code maintainability, I hope and pray that the Java language designers find a middle ground between these extremes. I've had my fun spending hours trying to understand overtly convoluted C++ code replete with gratuitous operator overloading, overloaded templates, etc. It is clear C# can be /at least/ as convoluted as the worst C++ when all the latest features there are thrown together. I don't need that sort of mental exercise -- I've got real problems to solve that provide enough of that without the language making work for me. On the flip side, the Java language designers should continue to carefully graft in additional features whose benefits /decisively /outweigh their costs -- considering all costs in the process including difficulty/complexity of learning the language, bias of code towards/against clarity of meaning and operation and maintainability, bias towards good/bad coding patterns, etc. In particular, simplicity cannot be the sole design goal, but neither should simplicity be discarded without carefully considering whether the benefits of a change truly justify this.
-- Jess Holle
P.S. In terms of "I get tired", I get tired of those who write more code than they read (i.e. written by others) asking for features which would seem to have a clear proclivity to produce highly unclear (one might even say obfuscated) code in the hands of many developers :-)
> I get tired of people explaining that java is the way it is by design, > and to keep it simple for the "80%" - the fact is it is mostly by > accident. Most of the features were intended to be added but Sun where > in a real hurry at the time.
> Sorry if I sound bitter but I am getting tired of trying to improve > things. I don't know how people like Stephen Coulebourne have the > patience for this, my hat goes off to people like that.
> As I am not an expert in languages, I should just shut up and let the > experts work it out, as long as they know there is "a problem" and "a > fix" is needed (either a new language, or growing the existing one and > living with the consequences).
> I would like other non experts (read 99% of people to do the same) - > but experience has shown that silence equals compliance, which is not > what we want, and why we are starting to get heated now.
> On Dec 18, 10:14 pm, "Peter Becker" <peter.becker...@gmail.com> wrote:
>> Puzzlers are even more plentyful in childish languages ;-)
>> Seriously: I think a large percentage of Java's problems is due to the fact >> it never had time to grow up.
>> Peter
>> On Dec 18, 2007 4:18 PM, Michael Neale <michael.ne...@gmail.com> wrote:
>>> Puzzlers are plentiful in any non childish language.
>>> I find it very annoying that a book even exists.
>>> I am just about to give up Java. We need a new VM language (which I >>> know people have been saying, but now I kind of realise is needed) >>> which tools vendors can focus on (everyone forgets about the tooling, >>> but tooling is nice !). With better language design. Lose the "J" >>> from "VM" and forget this horror ever happened.
>>> On Dec 15, 5:51 am, Casper Bang <c...@brunata.dk> wrote:
>>>> That's very circumstantial, perhaps we should wait for a bit more >>>> substance before debating that. Puzzlers are plentiful in Java, any >>>> new language construct is almost certain to introduce new ones - >>>> nothing surprising about that.
>>>> /Casper
>>>> On Dec 14, 6:36 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
>>>>> I'm not at Javapolis but a friend is and he reports that Bloch held a >>>>> talk about BGGA and the very very confusing puzzlers that could result >>>>> from it. Perhaps not entirely fair, as puzzlers are generally rather >>>>> contrived. However, as Bloch is one of the two main contributors to >>>>> CICE, I wouldn't say the spirit of CICE is totally dead as Stephen >>>>> Colebourne suggests.
Well said Michael. I too am in admiration of Stephen Colebourne, a
true and rare KISS pragmatist within the hardcore Java community
throwing in time and money to improve things for the rest of us.
We would much rather see Sun grow Java in a healthy manner rather than
seeing it patched up time and again, in the illusion that Java is
superior solely because "it is everywhere in one form or another".
Saying that Java is superior because it works on all platforms is like
saying anal sex is nice because it works on all genders.
To quote a colleague of mine, "Sun invented Java, it's pretty obvious
it will also be Sun destroying it". This in reference to the fact that
Java is not truly open source, Sun is still in control but
unfortunately without a vision. Instead Sun is busy with a ton of
other things but the Java language and API. What we need is an
interoperability layer with legacy code or a strong refactoring/
porting tool, such that both the JVM and the language can evolve and
move the art forward.
|
