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

Showing 1-139 of 139 messages
java.util.Optional<T> (Java 8) clay 10/23/12 5:22 PM
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.

Re: [The Java Posse] java.util.Optional<T> (Java 8) Ricky Clarkson 10/23/12 5:48 PM
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.
Re: [The Java Posse] java.util.Optional<T> (Java 8) Cédric Beust ♔ 10/23/12 6:04 PM
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




On Tue, Oct 23, 2012 at 5:22 PM, clay <clayt...@gmail.com> wrote:

--
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.

Re: [The Java Posse] java.util.Optional<T> (Java 8) Ricky Clarkson 10/23/12 6:14 PM
Can you point to it?  I spent a while looking for it but I signed up
after it happened.
Re: [The Java Posse] java.util.Optional<T> (Java 8) Cédric Beust ♔ 10/23/12 6:27 PM
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

Re: [The Java Posse] java.util.Optional<T> (Java 8) clay 10/24/12 12:04 AM
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.
Re: [The Java Posse] java.util.Optional<T> (Java 8) Christian Gruber 10/24/12 5:57 AM
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.

On Oct 24, 2012, at 3:04, clay <clayt...@gmail.com> wrote:

I read that map/flatMap are commonly requested features for Guava Optional, but the Guava team just dismisses the requests without apparent reason.
Re: [The Java Posse] java.util.Optional<T> (Java 8) clay 10/24/12 10:02 AM
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.
Re: [The Java Posse] java.util.Optional<T> (Java 8) Ricky Clarkson 10/24/12 10:12 AM

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.

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.
Re: [The Java Posse] java.util.Optional<T> (Java 8) clay 10/24/12 10:37 AM
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.
Re: [The Java Posse] java.util.Optional<T> (Java 8) Ricky Clarkson 10/24/12 10:50 AM
Error bothers me too, I'll discuss that with the others.  Thanks for
mentioning it.
> https://groups.google.com/d/msg/javaposse/-/AVs8YepKaOoJ.
Re: [The Java Posse] java.util.Optional<T> (Java 8) Simon Ochsenreither 10/24/12 12:02 PM

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 ...
Re: [The Java Posse] java.util.Optional<T> (Java 8) Ricky Clarkson 10/24/12 12:20 PM
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.
Re: [The Java Posse] java.util.Optional<T> (Java 8) Simon Ochsenreither 10/24/12 2:24 PM
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.
Re: [The Java Posse] java.util.Optional<T> (Java 8) Ricky Clarkson 10/24/12 2:38 PM
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.
Re: java.util.Optional<T> (Java 8) Mario Fusco 10/25/12 2:52 AM

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
Re: java.util.Optional<T> (Java 8) Simon Ochsenreither 10/25/12 3:11 AM
 
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?
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Ricky Clarkson 10/25/12 3:16 AM

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

Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Fabrizio Giudici 10/25/12 3:26 AM
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
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Ricky Clarkson 10/25/12 3:33 AM

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+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Fabrizio Giudici 10/25/12 3:39 AM
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...
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Mario Fusco 10/25/12 3:48 AM

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.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Mario Fusco 10/25/12 3:56 AM

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!
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) clay 10/25/12 7:00 AM
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?

Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Ricky Clarkson 10/25/12 7:11 AM
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.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Mario Fusco 10/25/12 7:33 AM
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
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Fabrizio Giudici 10/25/12 7:58 AM
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.

--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio...@tidalwave.it
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) clay 10/25/12 9:21 AM
"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.

Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Cédric Beust ♔ 10/25/12 9:43 AM

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

Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Ricky Clarkson 10/25/12 10:01 AM
I have 'inflicted' Option on these people and not had any real problems.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Cédric Beust ♔ 10/25/12 10:27 AM
Sure, but that was not my point...

-- 
Cédric

Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Ricky Clarkson 10/25/12 10:28 AM
That's ok, I wasn't making any counterpoint.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Cédric Beust ♔ 10/25/12 11:01 AM
We need to stop not fighting, it's boring.

-- 
Cédric

Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Fabrizio Giudici 10/25/12 11:15 AM
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.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Josh Berry 10/25/12 11:28 AM
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.)
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Fabrizio Giudici 10/25/12 11:33 AM
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.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Ricky Clarkson 10/25/12 11:59 AM
> 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.
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Roland Tepp 10/25/12 12:01 PM
This is not an answer. It is avoiding an answer.

neljapäev, 25. oktoober 2012 17:00.49 UTC+3 kirjutas clay:
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?

Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Fabrizio Giudici 10/25/12 12:04 PM
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.
Re: [The Java Posse] java.util.Optional<T> (Java 8) Cédric Beust ♔ 10/25/12 12:13 PM

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

