Stop Using “Functional Programming”
These languages aren't just about first-class functions.
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!
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.
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.