java.util.Optional<T> (Java 8)

1,902 views
Skip to first unread message

clay

unread,
Oct 23, 2012, 8:22:54 PM10/23/12
to java...@googlegroups.com
Has anyone seen java.util.Optional in the new Lambda builds?

Why is there no flatMap?

Why does it not support iteration (can't do a for loop over an Optional)?

Why doesn't it have Some/None subclasses?

Why does Scala and Functional Java get this right yet Guava and now the core Java guys completely ruin it?

Why doesn't Java 8 have persistent immutable collections?


Some of the JDK developers have real talent, but this is completely amateur.

I really hope they can fix this before it is set in stone. Tons of decent functional programmers can write a complete Option implementation easily as a fun exercise. It boggles my mind that they don't have the decent talent working on something so important.

Ricky Clarkson

unread,
Oct 23, 2012, 8:48:50 PM10/23/12
to java...@googlegroups.com
The closest to an answer I can find, a reply by Brian Goetz on lambda-dev:

Don't know the answer to any of these yet! But watch the repo as the
story plays out.

On Jul 27, 2012, at 1:15 AM, François Sarradin wrote:

> Hi,
>
> I have seen in one of the changesets that an Optional type is supposed
> to be available in Java 8. I have some questions about:
>
> * will the current implementation change later?
> * is it suppose to support a kind of flatMap operation?
> * will it be considered as an Iterable?
> --
> You received this message because you are subscribed to the Google Groups
> "Java Posse" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/javaposse/-/9H396Nyijw4J.
> To post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to
> javaposse+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.

Cédric Beust ♔

unread,
Oct 23, 2012, 9:04:55 PM10/23/12
to java...@googlegroups.com
There has been close to a centithread discussion on this topic on lambda-dev, maybe you should read it and then decide if the JDK devs are amateurs?

-- 
Cédric




Ricky Clarkson

unread,
Oct 23, 2012, 9:14:34 PM10/23/12
to java...@googlegroups.com
Can you point to it? I spent a while looking for it but I signed up
after it happened.

Cédric Beust ♔

unread,
Oct 23, 2012, 9:27:23 PM10/23/12
to java...@googlegroups.com
Look for Optional in this page, you'll find the two big discussions that happened last month (sorry for not being more specific but this listserv archive software was probably written in the late 90's).

-- 
Cédric

clay

unread,
Oct 24, 2012, 3:04:10 AM10/24/12
to java...@googlegroups.com, ced...@beust.com
I read every Option related message in the September archives

The primary debate is whether Option should or should not be added to the JDK.

We've heard that before and I respect both sides. I appreciate the elegance and high level abstraction and the ability to factor lots of common if/else logic out of regular code. On the con side, Java has a long history with using traditional null, and adding Option would be highly invasive and divisive. Also, the people that really apprecaite Option probably want to move to Scala anyway.

What I don't understand is why you would add Option and not do it right and omit for loop support and flatMap.

Several other people are asking for this exact same functionality. I don't see anyone offering a reason for not having for these features. Another person also suggests using Some/None subtypes the way every other Option is implemented and there is no response.

I read that map/flatMap are commonly requested features for Guava Optional, but the Guava team just dismisses the requests without apparent reason.

I'm sure the JDK devs have other areas of genuine expertise, but on this specific issue it really does seem like they are amateurs. The most wise commenters in the list were people asking the same questions as me and not getting a reply.

Christian Gruber

unread,
Oct 24, 2012, 8:57:08 AM10/24/12
to java...@googlegroups.com, ced...@beust.com
Actually, it's occasionally asked for, and the discussion is robust.  


Also, consider that Optional.asSet(), Iterables.transform(), Iterables.filter() are the guava idioms or what you're talking about.  No, they're not exactly like scala.  Yes, a LOT of churn happened internally and externally before arriving at this place.

The reasons and resulting API may not be to your preferences, but its not Optional<Rationale> nor even @Nullable Rationall r.  The reasons are present(). You just disagree.  And reasonable, professional adults can sometimes do that. 

Regards,
Christian
Sent from my iPhone.

clay

unread,
Oct 24, 2012, 1:02:20 PM10/24/12
to java...@googlegroups.com
The Guava teams reasons may be present(), but they are mostly hidden(), and secret(). The Guava team rep, Kevin Bourrillion, flat out said that they debated internally, and they are not explaining or open to further discussions, and sorry if you don't like it:

"Optional was the cause of possibly the single greatest conflagration on the internal Java libraries discussion lists ever.  Everyone, but everyone has a strong opinion on this thing.  I want to acknowledge the really awkward position it puts you all in to be presented with the result of all that churn without having the visibility into how it got that way.  Your fresh perspective on it is still beneficial, but often we're going to have to say... "sorry, we did think about this fully already, and decided against it" and I'm sorry if that's a drag."

And the limited reasons they did give are terrible:

"Implementing Iterable directly, so as to allow "for" loops directly over it, might just produce misleading code.  When I see a for loop, I expect it's because I'm, you know, looping.  "If present, get" is probably just a clearer idiom."

Option is a 0-1 collection and a for loop does "loop" over that 0-1 times. This is a terrible reason.

"One of the biggest misconceptions out there about Guava is that we are actually trying to make functional programming in Java awesome.  We have no such delusions, and aren't FP kool-aid-drinkers.  We have just added certain things as we have needed them.  But FP-like programming in Java will only become palatable in JDK 8,..."

So, the Guava guys have a derisive "don't drink the kool-aid" attitude towards functional programming. But, the Java guys are supposedly trying to make JDK 8 functional friendly, which is why it's problematic that the official JDK 8 Optiona implementation isn't adding flatMap or iteration support.

Sure, you can defend any bad design as a polite difference of opinion. First, I am offended because I care about Java and don't want the functional support in JDK 8 to be a joke that is rightfully snickered at. Secondly, the more objective measure I can point to is that people who want an Option class, but don't want flatMap + collection behavior and for iteration are in the minority. Of course, there are many who simply don't want Option at all, and that seems more reasonable; let the functional people go to Scala and keep Java as the more entry level language, like the way Microsoft added Option to F# but kept it out of C#. Even Microsoft added proper flatMap and iteration support to F# Option.

Ricky Clarkson

unread,
Oct 24, 2012, 1:12:57 PM10/24/12
to java...@googlegroups.com

Well, in any case, I can let you know that fj.data.Option will continue to work in Java 8 and that it will be lambda-friendly.  I am porting it to Java 8 in a branch (rickyclarkson/functionaljava branch java8 on github).

If you want to help, please make it buildable in sbt or make the tests buildable in maven.

When sbt hands the lambdaified Java sources to scalac, scalac barfs, and the option for skipping that step in sbt doesn't seem to do anything.  I haven't tried to get the tests building with maven yet.  I'm not sure whether to do that or port them from Scala to Java.

I'll also be (depending on what other FJ users say) looking at dropping some types/methods if the core implements them well enough.  A number of curried methods in FJ could be replaced with method references in Java 8, for instance.

The main difficulty is that FJ tends to use abstract classes instead of interfaces, and lambdas can only target interfaces.  This means breaking API changes unless they look at introducing static defender methods.

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/J3_hJuQGXPQJ.

clay

unread,
Oct 24, 2012, 1:37:10 PM10/24/12
to java...@googlegroups.com
It is important to have a good official standard JDK implementation, not a poor JDK version and a bunch of optional add-in third party replacements and support libraries.

