That is sometimes just not an option performance wise yet.
"If it's the kind of error that must be handled, throw a checked exception. If there's no value to return, return Optional.empty."
Again, why is Optional.empty() better then null? What makes it better? What do you get from throwing an exception? What is the benifit. You can't just say "my way is better" when we have years and years of Java development flying contrary to your statement. What has changed that makes null a non-viable practice?
"The code receiving that Optional<Foo> is now free to do what the author is suggesting: map, filter, all without worrying if the value is actually there or not. The code is cleaner, easier to read, etc."
The code being cleaner is a subjective, or at least extremely difficult to prove, statment. For instance
List<Integer> nums = getNumbers();
if (nums == null) {
S.o.p("Failed to load numbers");
return;
}
for (Integer i : nums)
System.out.println(i);
Is far better then
Optional<List<Integers>> nums = getNumbers();
if (!nums.isPresent()) {
S.o.p("Failed to load numbers");
return;
}
nums.forEach(S.o::p);
Or even better yet
for (int i : nums)
if (i < 10)
S.o.p(i);
VS
nums.filter((n) -> n < 10).forEach(S.o::p);
I don't think that's more readable. It think that's more compressed. HEre's another example. Suppose we have a magical language that I'm sure you'll pick up. It's a very compressed (or as you'd say expressive) language. This is that same code written in it
pa(i i nums < 10)
Which expands to "print all the ints `i` in nums that are less then 10" in english. That's far less readable. It is more compressed. I don't think compression is the goal of a language as much as it is a goal of a zip program. We're supposed to be writing software, not liturature to submit to the shortest story fully told contest. Readability is a function of correct verbosity.
In my opinion. Just compressing your logic doesn't make it more readable. I think some verbosity is needed to preserve simplicity.
"But no one should ever have to check for null anymore. "
I mean that just doesn't make sense. If you're suggesting that there are some times the state of a program should never contain a null value is just ridiculous. Some things are correctly modled by null and some things are also too performance dependant to not use null.
I think some things benifit from using Optional<> but the case doesn't exist to completely remove null. Even just by the creation of a new container object wrapping your already expensive return object there exists a case for null to exist.
Just saying "Don't do it it's bad" is not proof. Saying "the code is cleaner, easier to read, etc" is not proof or even an example of a design that is simpler to pickup and get going with. You'd have to write some code with the Java/OOP paradigms and write a version (that is feature complete) with the FP paradigms and see which is easier to understand for a new programmer. I'd be hard pressed to belive that the FP implementation would be simpler. Maybe to you and me but no to someone without the domain specific knowladge required to understand what's going on. Even when I use map, zip, and list comprehensions in my python code it scares off some of my coworkers.
public List<Integer> add2(File file) {
List<Integers> nums = file.getNumbers(); // Show where the data comes from
if(nums == null) { // Show the invariant provided for the rest of the code
return Collections.<Integer>emptyList(); // Show the default return value if there has been an error
}
List<Integer> resultList = List<>(); // Apply your logic
for ( i : nums) {
resultList.append(i + 2);
}
return resultList; // Return your list
}
Then you document that behavior in a javadoc. Throw in @Nullable where applicable and move on. Or you can do this
public List<Integer> add2(File file) {
// Show data source
List<Integers> nums = file.getNumbers();
// Show case where data is supplimented
if(nums == null)
nums = Collections.<Integer>emptyList(); // Show supplimnetal
// Show transformation
List<Integer> resultList = List<>();
for ( i : nums) {
resultList.append(i + 2);
}
return resultList;
}
This is important to unify because nums won't always be null. We also won't always be supplimenting with an empty set. I don't see what value is recived from compressing that all into a single line. I don't see that as being more readable. I do see this very simple, step by step, explination of what's happening as being dead simple that no one can misunderstand.
> Again, why is Optional.empty() better then null?
Because with Optional the type tells the caller that it might not return a value. With null, you have no idea if you need to check for null or not.
Being able to chain maps, filters, etc. is convenient as well, but I'd argue that's just a side benefit.
Oh, one other thing Optional can do that null can't: nest. For example, if you call get() on a Map, and it returns null, you can't tell if the key wasn't in the map, or if it's value was null. If get() returned an Optional, then for a Map<String,Optional<String>>, get() would return Optional<Optional<String>>.
Your very first method has a return buried in the middle of your code. That is a gigantic red flag.
Look, what you're trying to do is simple.
getNumbers.fold(println("Failed to load numbers"))(nums => nums.foreach(println))
That's the Scala version, but I'm sure there's a Java version of the same code. This code assumes that getNumbers returns Option[List[Int]], which your compiler can guarantee. If you want something that's a little bit more readable, try this:
getNumbers match {
case Some(nums) => nums.foreach(println)
case None => println("Failed to load numbers")
}
No null check, no loops, just very simple easy-to-read bulletproof code. This code cannot generate a NPE at all, ever.
The first option ins completely unreadable to me. I cannot imagine that ever scaling well.
The second option, as I have stated many times in this thread, is far preferable to null. Java does not support it but when it does I will like it.
"* No null check, no loops, just very simple easy-to-read bulletproof code. This code cannot generate a NPE at all, ever.*"
The NPE isn't the illness, it's the symptom. It's the symptom of a far larger problem in your program: unhandled or otherwise unexpected state. That's why I like the match example. It forces you to expect all of the states of your program. The first example does neither. It hides flow and operation in a single (ever-expanding) line. Far from ideal in any case in my book.
As soon as Match is supported in Java I'll change my opinion. Until then I'm stuck. You get nothing better from the Java version in terms of readability.
In Scala, the debate between using fold on an Option or using map and getOrElse is almost as old as the language. The method signature for this is:
def fold[B](ifEmpty: => B)(f: (A) => B): B
That is to say, fold always returns type B, and takes two arguments. The first takes a function returning type B if the option is "empty" (None) and the second takes a function that is called with the contents of the Some. As you can see, it's syntactic sugar for map and getOrElse.
def map[B](f: (A) => B): B
def getOrElse[B](f: => B): B
If it's syntactic sugar for map and getOrElse what is really gained? If the definition of fold is mapAndGetOrElse why add an additional concept to burden programmers minds with? GetOrElse is independently useful and everyone needs to know map anyway. Using fold just seems like a lost opportunity to teach someone getOrElse with no real benefit.
You make the Understanding This Codebase 101 curriculum some percent longer without making your programmers any better.
If it's terseness, I don't really think one symbol is any verbosity benefit over two. Same order of magnitude, same cost. It's a rounding error in brevity. People way overvalue terseness.
And the cost of people missing chances to learn getOrElse has got to be massive.
It's quite simple: null is not a valid value for any type. It completely breaks the entire point of a type system. Null isn't an Integer, nor a String.
Simple example that proves my point: You can't call .length on null, but you can for every string. Therefore null isn't a string. So why in hell should you be able to write code that states (falsely) that null is a string? You can't say an int is a string.
Removing null from a language adds a tremendous amount of safety.
That is sometimes just not an option performance wise yet.
"If it's the kind of error that must be handled, throw a checked exception. If there's no value to return, return Optional.empty."
Again, why is Optional.empty() better then null? What makes it better? What do you get from throwing an exception? What is the benifit. You can't just say "my way is better" when we have years and years of Java development flying contrary to your statement. What has changed that makes null a non-viable practice?
"The code receiving that Optional<Foo> is now free to do what the author is suggesting: map, filter, all without worrying if the value is actually there or not. The code is cleaner, easier to read, etc."
The code being cleaner is a subjective, or at least extremely difficult to prove, statment. For instance
Is far better then Or even better yet VS I don't think that's more readable. It think that's more compressed. HEre's another example. Suppose we have a magical language that I'm sure you'll pick up. It's a very compressed (or as you'd say expressive) language. This is that same code written in it Which expands to "print all the ints `i` in nums that are less then 10" in english. That's far less readable. It is more compressed. I don't think compression is the goal of a language as much as it is a goal of a zip program. We're supposed to be writing software, not liturature to submit to the shortest story fully told contest. Readability is a function of correct verbosity.In my opinion. Just compressing your logic doesn't make it more readable. I think some verbosity is needed to preserve simplicity.
"But no one should ever have to check for null anymore. "
I mean that just doesn't make sense. If you're suggesting that there are some times the state of a program should never contain a null value is just ridiculous. Some things are correctly modled by null and some things are also too performance dependant to not use null.
I think some things benifit from using Optional<> but the case doesn't exist to completely remove null. Even just by the creation of a new container object wrapping your already expensive return object there exists a case for null to exist.
Just saying "Don't do it it's bad" is not proof. Saying "the code is cleaner, easier to read, etc" is not proof or even an example of a design that is simpler to pickup and get going with. You'd have to write some code with the Java/OOP paradigms and write a version (that is feature complete) with the FP paradigms and see which is easier to understand for a new programmer. I'd be hard pressed to belive that the FP implementation would be simpler. Maybe to you and me but no to someone without the domain specific knowladge required to understand what's going on. Even when I use map, zip, and list comprehensions in my python code it scares off some of my coworkers.