In my free time I’m currently working on a new open-source project to add (almost) native support for algebraic data types (aka: sum types / tagged unions) in Java (via annotation processing). I would welcome some review of the readme: https://github.com/derive4j/derive4j from experienced FPers and feedbacks on feature set / generated api. eg. https://github.com/derive4j/derive4j/issues/8
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 validOption[T]value in all reference typesT. And I’ve seen unskilled Scala programmers (from the Java community, usually) usingnullall over the place. As with all tools, it can only be as good as the people using it.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.
Weird. In Scala, pattern-matching on Option is considered to be a beginner mistake.
yep. fold is better style. also missing on java8 Optional :(
Can you elaborate on this? I’ve never heard of folding over anything but a collection.
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).
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.
Not sure why you think
Some(null)should not be valid. It’s neitherOptions job to deal withnull, nor is it allowed to, because that would break laws.If
Tincludesnull, that’s an issue withT, not withOption.