Bloch torches BGGA at Javapolis
6 views
Skip to first unread message
Reinier Zwitserloot
Dec 14, 2007, 12:36:55 PM12/14/07
to The Java Posse
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.
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.
Message has been deleted
Casper Bang
Dec 14, 2007, 1:51:30 PM12/14/07
to The Java Posse
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
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
Jess Holle
Dec 14, 2007, 2:15:45 PM12/14/07
to java...@googlegroups.com
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 :-)
David Linsin
Dec 14, 2007, 3:37:40 PM12/14/07
to The Java Posse
Here's Neil Gafter's reply to the talk, which also contains the
pointers to Josh's presentation.
http://gafter.blogspot.com/2007/12/what-flavor-of-closures.html
regards, david
http://dlinsin.blogspot.com
pointers to Josh's presentation.
http://gafter.blogspot.com/2007/12/what-flavor-of-closures.html
regards, david
http://dlinsin.blogspot.com
Jesper de Jong
Dec 14, 2007, 4:15:05 PM12/14/07
to The Java Posse
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.
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.
Reinier Zwitserloot
Dec 14, 2007, 10:13:49 PM12/14/07
to The Java Posse
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:
foreach(someList) closure(x) {
System.out.println(x);
};
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.
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:
foreach(someList) closure(x) {
System.out.println(x);
};
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.
mgrev
Dec 15, 2007, 4:17:50 AM12/15/07
to The Java Posse
> voila. done. Now there's no need for the foreach construct at all;
It is those kinds of statements that scares the bejesus out of me.David Linsin
Dec 15, 2007, 4:20:12 AM12/15/07
to The Java Posse
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:
http://dlinsin.blogspot.com/2007/12/future-of-java-language.html
regards, david
http://dlinsin.blogspot.com
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:
http://dlinsin.blogspot.com/2007/12/future-of-java-language.html
regards, david
http://dlinsin.blogspot.com
Reinier Zwitserloot
Dec 15, 2007, 10:06:47 AM12/15/07
to The Java Posse
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();
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:
>
> http://dlinsin.blogspot.com/2007/12/future-of-java-language.html
>
> regards, davidhttp://dlinsin.blogspot.com
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);
T t = i.next();
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:
>
> http://dlinsin.blogspot.com/2007/12/future-of-java-language.html
>
TBT
Dec 15, 2007, 2:18:35 PM12/15/07
to The Java Posse
From reading the grease board, Java properties and the dot notation to
the properties got more No votes than Yes.
Too bad - I almost went and would have voted yes for both! Sorry Joe!
I also wanted to visit KULMINATOR.......mmmmmm beer. mmmmmm.
-Thomas
the properties got more No votes than Yes.
Too bad - I almost went and would have voted yes for both! Sorry Joe!
I also wanted to visit KULMINATOR.......mmmmmm beer. mmmmmm.
-Thomas
> 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:
>
> http://dlinsin.blogspot.com/2007/12/future-of-java-language.html
>
> regards, davidhttp://dlinsin.blogspot.com
> 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:
>
> http://dlinsin.blogspot.com/2007/12/future-of-java-language.html
>
Jess Holle
Dec 15, 2007, 6:07:17 PM12/15/07
to java...@googlegroups.com
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.> >From reading the grease board, Java properties and the dot notation to
> the properties got more No votes than Yes.
>
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...
Casper Bang
Dec 15, 2007, 9:15:34 PM12/15/07
to The Java Posse
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
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
> 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:
>
> http://dlinsin.blogspot.com/2007/12/future-of-java-language.html
>
> regards, davidhttp://dlinsin.blogspot.com
> 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:
>
> http://dlinsin.blogspot.com/2007/12/future-of-java-language.html
>
David Linsin
Dec 16, 2007, 4:09:25 AM12/16/07
to The Java Posse
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.
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.
brk
Dec 16, 2007, 5:36:34 AM12/16/07
to The Java Posse
+1 to that. Here's my take on it -
http://infinitescale.blogspot.com/2007/12/bgga-closures-end-of-many-java-careers.html
On Dec 15, 2:20 pm, 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:
>
> http://dlinsin.blogspot.com/2007/12/future-of-java-language.html
>
> regards, davidhttp://dlinsin.blogspot.com
http://infinitescale.blogspot.com/2007/12/bgga-closures-end-of-many-java-careers.html
On Dec 15, 2:20 pm, 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:
>
> http://dlinsin.blogspot.com/2007/12/future-of-java-language.html
>
Jess Holle
Dec 16, 2007, 1:32:36 PM12/16/07
to java...@googlegroups.com
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:
--
Jess Holle
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.]
- 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.
--
Jess Holle
hlovatt
Dec 16, 2007, 2:16:43 PM12/16/07
to The Java Posse
In:
http://www.artima.com/weblogs/viewpost.jsp?thread=182412
I suggest the syntax:
<methodName>.return value;
For non-local returns. This has the advantage of clarity and also
allows nesting more than one deep, which the current BGGA syntax
doesn't.
http://www.artima.com/weblogs/viewpost.jsp?thread=182412
I suggest the syntax:
<methodName>.return value;
For non-local returns. This has the advantage of clarity and also
allows nesting more than one deep, which the current BGGA syntax
doesn't.
Michael Neale
Dec 18, 2007, 1:18:05 AM12/18/07
to The Java Posse
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.
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.
Christian Catchpole
Dec 18, 2007, 1:39:35 AM12/18/07
to The Java Posse
Cool. Can I have your job then. :) And if Java's in that new car of
yours, just park it out the front. :)
yours, just park it out the front. :)
Peter Becker
Dec 18, 2007, 6:14:40 AM12/18/07
to java...@googlegroups.com
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
Seriously: I think a large percentage of Java's problems is due to the fact it never had time to grow up.
Peter
Alex
Dec 18, 2007, 7:34:38 AM12/18/07
to The Java Posse
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.
http://docs.google.com/Doc?id=ddhp95vd_0f7mcns
The authors are working on a prototype as well.
On Dec 16, 12:32 pm, Jess Holle <je...@ptc.com> wrote:
> * I /really/ like the idea of a function type system. In
> /suffice -- some better handling of throws clauses is still really
> needed, though.]
out the alternative FCM proposal (and optional JCA control abstraction
extension), which takes this idea as its core.
http://docs.google.com/Doc?id=ddhp95vd_0f7mcns
The authors are working on a prototype as well.
On Dec 16, 12:32 pm, Jess Holle <je...@ptc.com> wrote:
> * 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
> 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
> /suffice -- some better handling of throws clauses is still really
> needed, though.]
paulo
Dec 18, 2007, 2:46:22 PM12/18/07
to The Java Posse
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.
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.
Michael Neale
Dec 18, 2007, 6:44:18 PM12/18/07
to The Java Posse
Peter - you are so right.
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
>
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
>
Jess Holle
Dec 18, 2007, 7:25:52 PM12/18/07
to java...@googlegroups.com
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 :-)
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 :-)
Casper Bang
Dec 18, 2007, 7:44:10 PM12/18/07
to The Java Posse
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.
/Casper
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.
/Casper
Van Riper
Dec 18, 2007, 8:22:34 PM12/18/07
to java...@googlegroups.com
On 12/14/07, David Linsin <dli...@gmail.com> wrote:
>
> Here's Neil Gafter's reply to the talk, which also contains the
> pointers to Josh's presentation.
>
> http://gafter.blogspot.com/2007/12/what-flavor-of-closures.html
>
> Here's Neil Gafter's reply to the talk, which also contains the
> pointers to Josh's presentation.
>
> http://gafter.blogspot.com/2007/12/what-flavor-of-closures.html
Stephen Colebourne's recent blog entry adds FCM (First Class Methods)
to the mix for consideration too:
-Van
--
Mike "Van" Riper
van_...@dev.java.net
http://weblogs.java.net/blog/van_riper/
Silicon Valley Web Developer JUG
https://sv-web-jug.dev.java.net
Silicon Valley Google Technology User Group
http://groups.google.com/group/sv_gtug
Jess Holle
Dec 18, 2007, 8:37:55 PM12/18/07
to java...@googlegroups.com
Casper Bang wrote:
> 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.
>
Colebourne's FCM proposal certainly is a nice KISS approach compared to > 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.
>
other proposals in that area.
> 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.
>
forward. To erase every mistake ever made in the evolution of Java and
its libraries to date, yes, this would be necessary -- but restarting a
language every time you notice mistakes in it is practical only in
academia and ivory towers. To add truly important practical pieces to
the language I see no reason anyone has to force en masse
refactoring/porting or produce a layer to protect us from our own code
-- legacy or not much of it is working just fine. Rather one just has to
be careful and judicious in the design of new features and APIs to
ensure they dovetail with the existing language and APIs -- so we can
judiciously apply them to our code, new and legacy alike.
I'm suggesting steady and careful language evolution, preserving the
integrity of the community and its investment in the platform and
language. Perhaps that comes from many years working on large products
which have to keep working for decades -- while continuing to grow and
evolve steadily, not disruptively. You seem to be insisting on a
disruptive language coup d’état or schism -- violently splitting the
Java community between those ready to jump to a radically new vision and
refactor or box away all existing code and those who aren't or can't. I
don't see the point -- this would seem to only fracture and weaken the
community.
--
Jess Holle
David Linsin
Dec 19, 2007, 12:36:09 AM12/19/07
to The Java Posse
> 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.
I totally agree, because as Neil Gafter said on the latest Posse
> 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.
podcast: it's more important to read code, than write it!
On Dec 19, 1:25 am, Jess Holle <je...@ptc.com> wrote:
> 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
> 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
> 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
Reply all
Reply to author
Forward
0 new messages