The masses agree with you, apparently. That's why they sit in their cubes all day writing the same god damn re-implementation of map over and over again

    List<String> result = new ArrayList<>();
    for (int i = 0; i < list.size(); i++) {
        result.add(input.get(i).toString());
    }

    input.map(_.toString)

Declarative. As opposed to telling it how to get what you want, which would be imperative.

Beacuse imperative programs are rife with "statements". Opaque lines of code that may or may not do something, somewhere, which cannot be manipulated as first class objects.

Why would you ever wanna program with that weird restriction?

nailed it. I don't know much about functional languages other than a haskell course back in the day, but I don't want to do functional all the time. It plays great in some situations and I am happy to use those language subsets in my daily coding, but I don't need my entire application to be written in an esoteric language

Absolutely. Some problems are just so much simpler in an imperative style that it's worth the lack of confidence you get with the functional solution in its correctness and robustness.

That's why I love languages that have fairly powerful functional features but have an imperative escape hatch. I think more and more languages are becoming that. Rust does it very well, but the lisps, probably Scala, and a few others I'm not thinking of may be better, don't have much experience with those though.

Interesting. Monadic Haskell can be quite imperative if you want it to be, as can SML or OCaml. Scheme and Lisp have imperative parts too.

Yep. That's precisely what it is.

Okay, I'm really hoping there's a good surprise behind this, because I've been an imperative programmer for 10 years and a functional programmer for 5 and I have only rarely seen imperative code that was more concise than equivalent functional code. Faster? Sure. More efficient? I'll buy it. Perhaps even easier to read, especially when you get into point-free style on the functional side. But more concise overall? I find that hard to believe, but I'm genuinely excited now! The ultimate trump here would be APL but that's admittedly an eccentric case.

But there are to be the ways functional programmers solve the same task?

Thank you for the link.

Because it's what you've had exposure to. Perhaps, they're even objectively easier to read and write, I don't know. It's also completely besides my point.

My point was that I want my programs to work as desired. That's orthogonal to how easy it is to read and write. I don't want runtime exceptions where I could've gotten a compile-time error.

You know I didn't say that.

The imperative coding approach is cognitively more difficult. So at scale (size of code-base) you either have more bugs and therefore more overhead/cost of development; or you look for coping strategies to minimise the bugs and the cost of development.

Declarative, pure functional programming reduces the cognitive load, because you get to compose things reliably. And because it's declarative and pure you don't have to look under the hood to see what is going on, you know from the surface what large bodies of code do.

A simple example, two functions prototypes:

One in Java

    int foo(string x);

    foo :: String -> Int

You are of course free to take whichever approach you like. The imperative one is however just going to get progressively more difficult as applications get more complex. I spent 27 years writing various combinations of assembly, procedural, and OO. I've spent the past 10 using the functional paradigm. If I ever had to go back to the imperative paradigm it would fill me with dread. I still need to use it occasionally for performance optimisations, but I would always wrap it with a declarative interface (where the contract always holds).

> As far as I know those "off the shelf engines" are not written in fp languages. And I would say they are complex.

When I talked about 'easy', what I meant was that games development has much less of the real world to deal with:

* You tend to know your user

* The user doesn't get to have a say

* You often know exactly what hardware you're going to be running on

* You don't have to integrate with 20 other systems by 3rd party providers

* To a certain extent you can put it in a box and move on (I know that's not strictly true, but you're unlikely to be maintaining a game for more than a decade)

* The feature-set of the game won't double every few years as the product competes with others

* Most games have a relatively similar management system

* There aren't massively complex compliance issues or laws that get in the way (yes there are some, but less than other industries)

* Although networking and game-state synchronisation is a hard problem, the scope of distributed computing problems are small

A game engine really isn't that complex. Of course it's hard to make it as optimal as possible, but the problem isn't at the real difficult end of the spectrum. Probably the hardest thing in games now is writing the tooling. I spent a number of years writing core tech and tools for a 3 studio games company and that was just at the beginning of the tooling journey. I assume that's quite a sizeable coding challenge now; one I would definitely us FP for if I was still in the industry.

