1. 9

  2. 6

    I agree with the sentiment, and while I wouldn’t call it “worthless” insofar as it standardizes a pattern that skilled programmers will use, I’m glad that someone is recognizing this. “You can do X”, in a language, is not that interesting. Of course you can do anything in any language. What I want is to know that people can’t be doing certain Y’s, except in special and delineated cases (e.g. unsafePerformIO) where, one hopes, they’ve thought through the trade-offs and know what they’re doing.

    Likewise, functional programming doesn’t just mean “first-class functions”. C has first-class functions in function pointers. It’s not exactly a new idea. Functional programming means a lot more, and while that “a lot more” is too constraining for some problems (e.g. real-time systems that require manual memory management) it is, for most purposes, not very constraining and gives you a great deal of power when it comes to reasoning about the code.

    I’d take it further, though. The Option type is Scala is, in some sense, worthless. (I wouldn’t call either “worthless”.) You get pattern-matching, but you don’t get the assurance that you weren’t passed Some(null), which is a valid Option[T] value in all reference types T. And I’ve seen unskilled Scala programmers (from the Java community, usually) using null all over the place. As with all tools, it can only be as good as the people using it.

    1. 4

      My first instinct is that what makes or breaks Option is the presence or absence of pattern matching; I can’t think of any language without pattern matching that doesn’t make it unbearably tedious to use.

      I’d say this is even more important than static typing, as Erlang uses ad-hoc option types to great effect. (Though Erlang of course has the advantage of not having a null value.) If you get back an {ok, Value} tuple in Erlang, you’re going to match against it to pull the Value out, and this implicitly creates a “but if you don’t match, crash immediately instead of propagating bogus values further” situation; the language subtly encourages you to think of both cases even without the help of a type system.

      1. 3

        Weird. In Scala, pattern-matching on Option is considered to be a beginner mistake.

        1. 1

          yep. fold is better style. also missing on java8 Optional :(

          1. 1

            Can you elaborate on this? I’ve never heard of folding over anything but a collection.

            1. 2

              see. Option.fold. ‘Catastrophism’ is the general technical term for (right) folds when we are not talking about list in particular, but otherwise same idea. You can derive a lot of methods from just the definition of a catamorphism: http://blog.tmorris.net/posts/debut-with-a-catamorphism/index.html Fold-algebras, object-algebra are also based on the idea. An application in java/scala is to encode algebraic data-types (eg. https://github.com/derive4j/derive4j).

      2. 2

        WartRemover (https://github.com/puffnfresh/wartremover) is a tool that provide guarantees you don’t use unsafe construct in you scala code. A similar tool could be written for Java using the Checker Framework.

        With some tooling and tutorship you can do functional programming in any language. Saying “we don’t do FP because you can write unsafe code anyway” is a bad excuse (even Haskell has unsafePerformIO / unsafeCoerce), because “Fast and Loose Reasoning is Morally Correct” -> http://www.cs.ox.ac.uk/jeremy.gibbons/publications/fast+loose.pdf

        That would be like saying “let’s give-up at writing maintenable code because some people (that I don’t want to tutorship) will write shitty code anyway”.

        But yes, we should also push to use better languages at the same time.

        1. 2

          Not sure why you think Some(null) should not be valid. It’s neither Options job to deal with null, nor is it allowed to, because that would break laws.

          If T includes null, that’s an issue with T, not with Option.

        2. 5

          Just in case you didn’t hate Oracle enough already, this linked blog post is absolutely rage-inducing.

          1. 1

            Isn’t that from the same person that posted that horrid “no you really can’t decompile our binaries stop stealing our source” blog post?

          2. 2

            Optional can be useful in one situation: automatically populated fields, like with dependency injection. Dropwizard enables using Guava’s Optional for request parameters, like so:

            public Result httpHandler(@QueryParam("param") Optional<String> param) { ...

            In this case, you are guaranteed the Optional isn’t null so you can comfortably use it, even though the compiler doesn’t check it. Otherwise the possibility of the Optional itself being null totally eliminates any utility.