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.
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.
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.
Some of the JDK developers have real talent, but this is completely amateur.
I am sorry to say that I completely agree on that.
Calling someone's efforts amateurish isn't always the best way of persuading them to come round to your way of thinking.
Guava has no flatMap, and there it's deliberate so less likely to change than in the core.
--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.
As I said, there could be something else...
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.
... 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.
If you take Option so seriously and are on the JVM, why not fully switch over to Scala?
Today, JVM programmers are highly divided.
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?
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.
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.
The companion objects vs staticThe primary constructor systemThe merging of separate fields/properties to eliminate pointless JavaBean getters/setter or even the C# automation of getter/settersThe way that if blocks, for blocks, and aribtrary { } block return valuesThe way that immutable val is such a native constructThe addition of persistent immutable collections to the standard libraryPattern MatchingNative tuples
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.
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.
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.
What makes a great language designer is not the ability to implement complicated pieces of the compiler but the simple ability to say "No".
You can't ignore features in a language you don't like
Different in Scala:
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;
A better language design means fewer corner cases, fewer forward references when learning and a higher signal to noise ratio in code.
Those are real things that real programmers benefit from. I don't get all this nonsense about whether something is academic or not. Ask instead whether it's correct, whether it's useful, what it needs to be useful if it's not.
The subject here isn't politics or religion, we can handle the truth.
--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.
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.
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).
What on earth are you talking about? We discuss the quality of the language, you say the quality is irrelevant, it's how it is in use. We point out that those two things are linked, you say Scala doesn't sell. Where will we go next on this tour of absurdities? Scala is slow? Underscores are bad for the heart?
Scala is free, it doesn't need to sell in financial terms to survive. However, it is approaching the top 10 languages pretty well, and 40,000 people who started the Coursera course led by Martin Odersky clearly think it might have something going for it. People backing Typesafe also clearly think the same and are putting their money into it.
--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.
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 :-)
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.
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.
Offer me a coherent and complete subset of Scala and we'll reason on it.
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.
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.
I think I'm very happy with the change in industry.
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.
If there is still a community that cares, they should speak up.
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)".
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.
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).
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.
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. :-)
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.
Not sure whether it helps people learning the language or the new APIs when equivalent things are named differently throughout implementations/interfaces...
Sorry Christian, but I don't see any attack at all, especially not any personal.
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.