Improving Functional Java is good and accessible to us mere programmers (fixing fj's weirdness about throwing Error rather than an Exception subclass would be nice), but it is distantly inferior to having a good JDK version. The community of people who care about this should do a better job of convincing the JDK people to do the right thing while this is still in development, before JDK 8 is set in stone.

Ricky Clarkson

unread,
Oct 24, 2012, 1:50:24 PM10/24/12
to java...@googlegroups.com
Error bothers me too, I'll discuss that with the others. Thanks for
mentioning it.
> https://groups.google.com/d/msg/javaposse/-/AVs8YepKaOoJ.

Simon Ochsenreither

unread,
Oct 24, 2012, 3:02:18 PM10/24/12
to java...@googlegroups.com

When sbt hands the lambdaified Java sources to scalac, scalac barfs, and the option for skipping that step in sbt doesn't seem to do anything.

scalac hasn't any support for Java 8 yet, but I think it would be great if you would file a bug (maybe even a testcase?!) if no such issue exists yet ...

Ricky Clarkson

unread,
Oct 24, 2012, 3:20:45 PM10/24/12
to java...@googlegroups.com
I will, but there's an upcoming syntax change to the defender methods,
so I'm probably going to wait for that. That's also going to break
IDEA I imagine, which up to now has worked remarkably well on lambdas.
> --
> You received this message because you are subscribed to the Google Groups
> "Java Posse" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/javaposse/-/dOLRKoiOXGgJ.

Simon Ochsenreither

unread,
Oct 24, 2012, 5:24:13 PM10/24/12
to java...@googlegroups.com
Which JDK8 version are you using? I downloaded the OpenJDK builds and neither Lambdas nor Defender methods seem to compile. Are they still not integrated into the main branch yet?

...

http://openjdk.java.net/projects/jdk8/milestones ... wow. 2013-01-31 ... Oracle really seems like a cozy place to work.

Ricky Clarkson

unread,
Oct 24, 2012, 5:38:32 PM10/24/12
to java...@googlegroups.com
They are in a separate branch that gets synced from the main branch
every so often. You can download the lambda-enabled binaries here:
http://jdk8.java.net/lambda/
> --
> You received this message because you are subscribed to the Google Groups
> "Java Posse" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/javaposse/-/k7lmkK4JrdoJ.

Mario Fusco

unread,
Oct 25, 2012, 5:52:09 AM10/25/12
to java...@googlegroups.com

Has anyone seen java.util.Optional in the new Lambda builds?

Yes.

Why is there no flatMap?

I asked it but received no meaningful answer.
 
Why does it not support iteration (can't do a for loop over an Optional)?

I asked it but received no meaningful answer. However I tried to do it by myself and it is a bit tricky because by making Option (maybe I am too used to Scala but I very dislike the Optional name) implementing Iterable you will have a clash with the map and flatMap methods defined there. Nothing undoable anyway.
 
Why doesn't it have Some/None subclasses?

I asked it but received no meaningful answer.
 
Why does Scala and Functional Java get this right yet Guava and now the core Java guys completely ruin it?

I asked it about Java (I am not a Guava user so I didn't check how it is implemented there) but received no meaningful answer.
 
Why doesn't Java 8 have persistent immutable collections?

I wasn't thinking about it because it is not directly related with the Option topic, but it is a very good question indeed.
 
Some of the JDK developers have real talent, but this is completely amateur.

I am sorry to say that I completely agree on that.
 
I really hope they can fix this before it is set in stone. Tons of decent functional programmers can write a complete Option implementation easily as a fun exercise. It boggles my mind that they don't have the decent talent working on something so important.

True. That is what I tried to do here http://java.dzone.com/articles/no-more-excuses-use-null for example.

Moreover I tried to reopen the discussion in October ( http://mail.openjdk.java.net/pipermail/lambda-dev/2012-October/006130.html ) but as I said I received no meaningful answers.

Mario

Simon Ochsenreither

unread,
Oct 25, 2012, 6:11:37 AM10/25/12
to java...@googlegroups.com
 
Some of the JDK developers have real talent, but this is completely amateur.

I am sorry to say that I completely agree on that.

Maybe they just enjoy badly reinventing existing stuff so much, that they want to repeat the glorious success of java.util.Logging?

Ricky Clarkson

unread,
Oct 25, 2012, 6:16:05 AM10/25/12
to java...@googlegroups.com

Calling someone's efforts amateurish isn't always the best way of persuading them to come round to your way of thinking.

Fabrizio Giudici

unread,
Oct 25, 2012, 6:26:35 AM10/25/12
to java...@googlegroups.com, Mario Fusco
On Thu, 25 Oct 2012 11:52:09 +0200, Mario Fusco <mario...@gmail.com>
wrote:

> ... I received no meaningful answers.

Honestly, this is annoying. There's no meaning in having lambdas if the
library support lacks fundamental features - I don't know about the JDK
developers, but I trust a number of people here about lambdas, so I'm
worried by their negative evaluation. I wonder whether we should plan for
searching satisfaction in an alternate, third party library for
collections - maybe Guava updated to JDK 8? I'm serious about that,
because if Guava will enjoy a satisfactory update for Java 8, I might put
it into my arsenal right now (so far I've just played with it a bit) and
could provide a reasonable transition path to JDK 8. I mean, if one is
used to Guava collection, I suppose there will be less effort in just
upgrade them for taking advantage of lambdas (I wrote Guava, but it could
be even something else, of course).


--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio...@tidalwave.it

Ricky Clarkson

unread,
Oct 25, 2012, 6:33:40 AM10/25/12
to java...@googlegroups.com, Mario Fusco

Guava has no flatMap, and there it's deliberate so less likely to change than in the core.

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.

Fabrizio Giudici

unread,
Oct 25, 2012, 6:39:51 AM10/25/12
to java...@googlegroups.com, Ricky Clarkson, Mario Fusco
On Thu, 25 Oct 2012 12:33:40 +0200, Ricky Clarkson
<ricky.c...@gmail.com> wrote:

> Guava has no flatMap, and there it's deliberate so less likely to change
> than in the core.

As I said, there could be something else...

Mario Fusco

unread,
Oct 25, 2012, 6:48:30 AM10/25/12
to java...@googlegroups.com, Ricky Clarkson, Mario Fusco

As I said, there could be something else...

Could be Guava or something else, but if Java 8 wants really do a step toward the functional world, I honestly don't see why such a fundamental (and let me say trivial) thing like an Option (and possibly an Either) shouldn't be available in the core Java.
As Clay wrote, it is not rocket science, really it isn't.

Mario Fusco

unread,
Oct 25, 2012, 6:56:26 AM10/25/12
to java...@googlegroups.com, Ricky Clarkson, Mario Fusco

As I said, there could be something else...

Could be Guava or something else, but if Java 8 wants really do a step toward the functional world, I honestly don't see why such a fundamental (and let me say trivial) thing like an Option (and possibly an Either) shouldn't be available in the core Java.
As Clay wrote, it is not rocket science, really it isn't.

Rethinking to what I just wrote, the situation is even worse at the moment.
It is not that we won't have an Option in the core Java, so we will have to rely on external library to have it.
In realty we have an Option that is completely wrongly designed and implemented, so we will need an external lib to have it right!

clay

unread,
Oct 25, 2012, 10:00:49 AM10/25/12
to java...@googlegroups.com, Ricky Clarkson, Mario Fusco
On Thursday, October 25, 2012 5:48:30 AM UTC-5, Mario Fusco wrote:
... if Java 8 wants really do a step toward the functional world, I honestly don't see why such a fundamental (and let me say trivial) thing like an Option (and possibly an Either) shouldn't be available in the core Java.

I can give one extremely good reason that Java shouldn't have Option:

Java is the JVM language that caters to those who demand more backward compatability and something more traditional and familiar, and has tons of legacy code and libraries already built around null, while those who demand more high level elegance and abstraction, such as Option, have Scala.

Microsoft does the same thing with .NET: F# is the language that caters to those that demand more high level elegance and abstraction, while C# is their more traditional language. Microsoft added Option to F#, and purposefully did not add it to C#.

If you take Option so seriously and are on the JVM, why not fully switch over to Scala?

Ricky Clarkson

unread,
Oct 25, 2012, 10:11:27 AM10/25/12
to clay, java...@googlegroups.com, Mario Fusco
I don't see that as a reason that holds water at all. If the feature
is good and useful in Java code, there's no reason not to use it in
Java code. Whether it's in the core isn't interesting at all, but if
there's a crippled version in the core that's a shame, as users of a
better version might end up always converting between Optional and
Option, or simply between Optional and Iterable, to get stuff done.

Not everyone who knows what Option is and wants to use it has a choice
over what language gets used. Consider developing a library for use
by Java developers, if you write that library in Scala the users will
see classes whose names end in $ even if you're quite conservative
about the Scala features you use.

Mario Fusco

unread,
Oct 25, 2012, 10:33:40 AM10/25/12
to java...@googlegroups.com, Ricky Clarkson, Mario Fusco
If you take Option so seriously and are on the JVM, why not fully switch over to Scala?

Let me reply to your question with another very simple question: how many people in this mailing list, and more in general which percentage of the developers in the world, are allowed to choose the language they like or that in their opinion fits better the peculiarities of the project they are working on? Personally I will consider myself lucky if I will be able to drop Java7 compatibility and develop only in Java8 in let's say 3 to 5 years from when Java8 will be officially out.

Anyway it is fine for me to not have Option in Java8. It means I will develop my own version and will use it in my projects. What I really cannot tolerate is a badly written version of it in the core Java libraries, that will stay there untouched forever only for backward compatibility reasons. Does java.util.Date remember you something?

Mario

Fabrizio Giudici

unread,
Oct 25, 2012, 10:58:01 AM10/25/12
to java...@googlegroups.com, Mario Fusco, Ricky Clarkson
On Thu, 25 Oct 2012 16:33:40 +0200, Mario Fusco <mario...@gmail.com>
wrote:

>
>>
My additional points:

1. The F# strategy is excellent and if I had to decide, Java would never
see lambdas. In my point of view, Java 8 could just introduce a simplified
syntax for inner classes (it was called the CICE proposal if I'm not
wrong). Given that Sun/Oracle decided differently, and I'll have anyway to
pay the extra complexity of the language, let me please enjoy the new
features for full.

2. Option is not a Scala thing, is a micro-design pattern. I could like it
or not, but being a pattern I think I shouldn't see it at all, or see in
all the languages I like.

Essentially, I agree ony the importance of backward compatibility and
that, given that Java has/had nulls, it is doomed to have them forever.
But isn't Option just adding a new possibility? I don't see how it could
break compatibility. Certainly having two different way of dealing with
things, null and Option, is not elegant, and is another reason for which I
was conservative on Java evolution. But the lack of elegance was clearly a
ticket to pay for having lambdas... So with Java 8 I want that it's
possible to write "old style" code, as well as functional code.

clay

unread,
Oct 25, 2012, 12:21:50 PM10/25/12
to java...@googlegroups.com, Mario Fusco, Ricky Clarkson
"Not everyone [...] has a choice over what language gets used."

If people can't make ideal technical choices for political reasons, then that is a political problem rather than a technical one.

I can't fault programmers who try to "sneak" useful or stimulating technologies around the stifling confines of their employment situation. However, accommodating this type of "sneaking" shouldn't be a first class design consideration for the Java platform.

"What I really cannot tolerate is a badly written version of it in the core Java libraries, that will stay there untouched forever only for backward compatibility reasons. Does java.util.Date remember you something?"

I completely agree with this.

"If the feature is good and useful in Java code, there's no reason not to use it in Java code."

Generally good features should be added to Java. The two major caveats are:

- Divisive issues: Some love it, some hate it. Option and flatMap are extremely divisive.
- Legacy Impact: Some features are easy to ignore if you don't like or care about. Option is particularly invasive across a code base. I prefer Option, even in Java, but I can understand some of the resistance to it.

Persistent immutable collections should be an ideal addition because they are extremely valuable, they are not divisive (no one seriously objects to them), and they don't have any real legacy problems. There are a bunch of third party implementations, but there is a big opportunity for something much better. If I had the time, this would be a fun side project.

"Option is not a Scala thing, [it] is a micro-design pattern"

Today, JVM programmers are  highly divided. It's not a perfect summary, but I would broadly categorize into two groups: those that want all the Scala features and those that want to stick with a simpler Java-like language. Option is a good marker at signaling which camp a programmer falls into, but obviously Scala didn't invent or "own" the Option pattern.


I retract what I said about Some/None sublasses. In Scala that works with the match construct, but since Java doesn't have such a construct, it isn't important, and the Java implementation should focus on whichever is most efficient in terms of memory overhead and runtime speed.

Cédric Beust ♔

unread,
Oct 25, 2012, 12:43:15 PM10/25/12
to java...@googlegroups.com, Mario Fusco, Ricky Clarkson

On Thu, Oct 25, 2012 at 9:21 AM, clay <clayt...@gmail.com> wrote:
Today, JVM programmers are  highly divided.

I'm not sure about that. Sure, if you read this mailing-list and you go to conferences, it's very easy to get this impression because the community you belong to is, by definition, made of seekers and curious professionals who live on the bleeding edge of their profession. It's a text book example of sample bias.

Step outside of this community and ask random Java developers what they think of JVM languages besides Java and most of them have hardly heard of Scala, much less taken a look at it. I bet they will also think that Java is a great language and much more fun to work in than C++ was, which is all they care about (and honestly, I can't blame anyone with this line of thought).

-- 
Cédric

Ricky Clarkson

unread,
Oct 25, 2012, 1:01:24 PM10/25/12
to Cédric Beust ♔, java...@googlegroups.com, Mario Fusco
I have 'inflicted' Option on these people and not had any real problems.

Cédric Beust ♔

unread,
Oct 25, 2012, 1:27:12 PM10/25/12
to Ricky Clarkson, java...@googlegroups.com, Mario Fusco
Sure, but that was not my point...

-- 
Cédric

Ricky Clarkson

unread,
Oct 25, 2012, 1:28:49 PM10/25/12
to Cédric Beust ♔, java...@googlegroups.com, Mario Fusco
That's ok, I wasn't making any counterpoint.

Cédric Beust ♔

unread,
Oct 25, 2012, 2:01:34 PM10/25/12
to Ricky Clarkson, java...@googlegroups.com, Mario Fusco
We need to stop not fighting, it's boring.

-- 
Cédric

Fabrizio Giudici

unread,
Oct 25, 2012, 2:15:17 PM10/25/12
to java...@googlegroups.com, clay, Mario Fusco, Ricky Clarkson
On Thu, 25 Oct 2012 18:21:50 +0200, clay <clayt...@gmail.com> wrote:

> "Option is not a Scala thing, [it] is a micro-design pattern"
>
> Today, JVM programmers are highly divided. It's not a perfect summary,
> but
> I would broadly categorize into two groups: those that want all the Scala
> features and those that want to stick with a simpler Java-like language.
> Option is a good marker at signaling which camp a programmer falls into,
> but obviously Scala didn't invent or "own" the Option pattern.

I think I'm not fully understanding this. For the record, I'm definitely
not a Scala fan, and I definitely don't want all the Scala features in
Java, but I'd like to be able to use Option with the least effort.

Josh Berry

unread,
Oct 25, 2012, 2:28:49 PM10/25/12
to java...@googlegroups.com
On Thu, Oct 25, 2012 at 10:58 AM, Fabrizio Giudici
<Fabrizio...@tidalwave.it> wrote:
> 2. Option is not a Scala thing, is a micro-design pattern. I could like it
> or not, but being a pattern I think I shouldn't see it at all, or see in all
> the languages I like.

I think this is a key misunderstanding. One I mostly share. Option
is not a micro design pattern any more than String is. It is a common
type that is shared in many languages. Same as List or Map. Maybe
I'm placing more distinction on this than is necessary, but it is
important. Can you imagine working with a language where String was
implemented vastly differently than the way it is commonly done? (But
still called String.)

Fabrizio Giudici

unread,
Oct 25, 2012, 2:33:25 PM10/25/12
to java...@googlegroups.com, Josh Berry
On Thu, 25 Oct 2012 20:28:49 +0200, Josh Berry <tae...@gmail.com> wrote:

> On Thu, Oct 25, 2012 at 10:58 AM, Fabrizio Giudici
> <Fabrizio...@tidalwave.it> wrote:
>> 2. Option is not a Scala thing, is a micro-design pattern. I could like
>> it
>> or not, but being a pattern I think I shouldn't see it at all, or see
>> in all
>> the languages I like.
>
> I think this is a key misunderstanding. One I mostly share. Option
> is not a micro design pattern any more than String is. It is a common
> type that is shared in many languages. Same as List or Map. Maybe
> I'm placing more distinction on this than is necessary, but it is
> important.

It's a type, but you can't compare it to a String. String is a type born
to model a certain kind of stuff. Sure I can't imagine a different,
practical way to represent text. Option is a type born to support some
constructs, such as avoiding null.

> Can you imagine working with a language where String was
> implemented vastly differently than the way it is commonly done? (But
> still called String.)

Of course, I however agree with this statement, Option is well defined
from a conceptual point of view and should be the same thing everywhere.

Ricky Clarkson

unread,
Oct 25, 2012, 2:59:21 PM10/25/12
to java...@googlegroups.com, Josh Berry
> Option is a type born to support some constructs,
> such as avoiding null.

That's just as correct as saying that array is a type born to support
some constructs, such as avoiding declaring 10 variables. I.e., it's
not correct.

Both Option.none and null can be used to denote that an item is not
present, but so can having an empty string, an empty list, the text
"undefined" and all sorts of other approaches, some of which might
make sense given a scenario, but that doesn't mean Option is like null
any more than null is like "", or null is like 0, -1, false,
"unknown", NaN, etc.
> --
> You received this message because you are subscribed to the Google Groups
> "Java Posse" group.
> To post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to
> javaposse+...@googlegroups.com.

Roland Tepp

unread,
Oct 25, 2012, 3:01:14 PM10/25/12
to java...@googlegroups.com, Ricky Clarkson, Mario Fusco
This is not an answer. It is avoiding an answer.

Fabrizio Giudici

unread,
Oct 25, 2012, 3:04:13 PM10/25/12
to java...@googlegroups.com, Ricky Clarkson, Josh Berry
On Thu, 25 Oct 2012 20:59:21 +0200, Ricky Clarkson
<ricky.c...@gmail.com> wrote:

>> Option is a type born to support some constructs,
>> such as avoiding null.
>
> That's just as correct as saying that array is a type born to support
> some constructs, such as avoiding declaring 10 variables. I.e., it's
> not correct.
>
> Both Option.none and null can be used to denote that an item is not
> present, but so can having an empty string, an empty list, the text
> "undefined" and all sorts of other approaches, some of which might
> make sense given a scenario, but that doesn't mean Option is like null
> any more than null is like "", or null is like 0, -1, false,
> "unknown", NaN, etc.

What I see is that without an array I can't do many things (10 variables,
of course, aren't the same as an array). I can live without Option, using
null. I'm not saying that null is better or worse - I don't want to
discuss this now. I'm saying that Option is one of the many ways to
represent the lack of a datum. In this sense, I completely agree to your
last paragraph, and this further consolidates in my mind that Option is a
totally different thing than a String, or any other type.

Cédric Beust ♔

unread,
Oct 25, 2012, 3:13:45 PM10/25/12
to java...@googlegroups.com

On Tue, Oct 23, 2012 at 5:22 PM, clay <clayt...@gmail.com> wrote:
Why is there no flatMap?

Would you really be satisfied if Optional had flatMap, though?

Think about it carefully.

To me, the main benefit of flatMap is composability. With flatMap, I can pass my Optional and other monadic values across a flow of transformations without ever having to drop down to raw values.

And here is the rub: Optional would be the only type in the JDK that has this property. It would be a bit like being the only person on the planet with a fax machine. If all that I can do is composing Optionals with other Optionals, the value is severely limited. Once/if Optional gains flatMap, won't you want List to get it as well? And Map? And TreeSets?

You see where this is going...

-- 
Cédric

Kevin Wright

unread,
Oct 25, 2012, 3:41:50 PM10/25/12
to java...@googlegroups.com
I can definitely see :)

Option obviously has to be iterable as well, so that it composes cleanly with other collections.

Then we can move to a model where composed functions are pushed through data instead of the other way round; leave all that hairy cyclomatic complexity in the dust where it rightly belongs!
--
Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com
vibe / skype: kev.lee.wright
steam: kev_lee_wright

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

Simon Ochsenreither

unread,
Oct 25, 2012, 3:46:44 PM10/25/12
to java...@googlegroups.com, ced...@beust.com

And here is the rub: Optional would be the only type in the JDK that has this property.
It would be a bit like being the only person on the planet with a fax machine. If all that I can do is composing Optionals with other Optionals, the value is severely limited. Once/if Optional gains flatMap, won't you want List to get it as well? And Map? And TreeSets?

It seems to be a tradition that some people never do their research...

FYI: http://cr.openjdk.java.net/~briangoetz/lambda/collections-overview.html

Ricky Clarkson

unread,
Oct 25, 2012, 3:53:12 PM10/25/12
to java...@googlegroups.com, ced...@beust.com
Yep, Iterable has a whole bunch of methods including flatMap.
> --
> You received this message because you are subscribed to the Google Groups
> "Java Posse" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/javaposse/-/jARmw54ckK0J.

clay

unread,
Oct 25, 2012, 5:13:56 PM10/25/12
to java...@googlegroups.com, ced...@beust.com
No, Iterable is a single method interface. It has only: "Iterator<T> iterator();"

java.util.streams.Stream has flatMap (and the collections implement Stream)

Ricky Clarkson

unread,
Oct 25, 2012, 5:30:45 PM10/25/12
to java...@googlegroups.com, ced...@beust.com
Aha. This changed recently, Iterable had a lot of defender methods before.
> https://groups.google.com/d/msg/javaposse/-/6d4PBBWGSHEJ.

clay

unread,
Oct 25, 2012, 5:58:44 PM10/25/12
to java...@googlegroups.com, clay, Mario Fusco, Ricky Clarkson
On Thursday, October 25, 2012 1:15:31 PM UTC-5, fabrizio.giudici wrote:
I think I'm not fully understanding this. For the record, I'm definitely  
not a Scala fan, and I definitely don't want all the Scala features in  
Java, but I'd like to be able to use Option with the least effort.

I'm surprised. Why don't you like Scala? Is it a specific feature(s) you don't like? A tools issue? A community issue? Learning curve?

Most people consider each of the following a significant advancement over Java/C++/C#:

The companion objects vs static
The primary constructor system
The merging of separate fields/properties to eliminate pointless JavaBean getters/setter or even the C# automation of getter/setters
The way that if blocks, for blocks, and aribtrary { } block return values
The way that immutable val is such a native construct
The addition of persistent immutable collections to the standard library
Pattern Matching
Native tuples
 

Ricky Clarkson

unread,
Oct 25, 2012, 6:02:35 PM10/25/12
to clay, Mario Fusco, java...@googlegroups.com

He has said before that he finds Scala unreadable.  He also doesn't want lambdas in Java.  Some people just prefer the status quo, whatever happens to be what they're making money out of today.

Fabrizio Giudici

unread,
Oct 25, 2012, 6:20:18 PM10/25/12
to clay, Ricky Clarkson, java...@googlegroups.com, Mario Fusco
On Fri, 26 Oct 2012 00:02:35 +0200, Ricky Clarkson
<ricky.c...@gmail.com> wrote:

> He has said before that he finds Scala unreadable. He also doesn't want
> lambdas in Java. Some people just prefer the status quo, whatever
> happens
> to be what they're making money out of today.

My exact point of view is that language innovation should happen in a new
language instead of overloading a mature language to death. I continuously
see Java 5/6 under-used or misused, so lambdas won't change most of the
scenarios (or eventually make things worse). I've talked about this a lot
in the past and I won't repeat the same stuff.

In any case, and back to topic, given that the decision to put lambdas in
Java 8 has been taken, it would be absurd to have a half-baked support - I
mean, lambdas and not Option, or similar stuff, or limited support in
collections.

Cédric Beust ♔

unread,
Oct 26, 2012, 1:22:23 AM10/26/12
to java...@googlegroups.com, clay, Mario Fusco, Ricky Clarkson
On Thu, Oct 25, 2012 at 2:58 PM, clay <clayt...@gmail.com> wrote:
The companion objects vs static
The primary constructor system
The merging of separate fields/properties to eliminate pointless JavaBean getters/setter or even the C# automation of getter/setters
The way that if blocks, for blocks, and aribtrary { } block return values
The way that immutable val is such a native construct
The addition of persistent immutable collections to the standard library
Pattern Matching
Native tuples

I agree with most of these points so my list would be pretty close to yours, but I'll add one important (to me) item: I want that language to contain very little on top of the features I want.

I like my languages like I like my beef: lean.

The problem with fat is that you can't just say "Ah well, I don't see the point in multiple inheritance of implementation, but I'll just ignore it". You can't ignore features in a language you don't like, you will encounter them whether you use them or not. And if you happen to be right in disliking a certain feature, it's almost guaranteed that when you encounter source code that uses that feature, it will make you unhappy.

What makes a great language designer is not the ability to implement complicated pieces of the compiler but the simple ability to say "No".

-- 
Cédric

Fabrizio Giudici

unread,
Oct 26, 2012, 3:21:26 AM10/26/12
to java...@googlegroups.com, Cédric Beust ♔, clay, Mario Fusco, Ricky Clarkson
On Fri, 26 Oct 2012 07:22:23 +0200, Cédric Beust ♔ <ced...@beust.com>
wrote:


> What makes a great language designer is not the ability to implement
> complicated pieces of the compiler but the simple ability to say "No".

I mostly agree with this.

Kevin Wright

unread,
Oct 26, 2012, 3:39:21 AM10/26/12
to java...@googlegroups.com

It's worth mentioning some of what Scala says "no" to then.

Primitives
Static methods
Checked exceptions
Disjoint multiple constructors
null
Default mutable collections
Non-returning statements
Special-case syntax for string concatenation, catch blocks and Enums

It can't say no to null entirely, not without losing compatibility, but it certainly doesn't use it in any native libs.

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.

Ricky Clarkson

unread,
Oct 26, 2012, 9:01:53 AM10/26/12
to java...@googlegroups.com

Scala only really says 'not yet' to checked exceptions.  If exceptions are a good idea (debatable, they make you lose referential transparency) then checked exceptions are a good idea, it's just that the syntax as in Java causes problems and Scala wanted to wait until a better mechanism was found.

The upshot is that exceptions are used less in Scala possibly in part *because* exceptions are unchecked, so checked exceptions would have to be done really well now to be attractive enough to add.

clay

unread,
Oct 26, 2012, 12:18:46 PM10/26/12
to java...@googlegroups.com
Using the latest lambda build, I just tried to write:

public class FixedOptional<T> extends Optional<T> implements Iterable

which may be arguably better than using one of the many existing excellent independent implementations (Functional Java, Atlassian).

Unfortunately the none/empty constructor is private so I can't create a derived version.

Ricky Clarkson

unread,
Oct 26, 2012, 12:30:15 PM10/26/12
to java...@googlegroups.com
Optional should really be a closed type, as it's basically an
algebraic datatype, something like:

abstract class Option<T> {
private Option() { }
static final class None<T> extends Option<T> { }
static final class Some<T> extends Option<T> { ... }
}

I would not expect it to be something you can subtype as a third party.
> --
> You received this message because you are subscribed to the Google Groups
> "Java Posse" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/javaposse/-/1zKVOHHJeXYJ.

clay

unread,
Oct 26, 2012, 1:29:29 PM10/26/12
to java...@googlegroups.com
I prefer this algebraic data type design that is standard in every other implementation of Option/Optional/Maybe (Scala, Haskell, F#, Functional Java library, Atlassian's library, and even Guava)

However, as mentioned earlier, JDK 8's Optional is completely and purposefully avoiding this, and has Optional as more of a traditonal Java class with a boolean flag.

Ricky Clarkson

unread,
Oct 26, 2012, 2:11:11 PM10/26/12
to java...@googlegroups.com
That can be abused to add a 2nd empty state, which can be tempting.
"It's either here, not here or not here yet!" I don't really mind
what the implementation is, but it should not be possible to add a
subtype as a third party.

https://github.com/JamesIry/jADT does quite well at generating
algebraic data types (no flatMap yet though) given a brief definition,
which might help anyone who is thinking about extending Optional.
> --
> You received this message because you are subscribed to the Google Groups
> "Java Posse" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/javaposse/-/eiZshlECKfEJ.

Simon Ochsenreither

unread,
Oct 26, 2012, 4:06:39 PM10/26/12
to java...@googlegroups.com

However, as mentioned earlier, JDK 8's Optional is completely and purposefully avoiding this, and has Optional as more of a traditonal Java class with a boolean flag.

Not wanting to have ADT doesn't mean the design has to be this poor. A single static final, immutable NONE field + a some constructor would already be better than this.

Simon Ochsenreither

unread,
Oct 26, 2012, 4:53:55 PM10/26/12
to java...@googlegroups.com
What makes a great language designer is not the ability to implement complicated pieces of the compiler but the simple ability to say "No".

That's why I'm using Scala. :-)

I'd love to see an example where Scala's designer didn't say "no" in the last half decade and which you think impacted the language negatively.



You can't ignore features in a language you don't like

What an double entendre, this makes my day. :-)


Add to the list of "Java language features not in Scala":
  • Special cased arrays (e. g. in for loops) in the language spec
  • Special syntax for defining, indexing and updating as well as fun syntactical variants like "int[] foo[] = ..."
  • Syntactic special cases for casts and instance-of checks
  • Class literals
  • A lot of different literal variants (like octal integer literals or floating point literals like 1.)
  • Bad integration of generics and arrays
  • Raw types
  • Forced use-site generics
  • Refinement types in the type system with no representation in source
  • Hardcoded implicit conversions for certain types


Different in Scala:

  • One, unified reflection API shared between runtime reflection, compile-time reflection and the compiler (instead of having two different, incompatible APIs like in Java, where one of them lacks an implementation, forcing users of those interfaces to re-implement compiler-logic.
  • Flexible backend which allows targeting different JVM versions while retaining the full feature set.
  • Two namespaces (types, terms) instead of four like in Java (types, packages, methods, fields)

Roland Tepp

unread,
Oct 26, 2012, 5:06:36 PM10/26/12
to java...@googlegroups.com
Instead of degenerating yet another thread into Java vs Scala debate (which it starts getting dangerously close to), what would be the thoughts on how we can actually influence Java 8 to have a proper Option type instead of this half-baked thing they have implemented atm.


BTW: I've actually created a decent implementation of Option/Maybe class in two of my recent jobs in a day (javadoc an all) without much fuzz and only passing theoretical background in FP, so this is really not all that complex when you get down to it. It is really very trivial implementation of a fairly trivial pattern.

Fabrizio Giudici

unread,
Oct 26, 2012, 5:25:48 PM10/26/12
to java...@googlegroups.com, Simon Ochsenreither
On Fri, 26 Oct 2012 22:53:55 +0200, Simon Ochsenreither
<simon.och...@gmail.com> wrote:

> Add to the list of "Java language features not in Scala":
>
> - Special cased arrays (e. g. in for loops) in the language spec
> - Special syntax for defining, indexing and updating as well as fun
> syntactical variants like "int[] foo[] = ..."
> - Syntactic special cases for casts and instance-of checks
> - Class literals
> - A lot of different literal variants (like octal integer literals or
> floating point literals like 1.)
> - Bad integration of generics and arrays
> - Raw types
> - Forced use-site generics
> - Refinement types in the type system with no representation in source
> - Hardcoded implicit conversions for certain types

I'm sorry, but I feel I should point out that this contributes to the
academic/elite argument about Scala. While you're reasoning from the side
of the language designer, and I could agree that Scala is much better
designed than Java, most developers just don't care the design of the
compiler, rather the usage of the language; and demonstrate that they can
understand this usage (generics wilcards being probably the only thing
that pushes over the edge). Funny variants such as arrays were "copied"
from C - yes, they were a mess, but they were popular because so many
people knew C and Sun demonstrated a good attitude in language marketing,
which proved to be a winning strategy. An attitude the Scala community has
failed to show so far.

Simon Ochsenreither

unread,
Oct 26, 2012, 5:41:35 PM10/26/12
to java...@googlegroups.com, Simon Ochsenreither
 
I'm sorry, but I feel I should point out that this contributes to the  
academic/elite argument about Scala.

Isn't this argument getting boring after a while? I think it is sad that "academic" is being used as a slander along the line of "not being practical".
Is there actual _any_ point someone is allowed to make which can't be hand-waved with "If you say that, you're an academic and therefore what you say doesn't count"?
In my opinion cleaning up syntactical and semantical warts and weirdnesses is one of the most practical things to do, but feel free to disagree.

 
While you're reasoning from the side  
of the language designer, and I could agree that Scala is much better  
designed than Java, most developers just don't care the design of the  
compiler, rather the usage of the language;

Every item (except for "Hardcoded implicit conversions for certain types ") on the list above is actually something a user of Java is exposed to while reading code.
No point above is in any substantial way related to an actual compiler implementation.

Fabrizio Giudici

unread,
Oct 26, 2012, 6:04:04 PM10/26/12
to java...@googlegroups.com, Simon Ochsenreither
On Fri, 26 Oct 2012 23:41:35 +0200, Simon Ochsenreither
<simon.och...@gmail.com> wrote:

>
>> I'm sorry, but I feel I should point out that this contributes to the
>> academic/elite argument about Scala.
>
>
> Isn't this argument getting boring after a while? I think it is sad that
> "academic" is being used as a slander along the line of "not being
> practical".

If you prefer "unpractical" to "academic" I'm fine, but the Merriam
Webster reports (http://www.merriam-webster.com/dictionary/academic) as a
meaning of academic:

3b. "having no practical or useful significance"


(I've checked just to verify that it wasn't a false friend to me).
> Is there actual _any_ point someone is allowed to make which can't be
> hand-waved with "If you say that, you're an academic and therefore what
> you
> say doesn't count"?

You are again misreporting my statement. I've said: you focus on the
compiler design, and most programmer just don't care of compiler design:
your argument doesn't "sell". *Thus* I think it's not practical

> In my opinion cleaning up syntactical and semantical warts and
> weirdnesses
> is one of the most practical things to do, but feel free to disagree.

Generally speaking I don't disagree. I can think of the concept of a
language that's practically better than Java for most people, for me, and
it is syntactically and semantically cleaner than Java. What I'm saying is
that the implication "cleaner -> more pratical, more popular" is not
automatic. It's just that practical evidence says that people do care more
of other things. When we'll have more Scala programmers than Java
programmers I'll be proven wrong. Furthermore, there are many languages
out here and I don't think Scala is the only one cleaner than Java.

> Every item (except for "Hardcoded implicit conversions for certain types
> ")
> on the list above is actually something a user of Java is exposed to
> while
> reading code.

... and it seems people handle it very well. That's my point. BTW,
autoboxing, which I understand is not an elegant solution from the
compiler design point of view, is rather intuitive for a developer (what's
not intuitive is a bag of nasty side effects of autoboxing, such as
performance traps or equals() vs == mismatches, but honestly they aren't
ruining many programmers' days). I think this is a effective
counter-example.

> No point above is in any substantial way related to an actual compiler
> implementation.

So perhaps I've missed the reason for which you were citing them.

Ricky Clarkson

unread,
Oct 26, 2012, 6:15:08 PM10/26/12
to java...@googlegroups.com, Simon Ochsenreither

A better language design means fewer corner cases, fewer forward references when learning and a higher signal to noise ratio in code.

Those are real things that real programmers benefit from.  I don't get all this nonsense about whether something is academic or not.  Ask instead whether it's correct, whether it's useful, what it needs to be useful if it's not.

The subject here isn't politics or religion, we can handle the truth.

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.

Simon Ochsenreither

unread,
Oct 26, 2012, 6:29:48 PM10/26/12
to java...@googlegroups.com, Simon Ochsenreither
You spend a lot of text to tell me you have run out of arguments. :-)

Cédric Beust ♔

unread,
Oct 26, 2012, 6:30:19 PM10/26/12
to java...@googlegroups.com

On Fri, Oct 26, 2012 at 3:15 PM, Ricky Clarkson <ricky.c...@gmail.com> wrote:
Those are real things that real programmers benefit from.  I don't get all this nonsense about whether something is academic or not.  Ask instead whether it's correct, whether it's useful, what it needs to be useful if it's not.

I agree with the general sentiment but the academic slant of a language or of a language designer has a very concrete impact on the direction of the language.

Whenever you decide to add a complex feature to a language, you generate a lot of material for papers that you can then submit to conferences. When you don't have the inclination of publishing papers about your language, you have much more freedom to refuse to add features (and one could argue that such languages end up being leaner than academically slanted ones as a consequence).

-- 
Cédric

Fabrizio Giudici

unread,
Oct 26, 2012, 6:34:40 PM10/26/12
to java...@googlegroups.com
On Sat, 27 Oct 2012 00:29:48 +0200, Simon Ochsenreither
<simon.och...@gmail.com> wrote:

> You spend a lot of text to tell me you have run out of arguments. :-)

Simon, Ricky, in the end I have one argument: Scala doesn't sell. Is it
short enough? :-) This is perfectly fine for me, since I'm not a Scala
advocate. If it's fine for you too, well, we're all fine. :-)

Simon Ochsenreither

unread,
Oct 26, 2012, 6:45:42 PM10/26/12
to java...@googlegroups.com, ced...@beust.com

Whenever you decide to add a complex feature to a language, you generate a lot of material for papers that you can then submit to conferences. When you don't have the inclination of publishing papers about your language, you have much more freedom to refuse to add features (and one could argue that such languages end up being leaner than academically slanted ones as a consequence).

It took me approximately 3 minutes to verify that this is non-sense. I find your assumption that the whole mailing list is too lazy or stupid to use Google to get an overview of Scala-related papers a bit disrespectful.

Fabrizio Giudici

unread,
Oct 26, 2012, 7:04:21 PM10/26/12
to java...@googlegroups.com, Simon Ochsenreither, ced...@beust.com
On Sat, 27 Oct 2012 00:45:42 +0200, Simon Ochsenreither
<simon.och...@gmail.com> wrote:

> It took me approximately 3 minutes to verify that this is non-sense. I
> find
> your assumption that the whole mailing list is too lazy or stupid to use
> Google to get an overview of Scala-related papers a bit disrespectful.

You see, Scala doesn't have success because the world is so full of stupid
and lazy people. Gents, I declare myself the champion of stupidity and
laziness.

Now, please, enlighten us. I suppose you took a few seconds to wrote your
latest email; please explain us the reasoning beyond the remaining 3
minutes. So perhaps we'll learn how to be less stupid and lazy :-)

Ricky Clarkson

unread,
Oct 26, 2012, 7:20:40 PM10/26/12
to java...@googlegroups.com

What on earth are you talking about?  We discuss the quality of the language, you say the quality is irrelevant, it's how it is in use.  We point out that those two things are linked, you say Scala doesn't sell.  Where will we go next on this tour of absurdities?  Scala is slow?  Underscores are bad for the heart?

Scala is free, it doesn't need to sell in financial terms to survive.  However, it is approaching the top 10 languages pretty well, and 40,000 people who started the Coursera course led by Martin Odersky clearly think it might have something going for it.  People backing Typesafe also clearly think the same and are putting their money into it.

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.

Simon Ochsenreither

unread,
Oct 26, 2012, 7:35:56 PM10/26/12
to java...@googlegroups.com, Simon Ochsenreither, ced...@beust.com

You see, Scala doesn't have success because the world is so full of stupid  
and lazy people. Gents, I declare myself the champion of stupidity and  
laziness.

Sorry that I didn't reply to your other comment. I assumed that bringing up the old "but Java is more popular" when debating about language design and evolution to be sufficiently desperate.
What's your point? I honestly don't see it. Should Java adopt more PHP features, because it is the most popular language for web sites? Or should it add some more features from JavaScript because it is the most popular language running in the browser?
 

Now, please, enlighten us. I suppose you took a few seconds to wrote your  
latest email; please explain us the reasoning beyond the remaining 3  
minutes. So perhaps we'll learn how to be less stupid and lazy :-)

Sorry, but your making up things I have never said. Especially, I didn't say that anyone on this list is "stupid and lazy".

Looking at the papers related to Scala, it is pretty obvious that most papers are not about any language feature at all.
One of the latest Scala-related paper for instance is about improving Scala's general-purpose data structure. (Clojure ships with more or less the same data-structure, btw. So I wonder if the fit the "academics!!!!" slur as well.)
There are a lot of papers discussing common software engineering issues and describing Scala's approach towards it. No "we added a language feature and wrote a paper about it" either.
Interestingly, the only recent papers discussing language features, use a separate branch of Scala (scala-virtualized) which will probably never see any substantial incorporation into trunk.

So both the connection between "Scala adds language features to write fancy research papers" as well as the base assumption of Scala adding "complex features to the language" is wrong.

Fabrizio Giudici

unread,
Oct 26, 2012, 7:50:19 PM10/26/12
to java...@googlegroups.com, Ricky Clarkson
On Sat, 27 Oct 2012 01:20:40 +0200, Ricky Clarkson
<ricky.c...@gmail.com> wrote:

> What on earth are you talking about? We discuss the quality of the
> language, you say the quality is irrelevant, it's how it is in use. We
> point out that those two things are linked, you say Scala doesn't sell.
> Where will we go next on this tour of absurdities? Scala is slow?
> Underscores are bad for the heart?

Please, let's avoid straw man argument. In every debate of Scala I'm
repeating the same point, I'm not going anywhere: Scala usage is low and I
don't see it substantially growing. You say it's approaching the top 10
languages? Fine, please share data. So far, I don't see it and evidence
backs up my point: either most people are so stupid that they don't see
the blatant qualities of Scala, or those qualities aren't practical
enough. I don't see any other explanation for facts. If you have any,
please share.

When statistics will change, I'll say I were wrong. I don't have problems
with this. Four years ago I was very skeptical about Android success, and
you can find my skepticism registered by Google. When facts proved Android
was really going to be successful, I admitted I were wrong and jumped on
the Android bandwagon. I don't have problems in changing my mind, neither
I have any particular satisfaction in proving I'm so cool I'm always
right. I don't care, indeed. I know I'm right for something and wrong for
something else. Which ones, time will tell. Professionally I'm ok when my
customers are happy and this happens and will happen with different tools.
Since Scala and Java are just tools, and I don't make them, I'm not in any
particular feeling with them. I respect any passion in other people, but I
frankly enjoy life in other things than computer languages.

>
> Scala is free, it doesn't need to sell in financial terms to survive.
> However, it is approaching the top 10 languages pretty well, and 40,000
> people who started the Coursera course led by Martin Odersky clearly
> think
> it might have something going for it. People backing Typesafe also
> clearly
> think the same and are putting their money into it.

"Doesn't sell" for me meant "is not used by masses". When I talk about
"marketing attitude" I'm not necessarily talking about money: I'm talking
about the capacity of communicating ideas and make them popular. I think
the point was clear from the exchange of a couple of weeks ago. This
doesn't deny that a few people are using it, and doing very good things,
and there also some niche market for it where experts are highly
appreciated. Minorities won't change the industry, though.

Anyway, again, is Scala approaching the top 10 languages? Please let us
have data.

Fabrizio Giudici

unread,
Oct 26, 2012, 8:11:35 PM10/26/12
to java...@googlegroups.com, Simon Ochsenreither, ced...@beust.com
On Sat, 27 Oct 2012 01:35:56 +0200, Simon Ochsenreither
<simon.och...@gmail.com> wrote:


> What's your point? I honestly don't see it. Should Java adopt more PHP

No - it shouldn't *add* things. It should *drop* things and get simpler.
Don't ask me which things to drop - I'm not a language designer and I
can't tell. Offer me a coherent and complete subset of Scala and we'll
reason on it.

Do you want a reference of the level of simplicity I like? Ok, think of a
static-typed only Dart. Note that I'm not saying I specially like Dart,
neither that it will have success. For the record, I'm not using it,
neither studying it. But it has got OO, it has got closures, it has got
even reified generics (which might be important or not), everything
designed from the ground up and not by incremental additions such as Java
8. Something roughly like that, producing JVM bytecode and compatible with
the existing Java runtime, is something that I'd consider as a *candidate*
that *could* have mass success in the industry. More complex than it, it's
unlikely.

> Sorry, but your making up things I have never said. Especially, I didn't
> say that anyone on this list is "stupid and lazy".

I said *I* was, of course, but I think there's at least one more person in
the world who doesn't appreciate Scala; if I find even another one, and I
think I have some chances, well, three's a crowd, so "we" sounds
appropriate :-) After all, being the champion of a single-man team is not
that big satisfaction.

Thanks for the explanation about papers. I wasn't making that point, it's
not an argument of mine as I don't have enough knowledge, but I'm glad I
can make an opinion on it comparing Cedric's and your arguments.

Cédric Beust ♔

unread,
Oct 26, 2012, 8:53:24 PM10/26/12
to java...@googlegroups.com
On Fri, Oct 26, 2012 at 3:45 PM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

Whenever you decide to add a complex feature to a language, you generate a lot of material for papers that you can then submit to conferences. When you don't have the inclination of publishing papers about your language, you have much more freedom to refuse to add features (and one could argue that such languages end up being leaner than academically slanted ones as a consequence).

It took me approximately 3 minutes to verify that this is non-sense. I find your assumption that the whole mailing list is too lazy or stupid to use Google to get an overview of Scala-related papers a bit disrespectful.

Why do you feel this urge to bring up Scala into every single discussion that you see?

It's turning into a disturbing obsession.

-- 
Cédric

Simon Ochsenreither

unread,
Oct 26, 2012, 8:58:57 PM10/26/12
to java...@googlegroups.com, Ricky Clarkson
I said *I* was, of course, but I think there's at least one more person in  
the world who doesn't appreciate Scala; if I find even another one, and I  
think I have some chances, well, three's a crowd, so "we" sounds  
appropriate :-) After all, being the champion of a single-man team is not  
that big satisfaction.
Thanks for the explanation about papers. I wasn't making that point, it's  
not an argument of mine as I don't have enough knowledge, but I'm glad I  
can make an opinion on it comparing Cedric's and your arguments.

I didn't mention "stupid and lazy" in connection to people disliking Scala. That's neither what I said nor thought.
I wrote that in my opinion his assumption that he can get away claiming made-up things which don't withstand 3 minutes of research is disrespectful to the readers of this list. There is nothing wrong with having an opinion, but trying to sell misleading claims as facts is in my opinion not a great way to interact with other people.



Offer me a coherent and complete subset of Scala and we'll reason on it.

I choose Scala 2.11 (+ no view bounds, + refined higher-kinded types) as a coherent subset of Scala. What would be your opinion on that?


Please, let's avoid straw man argument. In every debate of Scala I'm  
repeating the same point, I'm not going anywhere: Scala usage is low and I  
don't see it substantially growing.
 
Yes, please avoid the straw man! Repeating "but Java is more popular" is already well-known, accepted by everyone and doesn't add anything to an debate about language design and evolution. It is an obvious as well as desperate try to kill off a debate.
 

I'm talking  
about the capacity of communicating ideas and make them popular. I think  
the point was clear from the exchange of a couple of weeks ago. This  
doesn't deny that a few people are using it, and doing very good things,  
and there also some niche market for it where experts are highly  
appreciated. Minorities won't change the industry, though.

JEP 101: Generalized Target-Type Inference

JEP 103: Parallel Array Sorting

JEP 104: Annotations on Java Types

JEP 105: DocTree API

JEP 107: Bulk Data Operations for Collections

JEP 108: Collections Enhancements from Third-Party Libraries

JEP 109: Enhance Core Libraries with Lambda

JEP 118: Access to Parameter Names at Runtime

JEP 119: javax.lang.model Implementation Backed by Core Reflection

JEP 120: Repeating Annotations

JEP 126: Lambda Expressions and Virtual Extension Methods

JEP 139: Enhance javac to Improve Build Speed

JEP 155: Concurrency updates (jsr166e)

JEP 160: Lambda-Form Representation for Method Handles


I think I'm very happy with the change in industry.

clay

unread,
Oct 27, 2012, 3:46:44 PM10/27/12
to java...@googlegroups.com
On Friday, October 26, 2012 4:06:36 PM UTC-5, Roland Tepp wrote:
Instead of degenerating yet another thread into Java vs Scala debate (which it starts getting dangerously close to), what would be the thoughts on how we can actually influence Java 8 to have a proper Option type instead of this half-baked thing they have implemented atm.

This is the important question of this thread and it's not a technical issue that a typical developer such as myself would have much utility with.

Ideally, this is where the more well connected and influential members of the group, or even the Java Posse themselves, should comment.

Mario Fusco

unread,
Oct 28, 2012, 4:50:35 AM10/28/12
to java...@googlegroups.com
This is the important question of this thread and it's not a technical issue that a typical developer such as myself would have much utility with.

Ideally, this is where the more well connected and influential members of the group, or even the Java Posse themselves, should comment.

This is exactly my point too. Some of us, including myself, already tried to ask, without receiving any sensible answer, both why it is currently implemented in that way and if they have the intention to improve from there. Now I am seriously wondering if and how we could influence this process and more in general if we can still consider it as open as they claim.

Simon Ochsenreither

unread,
Oct 28, 2012, 9:39:21 AM10/28/12
to java...@googlegroups.com
We can only assume that they already considered it, looked at code-examples and maybe decided that this is not the way they want people to write code (similar to Guava).

This wouldn't be too bad in many languages, but even Java's planned extension methods are designed in a way which prevents people who disagree from fixing it.

In the end, different languages have different attitudes towards their users, which can range from “They are stupid and need constant shepherding” to “They know what they are doing, get out of their way”.
Thankfully, there are plenty of languages to choose from.

clay

unread,
Oct 28, 2012, 9:47:25 PM10/28/12
to java...@googlegroups.com
Is there a legitimate complaint about the Java 8 virtual defender methods? That seems like a great enhancement. I haven't heard any objections.

I understand that people will complain about everything. But with the Option/flatMap/iteration issue, there is a very specific, technical, articulate, well reasoned and widespread objection. That makes it quite different.

Sure, there is choice in languages, but that is a lame response. If there is still a community that cares, they should speak up. I will probably migrate from Java towards Scala whether they fix small ticket items like this or not. I would still like to see the flagship JVM language move in the right direction.

Ricky Clarkson

unread,
Oct 28, 2012, 11:12:26 PM10/28/12
to java...@googlegroups.com
Sure, they don't let me add methods to types I don't control, i.e.,
they're not extension methods a la C#. I think they solve what
they're intended to solve reasonably well though.
> --
> You received this message because you are subscribed to the Google Groups
> "Java Posse" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/javaposse/-/ZNq_cgjE_UgJ.
>
> To post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to
> javaposse+...@googlegroups.com.

Simon Ochsenreither

unread,
Oct 29, 2012, 10:35:16 AM10/29/12
to java...@googlegroups.com
Personally, I think Java's approach is superior to extension methods, because it ensures that dynamic dispatch looks like dynamic dispatch.
Allowing both static dispatch (via extension methods) and dynamic dispatch (via standard method call) for the same syntactical representation is confusing for readers and adds complexity to the already too complex topic of method resolution (boxing, erasure, etc.).¹

In my opinion, foo.bar(baz) should always invoke a method on type Foo, not "the compiler figures out whether Foo has such a method and if not rewrites it to some static invocation of an extension method in scope FooExtension.bar(foo, baz)".

Additionally, reflection "just works" with default methods whereas supporting extension methods in reflection (I'm not sure whether C# for instance doesn't support it at all.) would require capturing the whole environment of the method call to figure out if an eligible extension method is in scope.

The only thing which I don't understand is why they decided to call it "extension methods". It is misleading because Java's "extension methods" lack two properties more or less universally accepted: static dispatch, allowing extension of foreign code. Imho, both "default methods" and "defender methods" are better names, but I guess Oracle's marketing objected ...

In the end, I can understand Oracle's decision for implementing default methods this way. They are both technically superior to extension methods and uphold their (and Sun's) rule of "users of our language are not allowed to modify or extend library classes in any way".



If there is still a community that cares, they should speak up.

Some prominent members are not even grasping the concept behind it yet, so this sounds hard considering the limited amount of time remaining.

¹ I have only read the specification of the new method resolution/invocation rules, not tested it yet. Defender methods add another lookup step to the end, but I'm not sure whether it creates any new corner cases for the users. The usual stuff will work as expected of course, but it will be interesting to see how the JVM will behave when methods will be added or removed, made private, will get/lose default implementations, etc.
This has already been a complicated topic, were the JVM changed behavior randomly and backward-incompatibly (it actually got worse in Java 7).
If I can trust what people who know more than me on that topic say, it seems that both Java 6 and Java 7 are violating the VM spec concerning method resolution. Let's hope the situation improves for Java 8.

Bye,

Simon

clay

unread,
Oct 29, 2012, 11:35:44 AM10/29/12
to java...@googlegroups.com
C# Extension methods are mere syntactic sugar to convert this:
foo(o, args);
into this:
o.foo(args);

So what? I'm only interested in language/api features that have a basis in serious logical reason and purpose.

Every Scala feature I listed earlier can be supported by reason and logic, not merely subjective taste and opinion.

Cédric Beust ♔

unread,
Oct 29, 2012, 12:03:03 PM10/29/12
to java...@googlegroups.com
On Mon, Oct 29, 2012 at 7:35 AM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

In my opinion, foo.bar(baz) should always invoke a method on type Foo, not "the compiler figures out whether Foo has such a method and if not rewrites it to some static invocation of an extension method in scope FooExtension.bar(foo, baz)".

That's a fair concern. I haven't made up my mind yet, but I remember that when the industry started shifting toward OO, there was concern that when you read C code that says "foo(a, b)", you knew exactly what method was being invoked but that when you saw C++' "a.foo(b)", you had no idea what method was going to be called.

Defender methods might follow the same path in the end and just become something that we are used to parse.
 
-- 
Cédric

Ricky Clarkson

unread,
Oct 29, 2012, 12:55:58 PM10/29/12
to java...@googlegroups.com
Given that most programmers begin by doing theObject. and waiting for
their IDE to suggest methods, the C# approach is quite useful. The
Java 8 approach has some advantages, but it does lose the ability to
add methods to a third party/core type without being that third party
or Oracle, and in a static and scoped way so it doesn't have the
problems Ruby's monkeypatching does.

C#, much more than Java, is designed with autocompletion in mind, even
down to the order of the clauses in LINQ. E.g., SQL-style select foo
from people p where p.age..., the IDE wouldn't have enough context to
complete foo, so instead you write:

from p in people select p.foo where p.age > ...

It also caters to a school of [non?]-thought whereby it's OO or
otherwise natural if it goes x.y(z) instead of y(x, z). Scala's
implicit conversions are almost always used to achieve the same
effect.
> https://groups.google.com/d/msg/javaposse/-/Q84leqqf0tQJ.

Ricky Clarkson

unread,
Oct 29, 2012, 1:01:29 PM10/29/12
to java...@googlegroups.com
Java has always supported static dispatch looking like dynamic
dispatch.. instance.staticMethod(args), it's just deemed poor form. I
don't think erasure has any bearing on method resolution.

Are you a fan of Scala's implicit conversions? Those make it so that
foo.bar(baz) can really be someConversionMethod(foo).bar(baz),
actually harder to predict than extension methods.

Similarly, Scala's approach doesn't show up in reflection as far as I
know (at least in Java reflection; I haven't looked at the Scala
reflection library yet). It's probably best that extension methods a
la C# don't appear in reflection, because they're a static construct
and you could genuinely have two separate implementations of the same
method used in separate parts of code. You wouldn't want any
potential for runtime conflicts caused by a static convenience.
> --
> You received this message because you are subscribed to the Google Groups
> "Java Posse" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/javaposse/-/9Zezv6mmMFIJ.

Simon Ochsenreither

unread,
Oct 29, 2012, 2:53:35 PM10/29/12
to java...@googlegroups.com

Hi Ricky,


Java has always supported static dispatch looking like dynamic
dispatch.. instance.staticMethod(args), it's just deemed poor form.
 
Of course. I just try to forget that as much as possible. :-) I don't think there is any recent IDE which doesn't yell at you if you try to use this syntax.
So I think it is safe to say that generally, a developer can expect that stuff which looks like dynamic dispatch is dynamic dispatch these days in Java.
 
