[jimsimmons]

Functional programming community likes this stuff. They go into the classical mathematicians’ trap of writing more and more general versions of something even though it’s not necessary.

[nequo]

I think this is partly because of the syntax.

When we write human languages (that use a Latin script), we use punctuation to delineate the beginning and end of terms. In a language like C or Rust, terms are surrounded by commas, parentheses, angle brackets, and so on. In OCaml and Haskell, many things that there is syntax for in C-style languages are done as ordinary function calls, which separate terms by only whitespace.

It is easier to read this (Rust):

  let value = some_long_ass_function_name(some_quirky_parameter, another_one);

  another_function(value)

than this (Haskell):

  let value = someLongAssFunctionName someQuirkyParameter anotherOne
  in anotherFunction value

or this (OCaml):

  let value = some_long_ass_function_name some_quirky_parameter another_one in
  another_function value

Individual terms in camel case are difficult to read if they consist of more than a couple words. Consecutive terms in snake case are difficult to read because underscores and whitespace look alike visually.

Haskell and OCaml's idiomatic solution is to use extremely terse names for arguments, type variables, and local variables, out of what seems to be syntactic necessity.

[golergka]

That's because of currying. If you want to partially apply parameters, in your example, with Haskell we would just have to do this:

        someLongAssFunctionName someQuirkyParameter

And we get a function that accepts one parameter. But in Rust you would have to do this:

        move |another_one: i32| {
            some_long_ass_function_name(some_quirky_parameter, another_one)
        }

Which is not easier to read.

[nequo]

It is true that currying looks comparatively awful in Rust. But that is not because Rust uses parentheses and commas. A hypothetical C-style language could use dedicated syntax for currying, like

  some_long_ass_function_name(some_quirky_parameter, ..)

which would be more readable without giving up on punctuation.

[ackfoobar]

Scala does that, with `_` being a "hole in the expression". I wouldn't call it currying though.

  func(param1, _)

Every once in a while you have to make some change to that expression.

  // you may want to write
  func(param1, func2(_))
  // but you need to write the full lambda
  param2 => func(param1, func2(param2))

[oblio]

Ah, now I realized, you're right. The lack of visual distinction between different syntactic elements is what's killing me.

[yawaramin]

I don't think this is correlated to functional programming. Programmers in general tend to over-architect because we're often learning as we're going and sometimes it's more fun to use some cool concepts. Since design patterns started becoming en vogue back in the day, OOP codebases got filled with those patterns. Now we are left picking up the pieces with things like `AbstractProxyFactoryBean` or whatever. Same thing with JavaScript where that ecosystem is infamous for using tons and tons of npm packages to recreate simple functionality, e.g. 'left-pad a string'. Arcane mathematics-heavy FP code is just how that expresses in FP languages. And in fact, OCaml is actually an antidote to that (for the most part), because it deliberately offers a lower level of abstraction than Haskell. I frequently say that OCaml is like a cross between Haskell and Go.

[j33zusjuice]

I don’t know OCaml, or really any language that would help me fully understand the code, but my exposure to OCaml is this stuff, and it looks pretty clean to me. https://github.com/janestreet/base

Of course, I haven’t read every file, so maybe I got lucky with my random sampling.

[yawaramin]

It's a pretty practical language, so much so that its creators think it's actually a great language to teach Unix programming, and even wrote a book about it: https://ocaml.github.io/ocamlunix/ocamlunix.html

Excerpt:

> Tradition dictates that Unix system programming must be done in C. For this course we found it more interesting to use a higher-level language, namely OCaml, to explain the fundamentals of Unix system programming.

> The OCaml interface to Unix system calls is more abstract. Instead of encoding everything in terms of integers and bit fields as in C, OCaml uses the whole power of the ML type system to clearly represent the arguments and return values of system calls. Hence, it becomes easier to explain the semantics of the calls instead of losing oneself explaining how the arguments and the results have to be en/decoded. (See, for example, the presentation of the system call wait, page ??.)

> Furthermore, due to the static type system and the clarity of its primitives, it is safer to program in OCaml than in C. The experienced C programmer may see these benefits as useless luxury, however they are crucial for the inexperienced audience of this course.

> A second goal of this exposition of system programming is to show OCaml performing in a domain out of its usual applications in theorem proving, compilation and symbolic computation. The outcome of the experiment is rather positive, thanks to OCaml’s solid imperative kernel and its other novel aspects like parametric polymorphism, higher-order functions and exceptions. It also shows that instead of applicative and imperative programming being mutually exclusive, their combination makes it possible to integrate in the same program complex symbolic computations and a good interface with the operating system.

[still_grokking]

Until they get enlightened.

Related: https://willamette.edu/~fruehr/haskell/evolution.html