Re: [The Java Posse] java.util.Optional<T> (Java 8) KWright 10/25/12 12:41 PM
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

Re: [The Java Posse] java.util.Optional<T> (Java 8) Simon Ochsenreither 10/25/12 12:46 PM

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
Re: [The Java Posse] java.util.Optional<T> (Java 8) Ricky Clarkson 10/25/12 12:53 PM
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.
Re: [The Java Posse] java.util.Optional<T> (Java 8) clay 10/25/12 2:13 PM
No, Iterable is a single method interface. It has only: "Iterator<T> iterator();"

java.util.streams.Stream has flatMap (and the collections implement Stream)
Re: [The Java Posse] java.util.Optional<T> (Java 8) Ricky Clarkson 10/25/12 2:30 PM
Aha.  This changed recently, Iterable had a lot of defender methods before.
> https://groups.google.com/d/msg/javaposse/-/6d4PBBWGSHEJ.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) clay 10/25/12 2:58 PM
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
 
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Ricky Clarkson 10/25/12 3:02 PM

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.

Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Fabrizio Giudici 10/25/12 3:20 PM
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.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Cédric Beust ♔ 10/25/12 10:22 PM
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

Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Fabrizio Giudici 10/26/12 12:21 AM
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.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) KWright 10/26/12 12:39 AM

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.
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.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Ricky Clarkson 10/26/12 6:01 AM

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.

Re: java.util.Optional<T> (Java 8) clay 10/26/12 9:18 AM
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.

Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Ricky Clarkson 10/26/12 9:30 AM
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.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) clay 10/26/12 10:29 AM
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.


On Friday, October 26, 2012 11:30:46 AM UTC-5, Ricky Clarkson wrote:
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.

Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Ricky Clarkson 10/26/12 11:11 AM
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.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Simon Ochsenreither 10/26/12 1:06 PM

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.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Simon Ochsenreither 10/26/12 1:53 PM
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)

Re: java.util.Optional<T> (Java 8) Roland Tepp 10/26/12 2:06 PM
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.

Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Fabrizio Giudici 10/26/12 2:25 PM
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.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Simon Ochsenreither 10/26/12 2:41 PM
 
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.

Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Fabrizio Giudici 10/26/12 3:04 PM
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.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Ricky Clarkson 10/26/12 3:15 PM

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+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Simon Ochsenreither 10/26/12 3:29 PM
You spend a lot of text to tell me you have run out of arguments. :-)
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Cédric Beust ♔ 10/26/12 3:30 PM

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

Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Fabrizio Giudici 10/26/12 3:34 PM
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. :-)
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Simon Ochsenreither 10/26/12 3:45 PM

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.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Fabrizio Giudici 10/26/12 4:04 PM
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 :-)
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Ricky Clarkson 10/26/12 4:20 PM

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+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Simon Ochsenreither 10/26/12 4:35 PM

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.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Fabrizio Giudici 10/26/12 4:50 PM
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.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Fabrizio Giudici 10/26/12 5:11 PM
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.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Cédric Beust ♔ 10/26/12 5:53 PM
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

Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Simon Ochsenreither 10/26/12 5:58 PM
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.

Re: java.util.Optional<T> (Java 8) clay 10/27/12 12:46 PM
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.
Re: java.util.Optional<T> (Java 8) Mario Fusco 10/28/12 1:50 AM
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.
Re: java.util.Optional<T> (Java 8) Simon Ochsenreither 10/28/12 6:39 AM
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.
Re: java.util.Optional<T> (Java 8) clay 10/28/12 6:47 PM
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.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Ricky Clarkson 10/28/12 8:12 PM
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.
Re: java.util.Optional<T> (Java 8) Simon Ochsenreither 10/29/12 7:35 AM
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
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) clay 10/29/12 8:35 AM
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.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Cédric Beust ♔ 10/29/12 9:03 AM
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

Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Ricky Clarkson 10/29/12 9:55 AM
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.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Ricky Clarkson 10/29/12 10:01 AM
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.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Simon Ochsenreither 10/29/12 11:53 AM

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
Re: [The Java Posse] java.util.Optional<T> (Java 8) Mark Derricutt 10/29/12 3:13 PM
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.


On 29/10/2012, at 2:47 PM, clay <clayt...@gmail.com> wrote:

Is there a legitimate complaint about the Java 8 virtual defender methods? That seems like a great enhancement. I haven't heard any objections.


Re: [The Java Posse] java.util.Optional<T> (Java 8) Fabrizio Giudici 10/29/12 3:22 PM
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).
Re: [The Java Posse] java.util.Optional<T> (Java 8) Graham Allan 10/29/12 3:46 PM
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
Re: java.util.Optional<T> (Java 8) clay 10/30/12 11:21 AM

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?

