Generally, yes. Some languages are really hardcore about it (notably Haskell), while others just strongly encourage you to write functions without side effects. Ed: that's the "purity" they're talking about in OP.
The other major neat thing about functional languages is how they let you treat functions like objects, but most modern programming languages have adopted that as well, so it's not a big differentiator anymore.
In theory, writing in a functional language that allows only "pure" functions (aka. functions w.o. side effects), makes it easier to control state.
In practice, side effects exists and are required for programs to do anything useful.
In my opinion, one mistake of many purely functional languages was to be so focused on this purity, that it made it needlessly hard to write useful code in them, especially for people coming from an imperative/procedural/oop style of doing things. And you need these people if you want your method to gain traction, because the vast majority of code written, is imperative.
The irony is, that FP could probably have had a lot more success if it didn't clamour on about pure functions so much, and was less focused on implementations (aka. languages) than on methodology (aka. coding style) Because it is perfectly possible to write pure functions in most languages, including OOP language, even if those functions are not "pure" internally, or are not "pure" all the time and under all circumstances.
And yes, doing so has really nice advantages. I have refactored quite alot of codebases into using a more functional approach, and what I found was that this makes it harder to introduce bugs, makes it easier to track bugs, and makes it easier to reason about my code.
So yeah, functional programming, used if and where it makes sense, does work, and is useful.
> The irony is, that FP could probably have had a lot more success if it didn't clamour on about pure functions so much
Except functional languages like Lisps and the MLs never were pure, the only (used by a significant number of people) has been Miranda/Haskell (ignoring Coq and the other proof assistents).
Or, to put it in other words:
ML (no, not that ML) turned 50 this year, Scheme is oder than 50 too and Miranda/Haskell ~36. There never had been a shortage of "impure" functional languages since OOP existed.
Yes, there have. And not a single one of them was able to even gain a sizeable fraction of the mindspace that imperative languages have, let alone replace or obsolete even a single one of them.
So maybe it's time for FP as a whole to accept the fact, that there seems to be something fundamental about the way it's paraded implementations look and feel like, that puts off a lot of programmers.
Maybe it's time for FP to accept that the paradigm as a whole has a lot to contribute that is useful to everyone, but doesn't need a new language with largely different syntactic constructs to do so.
Strict/constrained things are generally less appealing. That does not mean they are not the right approach. I dont agree with the popularity contest approach though.
Many languages are in use for different things without the need for a language to win. It is a bit anthropomorphic to approach tools like that IMO.
Instead, there has been a healthy influence of more research FP languages into mainstream languages (as you mention), more interesting experimental languages, etc. Aka everything working as intended.
> I dont agree with the popularity contest approach though.
Insofar as it didn't prevent the good parts of FP to become mainstream features, I agree.
But the popularity contest IS important for language emergence. I still believe there would be a place for a functional language that strives to adhere to the principles more stricly, and that programming could benefit from such a language gaining a lot of traction. But, as mentioned before, if such a language requires people to deal with a very different syntax, or applies it's principles too rigidly, it will likely fail the popularity contest.
It also is important for paradigms to become pervasive. As I mentioned, FP has a lot to teach even to OOP people. Writing functional code is a great way to organise a program.
But tell that to a young software developer who has only ever been served enterprise spaghetti OOP pasta with extra abstraction sauce garnished with pseudo-encapsulation cheese, and for whom "functional programming" is something he only saw ridiculed as a meme on some subreddits.
No, popularity isn't the only important thing. But it can help things to reach their potential.
> FP could probably have had a lot more success if it didn't clamour on about pure functions so much
Note that there are many functional languages which don’t care about purity at all: for instance, Scheme, OCaml, SML and Elixir. I get annoyed when people confuse Haskell for the broader paradigm of functional programming. (Even though Haskell is my main programming language!)
An "unpure FP" is a procedural programming language, because "unpure functions" are generally called "procedures".
But people tend to avoid the name "procedural" at all cost - which is bad because procedural programming really has it's advantages and should be clearly separated from FP which also has certain advantages.
If you declare a function effect-free, and try to perform effects inside it, then you'll get a compiler error.
You are still allowed (and it's common practice!) to declare your functions as effectful.
Unfortunately the 'signal' of this message is often lost in the noise: For every Haskeller happily writing effects, there's 9 non-Haskellers writing that 'Haskell's big mistake was being pure and not allowing effects - you should use X instead'.
Functional languages that require calling out side-effects (eg: "\ IO" in Flix) allow you to write functions that are "pure" (aka: they can do no mutation of data or perform IO) and will always give you the same result for a given input. Writing the majority of your code as pure functions makes the code much easier to reason about, especially as the system scales. IMHO, it also makes testing simpler.
It's definitely a different way of thinking and it has a lot of benefits. However, some of the downsides (which Flix seems to fix with region-based local mutation) might be implementing a sort that keeps two copies of a list in memory just to return the second list and discard the first. Depending on your list, this may not be an issue.
The other major neat thing about functional languages is how they let you treat functions like objects, but most modern programming languages have adopted that as well, so it's not a big differentiator anymore.