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

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.