[lidHanteyk]

Where does the author insert themselves into their imaginary social interactions? Are they the sneering functional programmer?

In particular, I wonder about their characterization of sum types. I had to search to make sure, but they never say the word "union". This is curious, because they do understand "tag" and "tagged" as words used to describe sum-type behavior, and because the classic way to explain sum types to "imperative" C programmers is as "tagged unions", or union types with a tag value that explains which of the union's constructors is present. C or Java programmers would instead prefer an analogy with subtyping, which the article proceeds to use, but by overlooking the tagged-union analogy, the author is actually missing out on both a useful analogy for reaching out to imperative programmers, and also how low-level implementations of functional programming languages usually implement sum types.

Pattern-matching is probably the killer part of ADTs, but only two paragraphs were spent upon the concept. Worse, it's implied that pattern-matching is tied deeply both to ADTs and to functional programming, when it occurs outside of those contexts. Languages like Python 3, Ruby, Racket, and Swift fall outside of the traditional "functional programming" traditions but still have interesting pattern-matching abilities.

The author still doesn't know Haskell. Want an effectful loop? Control.Monad.Loops [0] contains many prebuilt loops, and they're written in standard Haskell. The ST monad [1] provides imperative variables and mutation. So does IO [2], if one insists on avoiding GHC for some reason. I agree that it's good to learn an ML, and Haskell is a fine choice, but the author needs to realize how drenched in Haskell memes they currently are, and to either learn more of Haskell itself, or to take a break from it for a while.

[0] https://hackage.haskell.org/package/monad-loops

[1] https://wiki.haskell.org/Monad/ST

[2] https://hackage.haskell.org/package/base/docs/Data-IORef.htm...

[uryga]

what do you mean by pattern matching in python 3? the only thing that sounds similar is (nested) iterable unpacking:

  (a, (b, c)) = foo()
  (fst, *middle, last) = foo()

which is nice but i wouldn't really call it pattern matching because i can't do something like

  match xs:
    when (): ...
    when (x, *rest): ...

i.e. do different things based on the shape of the data.

[madsbuch]

My thesis is, that proclaimed functional programmers spend more time on mathematical structures than implementation details. Hence a sum type and not a tagged union (how the target evaluater distinguishes should not name the type).

[rectang]

Software developers are allowed to have discussions about "integer" types without being constantly interrupted by number theorists to remind them that those aren't really integers.

Perhaps one day we will be able to have similar discussions about sum types without constant interjections by functional programmers.

[madsbuch]

Yes indeed, as number theorists should be allowed to ditto.