Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java 8’s new Optional type doesn't solve anything

medium.com

Post reply on HN
Print view View original

181–190 of 197 posts

Re: Java 8’s new Optional type doesn't solve anything

#181

Post by plonh »

peeters wrote: post #131
jrockway wrote: post #62

I've only used the Guava version of Optional, which appears to have a slightly different API than Java 8's. (You can tell there's a Java 8 committee, that's for sure.) The biggest problem I found in applying Optional is that Optional is very much a Haskell-y concept to me, and Java programmers and Haskell programmers don't really overlap much. Therefore, to me, Optional is just a functor like a list or a set. So doin…

It always bothered me that Java8 and Guava optionals don't just implement Iterable. There must be a good reason for this, and I'm guessing they're worried about confusion when you have an `Iterable >` but still, it'd be really nice to be able to just write for (T result : potentialResult ) { //... } I agree with you, that just seems so much more idiomatic than if (potentialResult.isPresent()) { T result = potentialRe…

The Guava authors believed Iterable would be confusing without calling .asSet() first.

Re: Java 8’s new Optional type doesn't solve anything

#182

Post by gurkendoktor »

gurkendoktor wrote: post #63
toolslive wrote: post #43

I have the same feeling about boost's optional. It's a bandage on a wooden leg.

std::string always is a value, boost::optional isn't (similar to std::string , just a lot safer). The problem is that Java only has boost::optional , which can be null, empty or a value.

(Hacker News obviously wasn't made for writing about C pointers—the places where the text turns into italics and back where supposed to be asterisks.)

Re: Java 8’s new Optional type doesn't solve anything

#183

Post by valarauca1 »

kibwen wrote: post #168
valarauca1 wrote: post #162

Earlier quoted context omitted.

> filter_map(|x| foo(x)) Thanks :D I've been really struggling to get iterators in rust. I don't have a very strong functional background :|

Note that anytime you see a closure in any language that just takes a single argument, calls a single function with that argument, and returns the value of that function, then you can eliminate the closure entirely by just passing the function instead. So `filter_map(|x| foo(x))` can be written more simply as just `filter_map(foo)`.

I know this but I can never get my code to compile when doing this. I always seem to get huge type errors even when I know the code is correct.

     map(|x|foo(x)) //clean compile
     map(foo) //type error
The number of times I've had this happen has just lead to me giving up on simply just passing the lambda as a variable instead of wrapping it in another.

Re: Java 8’s new Optional type doesn't solve anything

#184

Post by steveklabnik »

codygman wrote: post #176
steveklabnik wrote: post #84

Earlier quoted context omitted.

unwrap() is not unsafe in Rust, and I don't think Haskell has anything similar?

The definition in Rust's documentation[0] was this: let x: Option = None; assert_eq!(x.unwrap(), "air"); // fails The equivalent Haskell if unwrap throws a panic as the docs[0] seem to imply: λ> fromMaybe (error "panic!") Nothing *** Exception: panic! You could also do something like this if you don't mind dealing with the wrapped boolean value: λ> fmap (== "air") (Just "air") Just True and the failure case: λ> fmap…

Right, but it's still not unsafe. The stack unwinds, destructors get called.

And I meant some notion of 'safety', not fromMaybe/fromJust.

Re: Java 8’s new Optional type doesn't solve anything

#185

Post by the_af »

mark242 wrote: post #143
the_af wrote: post #120

Earlier quoted context omitted.

> I've not seen a NullPointerException in years [in Scala] This sounds odd. Does your code never interface with Java libraries and frameworks? I envy you! It's all too easy to forget to wrap a suspect value from Java-land with an Option(..) . And cumbersome even if you do remember. And then, there's the code written by Scala novices who just love using nulls. Yes, yes, "code reviews", we all know they are always prac…

The Scala landscape is very, very quickly creating their own libraries for similar popular Java libraries/frameworks. It is entirely possible to create an application, web or otherwise, that uses no Java libraries at all (save for the sbt dependency tree). As for "Scala novices who just love using nulls", if you're seeing that, then the coder in question missed day 1 of Scala training, which is always "if you are wri…

Maybe, but if true that's still in the future. The OP claimed they hadn't seen a NPE "in years", which simply doesn't match my own experience.

As for novices: yes, novices tend to do that. They tend to miss, misremember or fail to put into practice what they should have learned on day 1. I've also seen senior devs who were not exactly newbies (in general) still using nulls because they don't grok Scala; the famous "you can program Fortran in any language". The reality of software development is that you have to deal with all these people.

Re: Java 8’s new Optional type doesn't solve anything

#186

Post by kibwen »

valarauca1 wrote: post #183
kibwen wrote: post #168

Earlier quoted context omitted.

Note that anytime you see a closure in any language that just takes a single argument, calls a single function with that argument, and returns the value of that function, then you can eliminate the closure entirely by just passing the function instead. So `filter_map(|x| foo(x))` can be written more simply as just `filter_map(foo)`.

I know this but I can never get my code to compile when doing this. I always seem to get huge type errors even when I know the code is correct. map(|x|foo(x)) //clean compile map(foo) //type error The number of times I've had this happen has just lead to me giving up on simply just passing the lambda as a variable instead of wrapping it in another.

Curious. Can you provide a full code example so that I can try to determine what's causing that error?

Re: Java 8’s new Optional type doesn't solve anything

#187

Post by valarauca1 »

kibwen wrote: post #186
valarauca1 wrote: post #183

Earlier quoted context omitted.

I know this but I can never get my code to compile when doing this. I always seem to get huge type errors even when I know the code is correct. map(|x|foo(x)) //clean compile map(foo) //type error The number of times I've had this happen has just lead to me giving up on simply just passing the lambda as a variable instead of wrapping it in another.

Curious. Can you provide a full code example so that I can try to determine what's causing that error?

Just make an issue?

Re: Java 8’s new Optional type doesn't solve anything

#188

Post by dllthomas »

tel wrote: post #86
matteotom wrote: post #52

I don't program much Java, but how expensive are exceptions? Wouldn't it make more sense to expect functions that could return null to instead throw a checked exception if something goes wrong? eg public dbResult doDatabaseThing(stuff) throws DatabaseException So if you do result = doDatabaseThing(stuff) the compiler will require you to do something about the DatabaseException. It seems to me that the point of, for e…

And of course checked exceptions (wrapped in a try block) are "just" the nomadic effect of the option (or "result") type.

I am amused by "nomadic".

Re: Java 8’s new Optional type doesn't solve anything

#189

Post by dllthomas »

mike_hearn wrote: post #142
bkv wrote: post #139

Earlier quoted context omitted.

>Except these aren't at all the same. With a reference, you have no good way of telling whether your reference IS nullable. As the article mentions, we have annotations to do just that. >Therefore it is trivial to a) train developer habits to always check before fetch, and b) enforce an isPresent check with static checks. Again, if we're using static analysis to verify the correct use of Optional, why are we using op…

Much better than using static analysis is to have it in the type system: https://kotlinlang.org/docs/reference/null-safety.html It's simple: val x: Foo = maybeGetSomeFoo() // Error: method returns Foo? val x: Foo? = maybeGetSomeFoo() x.sayHello() // Error: x may be null x!!.sayHello() // OK, the !! method throws an exception if it's null if (x != null) x.sayHello() // OK, flow sensitive typing means the test narrows…

"Much better than using static analysis is to have it in the type system"

I am not sure there is a distinction. Though it is true that some analyses may be run by a broader swath of users.

Re: Java 8’s new Optional type doesn't solve anything

#190

Post by Manishearth »

kibwen wrote: post #186
valarauca1 wrote: post #183

Earlier quoted context omitted.

I know this but I can never get my code to compile when doing this. I always seem to get huge type errors even when I know the code is correct. map(|x|foo(x)) //clean compile map(foo) //type error The number of times I've had this happen has just lead to me giving up on simply just passing the lambda as a variable instead of wrapping it in another.

Curious. Can you provide a full code example so that I can try to determine what's causing that error?

Usually in these cases the culprit is autoderef/deref coercions.
Post reply on HN