Re: java.util.Optional<T> (Java 8) Simon Ochsenreither 10/30/12 12:09 PM
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. :-)

Re: java.util.Optional<T> (Java 8) clay 10/30/12 12:41 PM
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.

Re: [The Java Posse] java.util.Optional<T> (Java 8) Christian Gruber 10/30/12 1:01 PM
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
Re: [The Java Posse] java.util.Optional<T> (Java 8) clay 10/30/12 2:19 PM
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.
Re: [The Java Posse] java.util.Optional<T> (Java 8) Simon Ochsenreither 10/30/12 3:07 PM
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.
Re: [The Java Posse] java.util.Optional<T> (Java 8) Christian Gruber 10/30/12 3:50 PM
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.
Re: [The Java Posse] java.util.Optional<T> (Java 8) Simon Ochsenreither 10/30/12 4:50 PM
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.
Re: java.util.Optional<T> (Java 8) clay 10/30/12 5:15 PM
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.

Re: [The Java Posse] java.util.Optional<T> (Java 8) Christian Gruber 10/30/12 5:56 PM
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.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Cédric Beust ♔ 10/30/12 6:26 PM
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

Re: [The Java Posse] java.util.Optional<T> (Java 8) Cédric Beust ♔ 10/30/12 6:36 PM
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

Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Cédric Beust ♔ 10/30/12 6:41 PM

On Tue, Oct 30, 2012 at 5:15 PM, clay <clayt...@gmail.com> wrote:
- 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.

Exactly. I expanded on this point here.

On a related note, I find it funny when people advocate Option because "it forces you to deal with null pointers instead of ignoring them" and then rant against checked exceptions because they force you to do exactly the same thing. I was also a bit surprised that the whole discussion on Optional in the podcast never mentioned a single time the main benefit of Options (composability) while casually discussing practices that are sure to lead to pain (calling get() or pattern matching on the content of an option), and by extension, discourage people from using Option altogether.

-- 
Cédric



Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Ricky Clarkson 10/30/12 6:57 PM
scala.xml is notoriously badly-designed and will likely be removed or
replaced (I could be out of date and it might already have been
rewritten).  Daniel Spiewak's antixml appears to be the de facto
standard.  Don't take it as typical Scala.

On Tue, Oct 30, 2012 at 9:15 PM, clay <clayt...@gmail.com> wrote:
> --
> 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/-/FIwskPnhYj0J.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Josh Berry 10/30/12 6:58 PM
On Tue, Oct 30, 2012 at 9:41 PM, Cédric Beust ♔ <ced...@beust.com> wrote:
>
> On Tue, Oct 30, 2012 at 5:15 PM, clay <clayt...@gmail.com> wrote:
>>
>> - 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.
>
>
> Exactly. I expanded on this point here.

I don't know, any expansion where you have a dig at Tony Hoare seems
likely to be off. :)


> On a related note, I find it funny when people advocate Option because "it
> forces you to deal with null pointers instead of ignoring them" and then
> rant against checked exceptions because they force you to do exactly the
> same thing. I was also a bit surprised that the whole discussion on Optional
> in the podcast never mentioned a single time the main benefit of Options
> (composability) while casually discussing practices that are sure to lead to
> pain (calling get() or pattern matching on the content of an option), and by
> extension, discourage people from using Option altogether.

You seem to be deliberately clouding the issue.  The side of the fence
that likes Option and friends like it not because "it forces you to
deal with null pointers," but because it lets you move the issue into
the realm of types.  Which is pretty much explicitly why they dislike
exceptions, because exceptions are pretty much an escape hatch from
the normal view of the type system.  (Either that, or I am completely
off in my admittedly naive understanding of the issues.)

What is wrong with pattern matching on the content of an option?  I
confess I did that just earlier today.  I had a reference to an Object
that might have been null.  So, I thought the following was fine:

