When I show F# code to non-F#ers, I often get a reaction that goes something like this: “This code looks kind of nice, but we don’t have math problems to solve, so F# is not for us.”
By the way, the code I show typically has nothing to do with math. We don’t solve math problems with F#. We write a business application with it.
So I wonder why I hear this almost every time when I present about F#. Some guesses:
Many presentations about functional programming use math-based language
Oh, I remember when I started looking deeper into functional programming, I found a lot of talks I didn’t understand much. All I heard was Monad, Functor, monadic, and so on. I had a lot of math during my studies, so that stuff didn’t scare me away easily. But to be honest, it didn’t help learning functional programming at all. Luckily, I found presentations specifically about F# that were mostly free of math terms. Thanks, Scott Wlaschin and Isaac Abraham!
Many examples showing functional programming are close to mathematics
I guess that one of the first examples in F# you saw was about Fibonacci numbers. That’s probably true for most programming languages. And I get why math problems are good fits to show the features of F#: Functions, recursive functions, immutable values, pipelines, and easy-to-build lists make for short expressive examples. But overall, they help build a picture of F# that is not complete. By the way, that is one reason why I started with my “Random F# code from our app series” – to show business application code written in F#.
The theory behind F# is lambda calculus
F# is a programming language from the ML-based (MetaLanguage) languages like OCaml or Haskell. ML is based on lambda calculus. But the theory behind a programming language does not define the scope a programming language can be applied.
With F#, you can build small helper console apps, big business apps (backend and front-end), scripts, data-crunching applications, and more.