I don't think erasure has any bearing on method resolution.

http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.12
http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-5.html#jvms-5.4.3

These two things are by far the most complicated parts of the whole specs. It is almost completely impossible to figure out what is actually allowed and what not without writing positive/negative test-cases for every single line of the spec.
I guess that's the reason why even the official implementation from Oracle/openJDK violates the spec. (See the IKVM blog.)
 
Are you a fan of Scala's implicit conversions?  Those make it so that
foo.bar(baz) can really be someConversionMethod(foo).bar(baz),
actually harder to predict than extension methods.

A "fan" would be a bit too much. Until now, they are the just the least bad approach I have seen.
The dispatch on bar is still dynamic btw (but that's only nitpicking, because the conversion is computed by the static type of foo).
I share your concern here. One thing which makes the issue less pronounced than in other languages is that the combination of
  • a deprecation policy which actually removes things
  • traits
  • more classes are final

tends to eliminate a lot of those situations where one would want to use extension methods.

Imo implicits have a better cost/benefit ratio than extension methods, because it is a more general concept which fits into the general notion of OOP instead of some ad-hoc mechanism. The notion of "we add methods, not because it's fun, but to implement interfaces" is probably a good example.

Additionally, they allow library implementations of many things which would otherwise be hard-coded in the language/compiler, like implicit conversions. Considering the huge amount of implicit conversion in Java, I'm pretty happy that many of those necessary for compatibility are implemented as simple methods in Scala, allowing developers to use their IDE to find them.

If for instance Java would drop their pretty insane implicit widening conversions, the appropriate implicit methods could just be removed from the standard library in Scala. (implicit widening conversions are actually a pretty bad example, because they have a lot of subtle impact on method resolution, subtyping, etc. which is pretty faithfully supported in Scala, so it would be a bit more work in this case.)

As a conclusion, a lot of those things normally addressed by extension methods are solved using more standard means in Scala and implicits are a more general mechanism covering issues extension methods can't solve (and which are normally addressed with a lot of more ugly and complicated means).


Similarly, Scala's approach doesn't show up in reflection as far as I
know (at least in Java reflection; I haven't looked at the Scala
reflection library yet).

I think there is some method for runtime reflection (or did I confuse something?). If you use compile-time reflection, you get them via the Context argument, as far as I remember.

 
 It's probably best that extension methods a
la C# don't appear in reflection, because they're a static construct
and you could genuinely have two separate implementations of the same
method used in separate parts of code.  You wouldn't want any
potential for runtime conflicts caused by a static convenience.

Yes! That's exactly what I meant with it "would require capturing the whole environment of the method call to figure out if an eligible extension method is in scope".

Bye,

Simon

Mark Derricutt

unread,
Oct 29, 2012, 6:13:20 PM10/29/12
to java...@googlegroups.com
My main complaint about them is that well… they're USELESS unless you're the API designer - and they're anti-modular.


One of the recent security problems in Jdk7 was (I believe) related to a whole bunch of "tooling" methods being added to classes and shipped as part of the JRE.  Now - if those methods were all extension methods provided by say tooling-support.jar which was ONLY shipped with the JDK, or with tools and NOT with the JRE - then there would be no way of exploiting them.

I was real extension methods, not toys.

Fabrizio Giudici

unread,
Oct 29, 2012, 6:22:42 PM10/29/12
to java...@googlegroups.com, Mark Derricutt
On Mon, 29 Oct 2012 23:13:20 +0100, Mark Derricutt <ma...@talios.com> wrote:

> My main complaint about them is that well… they're USELESS unless you're
> the API designer - and they're anti-modular.

Following the discussion with interest - a suggestion, can you also give
some short code examples attached to your considerations (not only
referring to Mark's post, of course).

Graham Allan

unread,
Oct 29, 2012, 6:46:11 PM10/29/12
to java...@googlegroups.com
On 29 October 2012 22:13, Mark Derricutt <ma...@talios.com> wrote:
> My main complaint about them is that well… they're USELESS unless you're the
> API designer - and they're anti-modular.
>

The problem being solved is "Interface Evolution". Do you think just
interface evolution is the wrong goal, or that the implementation of
that is bad? To me, for what the stated problem is, default methods
seem reasonable.

w.r.t. 'anti-modular', I'd like to hear more on what you mean by this.
Do you mean that there's no way to organise default methods except as
being in the same file as the interface declaration?

Kind regards,
Graham

clay

unread,
Oct 30, 2012, 2:21:41 PM10/30/12
to java...@googlegroups.com

The JDK perspective makes sense now. These guys are definitely super smart guys. Goetz's book on concurrency is great, and I apologize for suggesting that the JDK authors were amatuers. I am also sorry to contribute to a denial-of-service-like barrage of complaints, although this issue probably did deserve better explanation.

FYI, I previously pointed out that the Some/None ADT pattern doesn't add value without Scala's pattern matching and object unpacking system.

It's interesting that Goetz is fully aware and agrees that Scala/Haskell are better for that type of high level functional programming. I presume this means that Java is targeting the more mass market developer and the elite developers are expected to choose Scala or something else?

Simon Ochsenreither

unread,
Oct 30, 2012, 3:09:51 PM10/30/12
to java...@googlegroups.com
I agree on the ADT part, but I think it is only one of the three major complaints brought up.

The other ones are:
  • Is no collection/doesn't implement Iterable/Stream/...
  • Is no monad/lacks map/filter/flatMap

It is certainly a bit confusing that he added ifPresent almost at the same time (which is more or less equivalent to a foreach).

Not sure whether it helps people learning the language or the new APIs when equivalent things are named differently throughout implementations/interfaces...

The positive thing is that I was already concerned that we would have two different Option/Optional types in the future and confusion which one to use, but that won't happen as far as I see. :-)

clay

unread,
Oct 30, 2012, 3:41:15 PM10/30/12
to java...@googlegroups.com
On second thought, I retract my last post.

If a there is a better design for a Java Optional that can be demonstrated with pure reason, then the better design should be used.

This isn't about converting Java into another language, it's about making optimal technical decisions and choosing better designs over inferior ones in the standard library.

There are two valid responses: either accept the improvement requests as valid and implement them or demonstrate why they aren't technically superior.

To respond with "the discussions surrounding Optional have exceeded its design budget" is a poor excuse. Budgets and schedules are important, but the product should be done well. There should not be obvious flaws in new additions to the Java 8 standard library. Period. Responding to a consensus of specific, articulate, technically valid criticism with these excuses is not valid.

Similarly with "There is a narrow design scope of what Optional is being used for in the JDK." The "design scope" sounds more like an internal process issue that shouldn't be part of the public discussion. Ultimately the new Java library additions should be done correctly and if they are flawed, people should complain, and the library additions should be fixed.

To attack criticism as "a denial-of-service attack" is wrong. There is such a large response because this is such an obvious error in a high profile location. That is when people are supposed to voice criticism.

"We've carefully considered the considerable input we've received, spent no small amount of time thinking about it, and have concluded that the current design center is the right one for the current time." This is an opaque non-answer: We've thought about it a lot, we know we are right, but we will not or can not explain why.

Christian Gruber

unread,
Oct 30, 2012, 4:01:53 PM10/30/12
to java...@googlegroups.com
On 30 Oct 2012, at 15:41, clay wrote:

> There are two valid responses: either accept the improvement requests
> as valid and implement them or demonstrate why they aren't technically
> superior.

It's more than just a bi-polar scale, Clay. Sometimes it's about API
fit and consistency. Not agreeing or disagreeing with your specific
assessment here, mind you. Just pointing out that "technically
superior" isn't an objective reality, it's a subjective judgment based
on a variety of data, including priorities, aesthetic, preference,
utility, and subjective qualities such as testability, maintainability,
readability (obviousness of client code), etc. That you feel it is
technically superior is all well and good - the authors don't agree, and
it's not objectively verifiable even if two groups agreed on the
priorites… and it's clear that the priorities displayed in this thread
don't match those of the JDK authors.

In summary - you could be right, Option/Maybe could be "the shit" - but
it still might be wrong for the JDK, or even if right, it is still the
prerogative of the authors to have their judgments.

It is also your prerogative to vocally register your disagreement. :D

Christian

clay

unread,
Oct 30, 2012, 5:19:50 PM10/30/12
to java...@googlegroups.com
I would consider "subjective qualities such as testability, maintainability, readability" to be under the umbrella of logic and reason.

No one has explained or defended the omission of flatMap functionality and the omission of iteration/collection functionality with any of those considerations.

'we thought about this and decided not to' is not a logical or technical answer.

'We aren't turning Java into Scala/Haskell'; this is a straw man argument. People are asking for a specific feature/design that happens to be in other languages. If the Java devs had some alternative plan that made sense on a technical level, that would be great.

"In summary - you could be right, Option/Maybe could be "the shit" - but it still might be wrong for the JDK, or even if right, it is still the prerogative of the authors to have their judgments."

If Optional flatMap/iteration is wrong for the JDK, no one is making that argument at all.

The pro flatMap/iteration side has very clear and easy to explain reasoning and logic.

Simon Ochsenreither

unread,
Oct 30, 2012, 6:07:21 PM10/30/12
to java...@googlegroups.com
The only reasonable, although political, explanation I see why they would prefer crippling Option on purpose is that they want to prevent a huge, general paradigm shift from using nulls to Option. This change would certainly be much more disruptive than the introduction of Generics.

The response on the lambda mailing list reminds me of that response from the Guava guy which was also along the lines of "don't even bother talking to us, everything you could say was already considered and rejected internally". In contrast, I remember an improvement request against Option (concerning a "forgotten") where reporting, acknowledgement, patch creation and pull request happened in 4 hours...

I guess that we are experiencing the difference between "open source code" and "open source development" right now.

Christian Gruber

unread,
Oct 30, 2012, 6:50:33 PM10/30/12
to java...@googlegroups.com
On 30 Oct 2012, at 18:07, Simon Ochsenreither wrote:

> The response on the lambda mailing list reminds me of that response
> from the Guava guy which was also along the lines of "don't even
> bother talking to us, everything you could say was already considered
> and rejected internally".

I am a friend and colleague of the "Guava guy" in question, with a deep
sense of his professionalism and experience with his overall judgement.
What you just said here is a reduction of his comment past the point of
honest interpretation. Critique specific design choices all you like,
if it makes you happy, but making it into a personal attack is appalling
and does nothing but create a hostile space in which those you want to
convince have little incentive to listen.

regards,
Christian.

Simon Ochsenreither

unread,
Oct 30, 2012, 7:50:48 PM10/30/12
to java...@googlegroups.com
Sorry Christian, but I don't see any attack at all, especially not any personal. Could you be more specific what exactly you found offensive, so it can be worded better/more precise/less tongue-in-cheek next time?

Personally, I probably couldn't care less about Java's Option, and I think it is pretty clear that there is more or less zero chance of Oracle listening to feedback on that topic.

I'm commenting because I have sympathy with Java's struggle to evolve and watching it fail just hurts. Apart from that, I have no stakes in the game.

clay

unread,
Oct 30, 2012, 8:15:50 PM10/30/12
to java...@googlegroups.com
In hg changeset 6331:af4b2dd992d6 (build 62), Optional.map was removed from the Lambda code. So they are moving in the opposite direction. Now there are three important missing features: map, flatMap, and iteration.

Regarding Dick Wall's comments on episode #397

- Option's main advantage is not avoiding NPE's, but factoring common null-related conditional logic out of all your code and into a standard library component.

See JDK author Brian Goetz explain the rationale for adding Optional with a simple Java snippet here: http://mail.openjdk.java.net/pipermail/lambda-dev/2012-September/005952.html

- Java's for loop is completely adequate for Option/Optional. Java doesn't need for-comprehensions or for-yield or pattern matching for a complete Optional.

- Scala's API does use null rather than Option in a few places. Scala.xml for one. I vaguely remember seeing other places, but I can't recall exactly where right now. Even without a green field implementation like Haskell, having a good Optional type is still valuable even in a mixed null/Optional environment.

On Tuesday, October 23, 2012 7:22:54 PM UTC-5, clay wrote:
Has anyone seen java.util.Optional in the new Lambda builds?

Why is there no flatMap?

Why does it not support iteration (can't do a for loop over an Optional)?

Why doesn't it have Some/None subclasses?

Why does Scala and Functional Java get this right yet Guava and now the core Java guys completely ruin it?

Why doesn't Java 8 have persistent immutable collections?


Some of the JDK developers have real talent, but this is completely amateur.

I really hope they can fix this before it is set in stone. Tons of decent functional programmers can write a complete Option implementation easily as a fun exercise. It boggles my mind that they don't have the decent talent working on something so important.

Christian Gruber

unread,
Oct 30, 2012, 8:56:38 PM10/30/12
to java...@googlegroups.com
On 30 Oct 2012, at 19:50, Simon Ochsenreither wrote:

> Sorry Christian, but I don't see any attack at all, especially not any
> personal. Could you be more specific what exactly you found offensive,
> so
> it can be worded better/more precise/less tongue-in-cheek next time?

Sorry - it's not just your comment simon, but a pervasive continuous
characterization of the Guava team's motives and character on this list,
that is quite aside aside from technical commentary and it's frustrating
to watch. I suppose I could just stop watching. I just wish this
discussion list would stick to the technical advantages/objections, and
respect when others don't agree with the importance of one aspect vs.
another, without characterizing the individuals and teams invoked.

Christian.

Cédric Beust ♔

unread,
Oct 30, 2012, 9:26:10 PM10/30/12
to java...@googlegroups.com
On Tue, Oct 30, 2012 at 12:09 PM, Simon Ochsenreither <simon.och...@gmail.com> wrote:
Not sure whether it helps people learning the language or the new APIs when equivalent things are named differently throughout implementations/interfaces...

Scala's choice of renaming Maybe to Option doesn't seem to have been much of a problem. If types have slightly different API's and purposes, different names make sense (and I find the use of the adjective "Optional" more sensible than the noun "Option", myself).

-- 
Cédric

Cédric Beust ♔

unread,
Oct 30, 2012, 9:36:40 PM10/30/12
to java...@googlegroups.com
On Tue, Oct 30, 2012 at 4:50 PM, Simon Ochsenreither <simon.och...@gmail.com> wrote:
Sorry Christian, but I don't see any attack at all, especially not any personal.

That's the main problem with your emails and overall attitude: people keep pointing out that you should tone down your passive aggressivity and ad hominem comments (including Martin himself, remember? That was not so long ago), and yet you continue to engage in aggressive advocacy.

Personally, I probably couldn't care less about Java's Option

You seem to care a great deal considering your heavy involvement in the latest discussions on the topic here and in other places.

, and I think it is pretty clear that there is more or less zero chance of Oracle listening to feedback on that topic.

See, you have obviously not even tried to read what Brian said in the email I forwarded or even bothered reading the 100+ emails on the subject on lambda-dev. There has been a lot of discussion and a lot of listening. At the end, Oracle made a decision that you don't like. It's called a disagreement, not a "not listening".
 
I'm commenting because I have sympathy with Java's struggle to evolve and watching it fail just hurts.

Your antagonism toward Java, Kotlin and Ceylon is well documented, I'm not sure why you keep pretending sympathy while your only goal is to promote Scala and deride people who choose not to use it.

-- 
Cédric

It is loading more messages.
0 new messages