val myRef = something that returns Object for some reason and might be null.
Option(myRef) match {
  case Some(x:ClassICanDealWith) => something with x
  case Some(x:OtherClassICanDealWith => something else with x
  case _ => either I was null or something I didn't know how to deal with
}

Was I wrong in that?
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Ricky Clarkson 10/30/12 7:03 PM
I dislike exceptions because they're not referentially transparent
(they break f(x) == f(x)) like the gotos they are.  That said, they're
handy sometimes.

As for pattern-matching, there's nothing inherently bad about it, but
usually or perhaps always with scala.Option, there's a better way of
writing code using HOFs.
> --
> You received this message because you are subscribed to the Google Groups "Java Posse" group.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Cédric Beust ♔ 10/30/12 7:09 PM
On Tue, Oct 30, 2012 at 6:58 PM, Josh Berry <tae...@gmail.com> wrote:
What is wrong with pattern matching on the content of an option?

It's basically equivalent to testing against null: if there's an object, do this, otherwise, do that.

It's sometimes (often?) unavoidable when you are dealing with API's that take raw values instead of Options, but you do want to weave through your monads as much as possible (flatMap) to reap all the benefits that Option has to offer: instead of extracting the value inside the monad and operating on it, consider lifting your operation so it can operate on the monad directly.

Here is an example of someone doing it wrong (I explained why in this article). "Doing it wrong" is probably a bit harsh, the kind of code in this article is common when you are just discovering Option and you haven't fully realized its potential. It's a lot more than a container, although I agree that explaining it as "a list of zero or one element" is a good introduction to give an idea of what it is.

-- 
Cédric







Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Josh Berry 10/30/12 7:11 PM
On Tue, Oct 30, 2012 at 10:03 PM, Ricky Clarkson
<ricky.c...@gmail.com> wrote:
> As for pattern-matching, there's nothing inherently bad about it, but
> usually or perhaps always with scala.Option, there's a better way of
> writing code using HOFs.

So, in my example, what should I have done instead?  I should say the
function returning an Object that might be null was from a java
library.  And the "do something with class I know" was less than 2
lines in each case.  Seemed perfectly succinct and readable.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Cédric Beust ♔ 10/30/12 7:14 PM
It depends on the functions that you are calling in the Some and None cases: if they belong to an external API, extracting the value is your only opt... er... choice. However, if you are calling methods that you wrote, consider rewriting them to accept an Option and just call flatMap with that method on your option.

-- 
Cédric

Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Josh Berry 10/30/12 7:22 PM
On Tue, Oct 30, 2012 at 10:14 PM, Cédric Beust ♔ <ced...@beust.com> wrote:
> It depends on the functions that you are calling in the Some and None cases:
> if they belong to an external API, extracting the value is your only opt...
> er... choice. However, if you are calling methods that you wrote, consider
> rewriting them to accept an Option and just call flatMap with that method on
> your option.

They were external.  In both cases they were a direct call to the x
object.  (So, case Some(x:..) => x.someMethod)

Though, I am surprised to see it suggested to make methods take in an
Option type.  I thought the general rule was to make the functions
take in the non option, and then use map/flatMap to deal with when
their are options.  (Unless, of course, your function does something
different when there is a None, I suppose.)

And, in all of this, I have to confess my round one of console logging
was to just use printfs.  I definitely realize I am not exactly a
paragon of functional purity.  :)
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Ricky Clarkson 10/30/12 7:28 PM
You don't necessarily have to write methods that take Option, you can
write normal methods and lift them into Option with map.  That's
generally better than writing methods that take Option but just return
None if the Option is None.

Josh's example needs fleshing out, it's not even clear whether he uses
the result of the pattern-matching or does it just for the
side-effects.  That has a bearing on how I'd prefer to write it.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Josh Berry 10/30/12 7:38 PM
On Tue, Oct 30, 2012 at 10:28 PM, Ricky Clarkson
<ricky.c...@gmail.com> wrote:
> Josh's example needs fleshing out, it's not even clear whether he uses
> the result of the pattern-matching or does it just for the
> side-effects.  That has a bearing on how I'd prefer to write it.

