Is this a new kind of HN trolling? Instead of directly disagreeing with an argument on it's merits, you call a commenter out on possibly ambiguous terminology and use that to dismiss the entire comment?
Your entire lecture is true, but it does not apply to the sentence you quoted at all. That sentence is about some Haskellers' tendency to sacrifice readability in favor of better static checks. He could've written "difficult to understand" instead of "complex" and his comment wouldn't have changed meaning and your entire comment would've been void.
The difference between complex & hard, easy & simple has been put very elegantly by Rich Hickey in Simple Made Easy [1]. That doesn't mean everyone agrees with his definitions, which is why he revives the word "complected" to mean objective interleaving of concepts, and pulls out "hard" from the way people use complex to mean something one is unfamiliar with. I like his definitions, so I use them. :)
> Sometimes it refers to the number of steps a given algorithm takes to compute
This can still create ambiguity since it could be either time or memory complexity, but still easy to infer, especially if there's a big O.
> depth and breadth of a program's syntax tree
Lisp overloads the parens for difference concepts, which is complex. This could also be hard if one's not familiar with the syntax.
> tendency to branch out and create cycles
Sounds like time complexity!
> Sometimes it's mistakenly used to refer to concepts which are in reality simple but merely unfamiliar or non-intuitive.
This is the ambiguity, is he saying Haskell complex because it has a lot of interleaving with it's concepts, that other languages do not? Or is it just unfamiliar? I would think it's simpler because it forces one to think about how time interleaves the program, which could make things harder! I'm guessing this is what the grand parent means, since ML is impure. Though, either case is empty without examples.
In general, use of highly overloaded words is ambiguous in these discussions.
I'd caution against referring to all such explorations as complexity. Complexity is a highly overloaded term in our field. Sometimes it refers to the number of steps a given algorithm takes to compute (as a function of the input). Sometimes it refers to the depth and breadth of a program's syntax tree as well as its tendency to branch out and create cycles.
Sometimes it's mistakenly used to refer to concepts which are in reality simple but merely unfamiliar or non-intuitive. This last usage is a big problem for languages outside the mainstream which are trying to find better ways of writing software.