Here's the problem I have with this: nearly everything I do involves state. It's called a database.
Let's take a simple example, a to-do list. Abstracted out to its essentials (a piece of paper), the to-do list is exclusively state. Add a task, complete a task.
Now, I can write a program that manages a to-do list in a functional language. There are two options. (Let's assume this is a web app.) First, I can make the client manage the state. Each time they use the application, they bookmark the last page. This is obviously inconvenient, but it's pure. Every input has a distinct output. Send the entire to-do list and what you wish to add or complete as input, receive an update copy of the state in return. It's always immutable state. It's also inconvenient if you ever want to use this on another computer.
So, like most to-do lists, we use a database on the server side to manage the state of the application. However, you've lost the entire benefit of immutable state! You are not guaranteed to get the same output given an input. We're back to square one, aren't we? What's functional about mutable state?
Now, in a subset of programs, eliminating mutable state is beneficial. 99% of scientific programming would be best served by FP. However, I've never seen an answer to how we can still call any system functional once we add a database.
And at that point, why aren't we using a language that is bad at what we expressly need in the first place?
Programs have to have state and side effects to interact with the outside world. That's not what's frowned upon.
The goal with functional programming is to try and minimize the number of functions that involve those external transactions. The spine of your program in Haskell will revolve around IO, but all the limbs can probably avoid requiring anything more than inputs and outputs.
Perhaps a concrete example would help? Imagine parsing incoming HTTP requests on your TODO app. Ignoring streaming (which I think we can do safely in this case), your IO code is to read and write to the socket, but the intermediate code to parse the incoming request into data structures for inspection? That can and should NOT be dependent on I/O. Similarly, the code that actually generates your HTML output (before writing it to the socket) need not care about I/O.
Functional programming isn't just "no effects." There are many parts to functional programming: there's the idea of functions as the primary means of expressing data/information (as opposed to e.g. objects in OOP), the idea of functional purity (which is obligatory in Haskell but merely preferred in ML or Scheme), the various degrees of static type-safety, expressivity and power (e.g. Haskell with extensions is powerful but not always safe, Coq is safe and expressive but necessarily limited in power, Scheme is dynamically typed), as well as a handful of other concepts which appear from time to time. Even OOP isn't necessarily a conflicting paradigm, see OCaml or Common Lisp's CLOS system for the intersection of objects and functional programming. For more radical ideas, look at e.g. Functional Reactive Programming for functional data-flow programming.
w/r/t the specific side-effects in pure-functional programming: in Haskell, functions which perform effects are specially marked in the type system, so a function which performs side effects can call another one which performs side effects, but non-effectful functions can't unexpectedly induce effects. You end up writing programs with an effectful core for e.g. the manipulation of the db, and non-effectful functions for whatever processing you need to do with the data, with compile-time guarantees that the processing functions can be tested in isolation and won't cause exceptions or do unexpected IO.
Of course, you can write imperative code in a functional setting, and you can write functional code in an imperative setting. There's an old saying that bad programmers can write FORTRAN in any language; you can also write Lisp in any language, or Haskell in any language, with varying degrees of effectiveness or utility. Functional programming partisans—myself included—assert that functional techniques, correctly applied, can reduce errors (c.f. the Compcert C compiler) and simplify writing good code (c.f. the functional implementations of the Actor model of concurrency, parser combinators). I don't personally believe it to be a panacea, but it puts another tool in the toolbox for whenever your existing hammers aren't solving your problem.
It seems you didn't read my post at all, because this is a complete non-sequitur. Look at the only sentence in which I emphasized a word and notice that it is exactly the same as the opening sentence your rebuttal.
This tells me that you are operating off of some mental model of what you've heard from FP proponents in the past without actually giving what I said proper consideration. The irony is that in your other comments you decry the religion of such debates with FP proponents, but in this case you are the one bringing a religious view. Nowhere did I say that FP languages are generally superior for real-world problem solving.
I'm not the one you replied to originally. You're right, it was a non-sequitur, but mostly because it was a question I'd had since I took a functional programming class in college, and never saw an answer that sat well for me. One of the other commenters gave one, so rather than contribute to the noise I just stayed silent and upvoted.
I was just taking advantage of a heated discussion to get an answer. :)
Of course, most of useful software involves input and output and state. Functional programming doesn't preclude that. There are compilers, package managers, documentation systems, etc, written in Haskell. They all use files and databases. Of course, your programs have to be designed differently.
For reference, here's is a talk by Don Stewart et. al about the design of XMonad:
Let's take a simple example, a to-do list. Abstracted out to its essentials (a piece of paper), the to-do list is exclusively state. Add a task, complete a task.
Now, I can write a program that manages a to-do list in a functional language. There are two options. (Let's assume this is a web app.) First, I can make the client manage the state. Each time they use the application, they bookmark the last page. This is obviously inconvenient, but it's pure. Every input has a distinct output. Send the entire to-do list and what you wish to add or complete as input, receive an update copy of the state in return. It's always immutable state. It's also inconvenient if you ever want to use this on another computer.
So, like most to-do lists, we use a database on the server side to manage the state of the application. However, you've lost the entire benefit of immutable state! You are not guaranteed to get the same output given an input. We're back to square one, aren't we? What's functional about mutable state?
Now, in a subset of programs, eliminating mutable state is beneficial. 99% of scientific programming would be best served by FP. However, I've never seen an answer to how we can still call any system functional once we add a database.
And at that point, why aren't we using a language that is bad at what we expressly need in the first place?