I'm converting to a string.  Either calling .asText or .getValue,
essentially.  And if it was a class I didn't know, just an empty
string.  Each case is currently just a printf saying what happened
followed by the method I'm calling, which depends on the type of the
value held.  (I may have removed the printfs, can't remember.)

The java call is HtmlUnit's querySelector method.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Ricky Clarkson 10/30/12 8:02 PM
Let's say this is the original with pattern-matching:

val s: String = option match {
  case None => getValue
  case Some(foo) => foo.asText
}

You could write this as:

val s: String = option.map(_.asText).orElse(getValue)

I might have misunderstood, it's just hit midnight and I've had a long
day.  If I have, can you give a code example?  Tony Morris' cheat
sheet might help; http://blog.tmorris.net/scalaoption-cheat-sheet/
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Josh Berry 10/30/12 8:12 PM
On Tue, Oct 30, 2012 at 11:02 PM, Ricky Clarkson
<ricky.c...@gmail.com> wrote:
> Let's say this is the original with pattern-matching:
>
> val s: String = option match {
>   case None => getValue
>   case Some(foo) => foo.asText
> }
>
> You could write this as:
>
> val s: String = option.map(_.asText).orElse(getValue)
>
> I might have misunderstood, it's just hit midnight and I've had a long
> day.  If I have, can you give a code example?  Tony Morris' cheat
> sheet might help; http://blog.tmorris.net/scalaoption-cheat-sheet/

Hmm... yeah, I'm not explaining this well.

The None case is treated the same as a case of a type I am not ready
to deal with.  So, the code is:

val t = Option(page.querySelector(".fooClass")) match {
  case Some(x:HtmlInputElement) => x.getValueAttribute()
  case Some(x:DomNode) => x.asText()
  case _ => ""
}

Typing it, it occurs to me I could probably just skip the Option
entirely (Right?  That just drops the Some from the two cases I
define.).  My gut reaction on any method that returns null on failure
is to immediately wrap it in Option() now, though.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Cédric Beust ♔ 10/30/12 8:16 PM

On Tue, Oct 30, 2012 at 8:12 PM, Josh Berry <tae...@gmail.com> wrote:
Typing it, it occurs to me I could probably just skip the Option
entirely (Right?  That just drops the Some from the two cases I
define.).

Yes, that was my reaction as well. There is little point in lifting a value into Option and immediately pattern matching on it to process its value... Like I said, it's basically a more contrived version of testing against null.

-- 
Cédric

Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) clay 10/30/12 8:19 PM
Scala's implicits clearly have some of the same drawback as C#'s extension methods in that it can make code hard to understand and hard to read. 

I haven't learned Scala's implicit feature well enough to comment on them yet.

On Monday, October 29, 2012 12:01:59 PM UTC-5, Ricky Clarkson wrote:
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.

Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Josh Berry 10/30/12 8:32 PM
I think my block here is that I don't think of pattern matching as a
null check candidate.  That, and I originally had aspirations of using
this reference in a more traditional Option sense.  Turned out not to
be needed, so I opted for what I thought was the shorter code method.
Re: java.util.Optional<T> (Java 8) Mario Fusco 10/31/12 1:13 AM

The JDK perspective makes sense now. These guys are definitely super smart guys.

Probably I am missing something, but what I read is just: "the goal is NOT to create an option monad or solve the problems that the option monad is intended to solve".
So Goetz stated what the Optional class is NOT and I could be fine with it. But I don't see any mention about what the Optional class IS or is supposed to be.

Looking at this example http://mail.openjdk.java.net/pipermail/lambda-dev/2012-September/005952.html it seems that its only purpose is to avoid an additional variable. Does the Optional scope end here? Please tell me that there is more!

I also disagree about the ADT thing. It is not only a pattern matching matter: having a None and a Some class extending Optional results in a better design and a better API.

Mario
Re: java.util.Optional<T> (Java 8) Simon Ochsenreither 11/1/12 10:47 AM
I found one interesting data point in the Optional-debate concerning Optional's predecessor in Guava. It looks like Atlassian has built their own Guava-addon/fork, adding pretty much all the things discussed in this thread. The description reads:

Google's guava project is a solid utility library providing many useful interfaces and utilities, and it is a very commonly added dependency for most projects. Unfortunately, they have a strong NIH syndrome and are somewhat half-pregnant when it comes to functional-programming. This library attempts round out some of the deficiencies that a functional programmer finds when using Guava.

It will be really interesting to watch how the whole ecosystem of standard library addons will react when Java 8 starts to gain traction and substantial use.
On the one side, lambda's allow a lot more abstraction which would have been considered over the top when Java only had AICIs (making addon libraries more likely), but on the other side, default methods allow Oracle to evolve standard library interfaces continually (decreasing the potential traction of addon libraries).

Considering Optional's scope, it seems like it is restricted to only support ending some chained collection transformations, not to start or participate during those operations. Considering how long it took until most popular libraries and frameworks abandoned checked exceptions, I can understand that Oracle wants to avoid putting the whole library ecosystem into a much more severe limbo with a general-purpose Optional, in which parts of the libraries (including the JDK) would keep handling optional values at the value level (null), while other parts might decide to handle optional values at the type level (Optional).
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Fabrizio Giudici 11/1/12 1:02 PM
> Google's guava project is a solid utility library providing many useful
>> interfaces and utilities, and it is a very commonly added dependency for
>> most projects. Unfortunately, they have a strong NIH syndrome and are
>> somewhat half-pregnant when it comes to functional-programming. This
>> library attempts round out some of the deficiencies that a functional
>> programmer finds when using Guava.
>>
>
> It will be really interesting to watch how the whole ecosystem of  
> standard
> library addons will react when Java 8 starts to gain traction and
> substantial use.

