1. 12
  1.  

  2. 39

    This is a weird article. I jumps from ‘null is bad’ to ‘you need FP’. Null is bad because of a combination of two things:

    • All pointer types are option types of T* and NULL.
    • Unchecked conversions to T* are permitted.

    The second of these is the real problem. NULL is fine if every pointer access requires a NULL-pointer check, but the fact that you can’t express the difference between T* | NULL and T* in your type system means that you have no way of capturing the fact that you have performed the check.

    None of this has anything to do with functional programming or any other paradigm, it is simply a limitation of a family of type systems.

    1. 15

      This is a weird article. It jumps from ‘null is bad’ to ‘you need FP’.

      Given the way it describes basic concepts, I think this is really not an article for engineers; the intended audience is either executives or managers. It feels like it was written so that Haskell/Purescript-loving engineers could have something to send to their manager to help convince them to use Haskell/Purescript at work.

      But yeah, the fact that many functional languages solve the null problem is entirely coincidental; they solve that problem because they were designed by people who spent a lot of time thinking about problems of programming, not because they’re functional languages.

      1. 12

        Case in point, Clojure has the null problem.

        1. 3

          And Racket and Erlang don’t, despite having type systems almost as far from Haskell as you can imagine.

          1. 4

            They do, and I would argue that in fact you can’t avoid this problem without static types.

            They may not have a construct actually called null, but you see the same kind of patterns in scheme – #f is often used the way null is in languages without sum types. I have seen more than one serious bug that was the result of forgetting to check for #f. More trivially:

            Gerbil v0.17.0-26-g96025a9c on Gambit 4.9.4-41-ga34094ff
            > (null? '())
            #t
            > (car '())
            *** ERROR IN (stdin)@2.1 -- (Argument 1, pair) PAIR expected
            

            If you don’t have the option of simply rejecting such constructs at build time (static checks) then the best you can do here is throw an exception – which Java does too, and it’s better than what C does (undefined behavior), but it’s still a problem.

            I have less experience with Erlang, and I feel like the “let it crash” philosophy probably muddles the waters wrt. what’s a null “bug” vs. the intended approach to error handling, but I don’t see anything fundamentally separating it from other languages.

            1. 2

              Sure; granted that’s A nil problem, but it’s a very different problem from Clojure’s nil problem where the nil values trickle all the way thru the codebase and manifest as problems in areas that are far away from the root cause. I’ve debugged more than my fair share of these, and when I code in Racket and Erlang, the absence of nil as a valid “not found” value is the most refreshing difference.

            2. 0

              Umm, Racket and Erlang are both FP languages, with a lot of similarities to Haskell.

            3. 1

              Is Clojure a functional language? I wasn’t aware that any LISPs were

              1. 2

                It doesn’t help that “functional language” is about as well-defined as “systems language”. It’s a shame that procedures and subroutines ended up being called functions. (Much like functors in C++.) Now we have languages based on mathematical functions, which we have to call “purely functional” because we already called Lisp “functional”.

                So, yes, Lisp is traditionally considered a functional language, but it’s functional in the sense that it makes it easy to write programs that pass functions as arguments to other functions, which might return functions, or store them in data structures, etc., i.e. functions are “first-class citizens” of the language and can be manipulated much like any other value. This is unlike a lot of other programming languages… but not much different from many languages around today. You can even do most of this in C with function pointers, it’s just a lot more awkward.

                Scheme is more functional than Common Lisp (pun not intended) as it really encourages that “functional style” of programming, whereas Common Lisp is happy to let you program in any style you like. Clojure is like Scheme, in that it strongly encourages functional-style programming (but will let you do imperative things if you really want).

                No Lisp, as far as I know, is functional in the mathematical “pure function” sense that, say, Haskell is.

                1. 1

                  Clojure allows you to be non-functional, but defaults very strongly to functional.

            4. 12

              I’m equally impressed and disappointed in myself that I could predict all the arguments in the article just by knowing the author was Charles Scalfani.

              1. 7

                Indeed, a very questionable chain of reasoning. The text contains no justification for the claim in the title.

                In my book, I provide guidance for obtaining proficiency in a functional language called PureScript

                How do you say, “he thinks for his supper”.

                1. 3

                  I was going to post exactly this. It’s a huge rhetorical leap from optional types to functional programming. We can have immutability, type safety and other goodies without going full blown FP.

                  Plus, Ocaml is missing from the list of repositories, which is a gross error for someone advocating the solution to software.

                2. 5

                  I think FP is awesome but I am saddened that this article does nothing more than present anecdotal evidence. In this regard I don’t think it’s more convincing than any other blog post touting the next programming panacea.

                  I am optimistic that in the near future we will have better qualitative and quantitative data on what it means to be a good programming language and whether existing languages are good.

                  1. 4

                    Of note: the author said this article aims to target CEOs and management. Folks here may not be the target.

                    1. 3

                      The comments here have been far more enlightening than the article was.

                      1. 1

                        HN discussion (which is rather too cynical): https://news.ycombinator.com/item?id=33433783

                        1. 4

                          What makes you say it’s too cynical?

                          1. 5

                            What’s interesting to notice about this thread is how many messages are just oozing with smug superiority and disdain for anyone who doesn’t share their knowledge.

                            The cynicism characterization comes from the fact that the criticaster who wrote the top-level thread engages in the projection of one’s own feelings of offense (else, the author can surely and readily reference those specific words that connoted “smug superiority and disdain”) rather than discussing the merits of the topic at hand.

                            “Gatekeeping” is another fancy word used elsewhere to express this felt offense, making it pass for a factoid.

                            The author even goes to the extent of condescendingly claiming to read the minds of the people involved (FP proponents) better than those people themselves can by exclaiming, “I don’t think they can even see what they’ve become.” when the fact of the matter simply is that “what they’ve become” is nothing but a cynical creation of this person’s mind (else, the author can surely and readily reference those specific words that connoted “smug superiority and disdain”) which projection is then introjected by other such criticasters and naysayers as evidenced by the place this factoid holds in the hierarchy of comments.

                            None of this is unique to functional programming per see. When something new is presented to humanity, the initial tendency generally is to resist it at all costs. See https://en.wikipedia.org/wiki/Allegory_of_the_cave

                            1. [Comment removed by moderator pushcx: You can point out a cliche without being cruel.]