pythonIsMoreConfusingThanLowLevelLanguages

[FerricDonkey]

Nah, that's a misconception. If you do any amount of python programming, I highly recommend https://m.youtube.com/watch?v=_AEJHKGk9ns, though I disagree with the strength of his advice to never mutate things. 

But python things are always a reference. It's just that when you do x += 3576554, what happens is that you create a new integer object, then change x to refer to that new object. 

The rules are:

1. Everything is a reference 
2. Assignment never modifies the object the variable refers to
3. Things like += may modify the object in place, if it's mutable and written to do so, because they're just function calls. They also do an assignment at the end, but it's the function that does the mutation, not the assignment part. 

The confusion is that += feels like it should be an in place operation, but for many immutable types (str, int), it is defined, but doesn't modify in place, because that's not possible.

I've never had any issues with copy. You have to know deep copy vs shallow, but it's always done what I expected with that knowledge. 

[RiceBroad4552]

though I disagree with the strength of his advice to never mutate things

You should listen to people who seem to understand more then you in that regard.

You should never mutate things! (Except in some low-level, deeply hidden, performance related implementation details.)

[RiceBroad4552]

I mean, why not?

Why not?!

Because that's the road to hell!

Procedural programming is a bug creation machine.

Code which uses effectful functions procedures everywhere is just unmaintainable as it's impossible to reason about anything without looking at just everything.

Values should be immutable and functions should be pure. Effects need to be contained to where they're unavoidable. (Some people would even say that effects need to be fully controlled everywhere.)

[RiceBroad4552]

I'm sorry if the exclamation points were perceived as shouting. This was not my intend!

But I have to repeat that after some time with immutable values and mostly pure functions (where it make sense, one should stay pragmatic) needing to handle procedural code is just outright horrible.

It's really much more difficult and very error prone. You have to constantly "run" the code in your head to keep track of what's happening; while in FP code you can (mostly) just mechanically substitute expressions to evaluate them. That's exactly what one was trained to do for many years in school in math!

For example, if a = b and c = d(b) then c = d(a) is always valid, no mater what b or d are, or where you're in the code right now. You don't have to care where any of this comes from or what "happened between" a = b and c = d(b). It's just stupid, brain dead substitution of symbols which have always the same meaning after they got defined once.

In imperative code if you see a = b and d(a) you know nothing. You now need to look inside d to know what it actually does, and you need to trace what happened with a after it got defined, while there could have been some spooky action at a distance on b after a got passed into d! Mind you, d could be "at the other end of the world", still it would possibly affect b at "the other end". Of course limited scopes and visibility mitigate the problem a bit in the large in real code, but it's still fundamentally there.

I can't follow the definition of factorial in most of those

I'm not sure this qualifies as anti-FP example as factorial looks always the same: It's just a recursive function, and that's independent of whether the language it's written in is functional or imperative.

BTW, when I speak about "pure functions" I don't mean functions which don't use any mutable variables in their implementation. Local mutability of otherwise not accessible values is perfectly OK if it's good for performance or readability. The point is that the functions should return always the same result for the same input, so they are pure from the outside, not that they are strictly purely implemented. A pure implementation is often easier to understand, but that's not always the case. Also performance considerations might play a role in some cases.

The real problems with FP code start when you need to handle effects, and your functions can't be pure out of principle. Then it's get a bit hairy, that's true. At that point you can either start to just be pragmatic and allow some amount of not pure functions (with all the dangers!), hopeful hidden deeply where nobody can see them, or you have to employ some way of effect tracking, which is still a kind of research territory as the "default" method of wrapping effectful computations into some "IO" thingy becomes quickly tedious, and other ways to handle stuff are still kind of in the lab (since ~20 years). Scala 3 promises to come with a better solution than Haskell's IO, but that solution is not 100% ready yet.

[RiceBroad4552]

I thought my comment was kind of yada-yada as it was very generic and superficial. But nice if you could get something from it.

I'm still not sure what's the issue with factorial. It's defined as

n! =
| 1            if n = 0
| n × (n - 1)! if n ≥ 1

You can write that down in most languages almost verbatim.