Definitely, because from the latest exchanges here it sounds as many of us  
will need some third party stuff to fully exploit the functional features  
in Java. For collections I've always stuck with the standard library, but  
I could depart from this standard in future. But I'm a little worried  
about a possible proliferation of multiple, incompatible libraries. I'd be  
interested in knowing why Google rejected the patches submitted by  
Atlassian (I interpret their comment as the fact that they tried to  
provide patches...).


--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio...@tidalwave.it
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Jed Wesley-Smith 11/1/12 2:30 PM
On Friday, 2 November 2012 07:02:38 UTC+11, fabrizio.giudici wrote:
… I'm a little worried  
about a possible proliferation of multiple, incompatible libraries. I'd be  
interested in knowing why Google rejected the patches submitted by  
Atlassian (I interpret their comment as the fact that they tried to  
provide patches...).

We – and others – have tried to submit patches to Guava several times and were basically met with a stone-wall, normally various excuses about some internal thing or other, and then Kevin came out and basically said[1] they were never going to take any submissions from outside, so please stop trying.

Fugue[2] was written as it became increasingly obvious that any sane functional library code would be deliberately subverted as the Guava team don't like it [3] and have no intention of supporting it except accidentally.

BTW Fugue isn't our only functional library code, we have recently added a Promise[4] to atlassian-util-concurrent[5] that gives a much saner interface to the whacky ListenableFuture stuff.

I'm somewhat disheartened by this whole thread though, I was really hoping java8 might bring some sanity to functional programming in Java. There seems though to be much investment from some parts of the community in making sure it doesn't happen, and no good reason for it. I have spoken with Brian Goetz, he's a great guy but he alone cannot do all of lambda as well as implement really good standard FP lib. Hopefully they'll get more resources so they can round things out, but there'd be a lot more than just having map/flatMap on Option (think immutable collections for instance).

Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) clay 11/1/12 5:39 PM
OK, I wrote Optionals for JDK8 which adds static functions map, flatMap, and toIterable

(I would probably adjust the generics type boundaries if this was a serious effort)

So that these work:

map(optObj, (o) -> ...);
flatMap(optObj, (o) -> ...);
for (T t : toIterable(optObj)) { ... }

For at least the first two, C#-style extension methods would offer more natural syntax, but I don't think that is a big deal:

optObj.map((o) -> ...);
optObj.flatMap((o) -> ...);

The major downside is that this will be another third-party add-on library and not built-in to the core standard library.

Will third party libraries -- mainly Functional Java but also others like Atlassian Fugue -- standardize on the JDK8 option and use static methods for the omitted features or will they continue to use completely separate Option class implementations?

Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Ricky Clarkson 11/1/12 5:59 PM
It is unlikely that we will drop Option in favour of Optional in
Functional Java, as that would be a step backwards for the library if
Optional does not gain flatMap etc.  There will almost certainly be a
compatibility layer.

As an aside, it's amazing how small an amount of code we're really
talking about.  I just implemented Option and List including map and
flatMap in JavaScript for fun on the way home from work (and missed my
stop!).
> --
> 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/-/9-5GnOv9VGUJ.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) clay 11/1/12 7:21 PM
But you wouldn't lose any functionality at all, you would merely lose the more convenient syntax

instead of class function syntax:

optObj.flatMap((a) -> ...);

you would use external static function syntax:

flatMap(optObj, (a) -> ...);
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Ricky Clarkson 11/1/12 8:00 PM
That would be inconsistent with the other types in FJ.  There's no
advantage to that over using Option other than compatibility with code
that uses Optional, for which a couple of conversions can be provided.
 If they do it right then I would expect us to drop Option but FJ is
not the kind of library that makes compromises, it should instead be
the library that does everything as well as is possible in Java.  That
said it's not exactly a translation of Haskell's prelude.

Proper extension methods would let us add flatMap and map to Optional
and get on with life.
> https://groups.google.com/d/msg/javaposse/-/2jhSx9IrHTEJ.
Re: [The Java Posse] java.util.Optional<T> (Java 8) Mark Derricutt 11/2/12 4:20 AM
My thoughts on them being anti-modular is more around wanting to keep an API separate from -ANY- implementation.

Say you have a bug in your default implementation, or you wish to alter it - you currently need to rerelease the API even tho the actual API hasn't changed.

In an ideal modular world we should be shipping -api and -impl jars and keeping things separate, this makes working with say OSGi and I guess any other module system much nicer, clients will bind themselves against an API, which ideally would be rather stable and not change often, leaving the implementation to be interchangable.

Maybe this pattern is more suited to more services than utility functions like but in the name of modularity I don't see why it shouldn't be just as desirable.



