MonAaraj

Immutable fanatic. That means you can't stop me from talking!

These languages aren't just about first-class functions.

It isn't uncommon to see arguments on the internet about what Functional Programming encompasses, and what it is. They usually come and go like the wind, without a proper conclusion to be made. Because, well, nobody feels strongly enough about it in the Functional Programming communities to try to establish a conclusion. Uh, except me. Usually, the discussion starts because someone uses JavaScript to code in a “functional” way, and then it goes on from there; I think it's important to label such discussions as having a few sides, and the relevant ones are the ones that are willing to keep FP an encompassing term, so in their point of view, every single language that has first-class functions passes the mark as an FP language. That includes C++, Java, JavaScript, Elixir, OCaml, Haskell, Lambda Calculus, Rust, and more. The other side, they plan to restrict FP to not just be about first-class functions, but also to add in important features in such languages, like pattern matching. These people (and probably the previous ones as well) think that languages in terms of paradigms are sliders. While you can code in an FP way in Java, it would prove painful and annoying than coding in an FP way in OCaml. And some of these people consider the worse ones to not be FP, so it excludes Java, C++, and likely JavaScript too.

I think both are very reasonable, but I just can't help but think that the FP term is still important as it is, even though by it's namesake, it means about nothing at this point; because having first-class functions is very important to be able to make programs in a reasonably easy way. Plus, I think adding a new term here would be incredibly useful, especially if it fixes the issues that the FP term has. In my opinion, upon inspecting the term “Functional Programming”, one of the key issues that arise are: 1. Heavily subjective: People really like to limit or expand what it means based on their preference. 2. Too vague: Languages with first-class functions are everywhere at this point, and it isn't really descriptive of most of the “FP” considered languages these days. 3. Unhelpful: Usually, terms like these are used to point to a specific class of languages. Because of the above issues, it makes it slightly difficult to understand specifically what someone really means by it. Because of this, I think that a new term should be created to encapsulate everything that we think about when we talk about “Functional Programming”, but aren't just first-class functions. And I think upon all the languages I'd consider to be “functional” are: Haskell, OCaml, Coalton, Idris 2, Agda, Ante, ATS... And after looking at every deficit I can, I think I understand one thing that is the source of everything I like out of these languages: Expressive types. Let me explain. One of the reasons these languages shine in my heart, is because they insist on having correctly typed programs, in a very strict manner; And unlike your Java or C++, they give you the best tool of all: very expressive type systems.

Really, in all of those languages, the one thing I would never want to give up is their type system. Product types, Sum types, Functors, Applicatives, Monads, and more. That, and (well, most of them) have common structures embedded as well, such as Monoids, which make creating programs that utilise these structures extremely easy. And finally, in every single one of them, you have “special techniques”. Optics, Algebraic Effects, Extensible Effects, Functional Reactive Programming, and so much more. All of these are magic tools that the expressive type system gives rise to, and it's really beautiful; it's also the main reason I use these languages.

Thus, I think I have found a solution. Just call them ML-like languages!

Just kidding. Though, that's a very useful way to point to these languages. Use it!

It's really hard to “create” such a term by oneself, even without many other people's input, but I think it's also important to create one. The acronym I chose is Expressively Typed Functional Programming. Of course, that term doesn't include everything I have just described, but in my opinion, all of those things are symptoms of having really expressive type systems. Of course, now, my definition isn't quite perfect, because it excludes some programming languages that might not make other people fans of it. Specifically, it excludes Scheme, Common Lisp, Elixir, Rust, JavaScript, C++, and Java.

Honestly, I think the most important language here is Elixir, but excluding it isn't some coincidence; It's excluded by the definition because the type system isn't really one of it's strong points, and I'm very fine with that. ETFP should not replace FP as a term; only compliment it to make communicating with genres of programming easier.

Of course, it's still kind of subjective about what really is an expressive type system, but I think excluding Rust here and including OCaml (the language that barely geeked out qualifying) says a lot about how I interpret it as the person who created this term. Rust's type system, while still more expressive than a lot of the other procedural languages, still isn't expressive enough to do a lot of useful things I described. Missing higher kinded type variables, the ability to express functors easily, are really big things that make Rust really incapable of the “engineering” I explained earlier, like algeffects, or exteffects, or encoding effects in the type system, etc. That, and I really dislike how it has a lower class support for generics than the other languages.

And also, Rust is procedural. That negatively impacts the type expressiveness by a LOT. It's really no surprise, I mean, I think there's something about the procedural paradigm that really goes against having expressive type systems, though I'm glad Rust managed to have a decent one.

Looking forward

I think, in the future, with all of this in mind: the next logical step would be to jump into the gigantic rabbit hole that dependent typing is. Of course, it's really the most expressive type system to date! Though it's very sad how little such languages are used for general programming, despite how helpful they are in these cases. If only dependently typed languages get some sort of a boom in the next couple years.