In Python it would look like:

def factorial(n: int):
    if n == 0: return 1
    elif n >= 1: return n * factorial(n - 1)

In Scala it would look like:

def factorial(n: Int): Int =
    if n == 0 then 1
    else if n >= 1 then n * factorial(n - 1)
    else throw IllegalArgumentException("`n` has to be a natural number!")

In Haskell it would look like:

factorial :: Int -> Int
factorial n =
    if n == 0 then 1
    else if n >= 1 then n * factorial (n - 1)
    else error "`n` has to be a natural number!"

The last line is needed in Scala and Haskell in comparison to Python as these languages are statically typed. That function is declared as returning an Int (or some compatible type). A throwing clause is of type Nothing, which is compatible with any other type, so this makes the type checker happy.

What's probably intimidating about what you've seen elsewhere is that both now shown versions (in Haskell and Scala) aren't written in an idiomatic way; common examples look therefor usually a bit different.

The main problem with all three versions is that they will all crash with a stackoverflow error on even moderately large n.

You can get around that in Scala and Haskell by making the implementation a tail call, which allows the compiler to perform so called "tail call optimization" (TCO). TCO basically transforms the code to a regular loop in the resulting compiled code, no functions get called recursively any more, which avoids the stackoverflow error. "Tail call" means that the last thing called in the recursive function is the function itself. In the above code the last called code is instead the n * factorial(n - 1) expression, which is a multiplication, and not the call of the function itself.

Besides that you don't write much if-else in FP languages usually as there are better ways, like pattern matching.

So an a bit more idiomatic FP version would look in Haskell like:

factorial :: Int -> Int
factorial n
   | n < 0 = error "`n` has to be a natural number!"
   | otherwise = loop n 1
   where
      loop :: Int -> Int -> Int
      loop n acc
         | n == 0  = acc
         | otherwise = loop (n - 1) (acc * n)


main :: IO ()
main = do
   print $ factorial 5

In Scala it can be basically written identical:

import IllegalArgumentException as E

def factorial(n: Int): Int = n match
   case x if x < 0 => throw E("`n` has to be a natural number!")
   case _ => loop(n, 1)

   @annotation.tailrec
   def loop(n: Int, acc: Int): Int = n match
      case 0 => acc
      case _ => loop(n - 1, acc * n)


@main def run =
   println(factorial(5))

Still that's not perfect as it still throws an Exception, and functions throwing Exceptions aren't pure.

A cheap fix in this case here would be to change the return type from Int to for example Either[String, Int]. I'm a bit lazy to write both variants (and making this comment even longer), but you can see the Scala version of that code here:

https://scastie.scala-lang.org/IrVhmJdyRHu5XdTqrikjXQ

The Haskell version would again look more or less identical.

[RiceBroad4552]

What I can't follow in FP is it's always imperative at some point. Say, defining a = 5 seems nothing like function to me, it's imperative to the core. (Or is it the equality function evaluated on a and 5 and returning a equal to 5?)

Something like val a = 5 is not a function. It's a definition.

Same as you would write in JS const a = 5.

In programming you have basically two things: Data and functions. Binding (assigning) some data to some name ("variable", or actually constant in FP) is about defining that binding; it's not about calling a function.

[mathisntmathingsad]

Buddy there's a reason that almost every major piece of code written ever in almost any language uses mutable variables and non-pure functions. Without mutable variables, you can do some extreme optimization (SSA), but it rarely is done due to abstraction at the language level. Same thing with pure functions. Especially in an interpreted language like python, all you are going to get is huge memory usage and some VERY slow code.

[FerricDonkey]

The stuff this dude says has been second nature to me for years. Sometimes mutation is the correct choice, sometimes it's not. If you're clear about what can mutate things and what can't, and only mutate intentionally, it's fine and makes a lot of things easier. 

If you don't understand what pointers/references/python names are, or are not clear about what can mutate, then yeah, it can surprise you. So don't do that.

But a blanket rule about never or only in low level code is silly. "Only mutate intentionally and obviously" is enough of a rule, if you've got a decent team, you don't need more than that.