On 30/10/2012, at 11:46 AM, Graham Allan <grundl...@gmail.com> wrote:

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?

Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Dick Wall 11/2/12 9:19 AM


On Tuesday, October 30, 2012 6:41:31 PM UTC-7, Cédric Beust ♔ wrote:

On a related note, I find it funny when people advocate Option because "it forces you to deal with null pointers instead of ignoring them" and then rant against checked exceptions because they force you to do exactly the same thing. I was also a bit surprised that the whole discussion on Optional in the podcast never mentioned a single time the main benefit of Options (composability) while casually discussing practices that are sure to lead to pain (calling get() or pattern matching on the content of an option), and by extension, discourage people from using Option altogether.

-- 
Cédric


Hi Cedric

I could have sworn that my whole point on the podcast *was* to talk about what you call the "composability" of the option type, which is due to the monadic nature of it if you want to be technical, but that was certainly the point of the discussion - I will try again in the next podcast to make sure it is super clear.

I am pretty sure I remember saying something along the lines of: sure you can use pattern matching or if (x == None) to use options, but to do so is missing the point, far better is this form:

val zips = for (person <- people; address <- person.addressOption; zip <- address.zipOption) yield zip

Ok - that's a coarse example, but it shows the point, which is that you start with some people, and get a list of the existing zips from that list assuming that the person has an address, and the address has a zip. If not, the for expression gets short circuited and you don't get the zip. It's very understandable code with a high signal to noise ratio especially compared with (I would write Java, but I would probably make a mistake writing it after 3 years not using it, so I will write Java style Scala with the null checks):

val zipsMut = mutable.ListBuffer.empty[String]

for (person <- people) {
  if (person.address != null && person.address.zip != null) zipsMut += person.address.zip
}

val zips = zipsMut.toList

I think that's fair code - I even put the two null checks in the same predicate knowing that it won't run the second if the first fails (fair, but you need to know that lore about the language too in order to know there can't be an NPE in that second dereference).

I even remember saying that the real value of Option in Scala, Haskell and other languages that offer it is that it is integrated into the core libraries for doing stuff like this. That's the real value and I remember saying on the podcast that I can understand the position of the folks doing Optional in Java - even if the flatMap was there, it would only really be useful if the core libraries were retro-fitted to use options over nulls, and if there was language support for options in the form of a for expression or similar. 

Did anyone else get that I was trying to say this? Certainly I will clear it up in the next podcast.

I know you have a thing about me saying Option has eliminated a whole class of runtime errors - namely NullPointerExceptions - from my code and fair enough, I won't say that. I will say instead that Option has enabled/encouraged/caused me to write natural looking code easily with less bugs in it, period. Is that better?

On the other point - I get what Java was trying to do with checked exceptions, but the problem is I have rarely (if ever) seen them used well. The problem is that they are a pain, all that re-throwing or catching, so people abuse them or subvert them or just plain avoid them. Just like Option (when you get into the mindset) makes a nice, easy, readable alternative to nulls and null checks, so Either when you get into the mindset makes a nice, readable, easy alternative to checked exceptions. It's convenient to use them and pass them along, which it almost never seems to be with checked exceptions and which is why most code I have seen either logs them and forgets them, re-throws them as runtime exceptions, or just ignores them altogether (IOException on file close...?). Ultimately the real judge of checked exceptions is that (as far as I know) there are no new main-stream languages that adhere to them, even Kotlin or Fanton (which are aiming at being the Java++ languages).

Dick
 
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Fabrizio Giudici 11/2/12 11:03 AM
On Thu, 01 Nov 2012 22:30:43 +0100, Jed Wesley-Smith  
<jed.wes...@gmail.com> wrote:


> We – and others – have tried to submit patches to Guava several times and
> were basically met with a stone-wall, normally various excuses about some
> internal thing or other, and then Kevin came out and basically said[1]  
> they
> were never going to take any submissions from outside, so please stop
> trying.
>
> Fugue[2] was written as it became increasingly obvious that any sane
> functional library code would be deliberately subverted as the Guava team
> don't like it [3] and have no intention of supporting it except
> accidentally.
>
> BTW Fugue isn't our only functional library code, we have recently added  
> a
> Promise[4] to atlassian-util-concurrent[5] that gives a much saner
> interface to the whacky ListenableFuture stuff.

Thanks for the insight, that to me is very important: at this point I  
think I should wait with Guava and have a look at Fugue.

But I can't prevent myself from putting further questions? If the  
stone-wall was only Sun/Oracle, one might argue they have a too  
conservative attitude. Now we're talking also of Google. The two biggest  
Java player around, I'd say.
unk...@googlegroups.com 11/2/12 11:47 AM <This message has been deleted.>
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) clay 11/2/12 11:58 AM
Dick, your person/address/zip example perfectly illustrates the benefit of Option/Optional.