No it's not, objectively speaking. You're confusing simplicity with familiarity.

Ever read a recipe designed for concurrency and/or parallelism? Functional idioms are becoming in vogue at the same time as people are meeting walls when it comes to single threaded applications.

Except that you can be functional and imperative, like Clojure, Erlang and even OCaml. Those are functional-imperative languages (you can even be pure and imperative yet not functional, like Esterel and maybe Céu).

Nope. There is more to programing than the imperative paradigm.

I.. have trouble with this statement. I bet you have, but you thought about it differently. A function that COULD be a pure function but that takes some data structure then mutates it and returns nothing, well that's just bad programming.

Now, wanting the entire program to be functional, that's a different matter.

Is that supposed to be a meaningful statement?

Verbosity is not inherently good. In fact, I think verbosity is inherently bad. Have you read much first-year programmer code? It's absurdly verbose at the cost of legibility.

The real issue is clarity. Your code should be sufficiently verbose that its purpose is self-evident, but it should not be overly verbose such that your screen is cluttered with meaningless junk (see: Java).

---

To me, there is a fundamental distinction between the intents of functional programming and imperative programming that a lot of these articles either gloss over or miss completely.

Imperative programming is about describing to the computer a procedure by which to accomplish a goal.

Functional programming is about manipulating the relationships between data directly such that you transform your given input into the desired output.

If you want to understand what a program does, then imperative code is going to be better to read. But if you want to understand what a program means, then (well-written) functional code is going to be better. This is also why so many functional languages have strong static type systems: to better enable the programmer to express programs' meanings outside of the implementation.

However, as others have mentioned, string manipulation is always kind of hairy anyway, so reading this function will result in understanding what it does instead of what it means (unless you just read the signature, which is actually what I do a lot of the time). My thought process of reading this particular function without prior context would be something like:

- The function is named `alignCenter` and takes a list of strings and gives back a list of strings... so the strings are being centered amongst themselves. I know they aren't being centered relative to anything else because there are no other inputs to the function — which I would not know in an imperative language, where there could be hidden state somewhere. - It maps some function over the list of strings. I assume that function will do the centering. - This inner function takes a string and does something to it. Let's investigate. - We replicate a space character some number of times and prepend the resulting string to the input string. (I think the author's reliance on operator precedence is disappointing here, as it detracts from the clarity IMO. I would rather put the `replicate` call in parens before the `++`.) - The number of spaces is determined by dividing by two some other number less the length of the string. - That number is the length of the longest string.

So: to center a list of strings, we indent each string by half the difference between its length and the maximum length among all the strings. This seems like a reasonable way to center a group of strings. (Notice that I did not use words like "first", "then", etc. which indicate a procedure. Instead, I have described the relationships of the strings.)

(Of course writing it all out makes it seem like a longer process than it is, but in reality it probably took me 10-15 seconds to go through everything and figure out what was going on.)

---

I think this isn't a great example for the author to have chosen. My go-to example of a beautiful functional solution is generating the Fibonacci sequence.

A "good" imperative solution uses iteration and might look like:

    def fib(n: int) -> int:
      a = 0
      b = 1
      while n > 1:
        t = a
        a = b
        b = t + b
        n -= 1
      return b

Now, the Haskell solution:

    fib :: Int -> Int
    fib n = fibs !! n
      where fibs = 0 : 1 : (zipWith (+) fibs (tail fibs))

\*Of course, I'm assuming the reader knows what it means to "zip" two lists together (creating a list by performing some operation over the other two lists pairwise) and what a "tail" of a list is (the sub-list that simply omits the first element).

To me, this data-relationship thing often makes more sense than a well-implemented imperative solution. I don't care to explain to a computer how to do its job; I care to think about how to move data around, and that's what functional programming is all about (to me).

Of course, this is just my subjective opinion, but I think there's some merit to it. I'd like to hear your thoughts!

Probably, you may restructure your code, use curried functions, and you won't need to go through all 10 levels. Transition from imperative to functional programming may looks like untangling a ball of function calls, in order to get simple and clean design.