This is precisely the functionality that JDK8 is purposefully omitting and that we are debating.

I wrote some optional flatMap adds-on for the latest JDK8 lambda build, ported your person/address/zip example, and tested:

List<Person> people = ... // Omitting test data initialization
final List<String> zips = new ArrayList<String>(); // Zip codes go here.

// optionalMap is missing from JDK8. I wrote it and statically imported it.
optionalMap(optionalMap(people.stream(), (p) -> p.addressOption), (a) -> a.zipOption).into(zips);

If JDK8 had optionalMap built-in (or if I could add-on with C#-like extension methods), it would have the much more natural syntax:

people.stream().optionalMap((p) -> p.addressOption).optionalMap((a) -> a.zipOption).into(zips);

This offers pretty much all of the benefits of Option and is almost as elegant as your Scala example without any changes to the Java language.

I've put a more complete code implementation + example in pastebin (classes are concatenated): http://pastebin.com/id03sNvQ
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) clay 11/2/12 1:12 PM
In hindsight, a simpler solution (with static import of custom toIterable method) would be:

final List<String> zips2 = new ArrayList<String>();
for (Person p : people) { for (Address a : toIterable(p.addressOption)) { for (String z : toIterable(a.zipOption)) { zips2.add(z); } } }

Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Fabrizio Giudici 11/2/12 1:22 PM
Honestly, I don't find it particularly readable.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Ricky Clarkson 11/2/12 1:28 PM
With proper support it would be:

List<String> zips2 =
people.flatMap(Person::addressOption).flatMap(Address:zipOption);

That might take a stubborn person a couple of minutes to understand
but after that even the most determined anti-flatmapper will be able
to curse, rewrite, fire the writer of but ultimately understand code
like this without any real trouble.
> --
> You received this message because you are subscribed to the Google Groups
> "Java Posse" group.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Fabrizio Giudici 11/2/12 1:49 PM
On Fri, 02 Nov 2012 21:28:50 +0100, Ricky Clarkson  
<ricky.c...@gmail.com> wrote:

> With proper support it would be:
>
> List<String> zips2 =
> people.flatMap(Person::addressOption).flatMap(Address:zipOption);

This is better.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) clay 11/2/12 2:09 PM
First, you can't use the :: method reference syntax with a variable.

Secondly, the map and flatMap functions currently exist on the Stream interface and return a modified Stream. So you have to start with people.stream() and end with either a Stream instance or call .into(someCollection) to put them into a collection.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Ricky Clarkson 11/2/12 2:32 PM
It's rare that you actually expose public fields in Java, so let's
assume addressOption and friends are methods, and then the method
reference syntax works fine.

Also, I said 'with proper support', regarding the returned collection
type. :)  But sure, adding a .into wouldn't be too bad.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/javaposse/-/SBpf_wVxh0gJ.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) clay 11/2/12 2:53 PM
AFAIK,

You can't do ClassName::instanceMethod()
You have to do classInstance::instanceMethod()

So, even if getAddressOption() was an instance method, you would have to do onePersonInstance::getAddressOption, and the method reference is bound to that one instance which wouldn't fit with the example.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Ricky Clarkson 11/2/12 3:50 PM

I can't confirm right now but I'm pretty sure I've done ClassName::methodName in my experiments with FunctionalJava and Java 8.  Doesn't the State of the Lambda cover that too?

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/mhPVSnOnsIYJ.

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.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) clay 11/3/12 6:54 AM
State of the Lambda #4 (http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-4.html) says you can do:

ClassName::staticMethod
or
instanceName::instanceMethod
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) Ricky Clarkson 11/3/12 2:14 PM

If you read the actual words in that document, a different story emerges:

For a reference to an instance method of an arbitrary object, the type to which the method belongs precedes the delimiter, and the invocation's receiver is the first parameter of the functional interface method:

Arrays.sort(names, String::compareToIgnoreCase);

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/yzc9RMhScTgJ.

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.
Re: [The Java Posse] Re: java.util.Optional<T> (Java 8) clay 11/3/12 3:01 PM
You are correct regarding instance method references and I was mistaken on that point.

So with third party static methods this syntax works (verified):
Stream<String> zipStream = optionalMap(optionalMap(people.stream(), Person::getAddressOption), Address::getZipOption);

And if a more native syntax was built into the JDK, it would be:
Stream<String> zipStream = people.stream().optionalMap(Person::getAddressOption).optionalMap(Address::getZipOption);

and you would follow with .into(zipList) if you wanted the results in a Collection rather than a Stream.
More topics »