Don’t Be Scared Of Functional Programming (smashingmagazine.com)

Nah, FRP is fundamentally about continuous time.

> That's the point of declarative programming and FP is declarative.

Declarative programming is a gradient. You can be exposed to a bunch of tedious details in FP and you can abstract over them in OOP. Saying FP is somehow magically declarative (as if that were a thing) leads to profound disappointment when complexity is inevitably encountered.

> It's the same in Prolog, I'd think.

"Cut" it out :) Also see taming space leaks in Haskell.

> There's no state to speak of. FP builds the blueprint of the program (one level removed from the way OOP and procedural see things) and gives it to the computer to run it.

The primary difference between pure FP and OOP is identity: there is no identity to speak of, things don't have names or addresses, they are just values whose equality is determined purely by structure. The inability to name things in FP is a huge drawback, because things actually have names in the real world.

State doesn't depend on ordering. It depends on time; imperative and even functional languages often convolute the two concepts, but not always (see real FRP, not fake FRP ala Rx). Functional languages eschew state are merely eschewing the notion of time, which makes equational reasoning hard; it takes something like FRP to bring time back into the fold by making it explicit. Still, its quite hard to program interactive apps in pure FP given the intrinsic aversion to time.

Yes of course, I did not mean to imply there are only those two (that would be weird for the two to be "lists" and "functions" out of all things).

What I mean is the current mainstream languages are not the best of any category, like Haskell is up there for functional programming and lisp is up there for s-expressions. C++ is not the best for controlling details (see Rust, D, etc), in fact it's quite a broken language. I doubt Fortran is better at matrices than APL (in fact APL is arguably the best in the matrix category) and so on.

That's the problem. These languages that are best in their categories are many many times better than the mainstream languages of today, which aren't the best in any category they represent.

That's actually not simple at all because it assumes an implementation, that is, a machine with RAM that changes.

For instance, what does = mean between domain and email.split ? Who is equal to who? That question is a question that students sometimes have. You have to explain that Time is implicit in the code, and that an equal sign works by making the thing on the left equal to what the thing on the right was just before this line. So now there's a concept of Time and that's how things start to get very complicated, because it is implicit in your code.

Then, what does ".append" mean? I mean, you call append, but now you don't assign the result to any variable? And what would it mean if you said domains = domains.append(domain), then we really need to have a talk about the hidden Time.

So it only seems simple because it's familiar to you; so in fact I believe it's not simple at all.

But this I believe it's simple, and my fishing boat engine above would've benefited from this:

https://www.fpcomplete.com/tutorial-preview/4217/4k7kq6jGUE

If you look at that code (you can also click play to run it) and then look at the explanation again, could you please tell me what doesn't seem simple?

Edit: let's not forget your Python example uses a map, disguised as a for loop. That for is a keyword, but backstage it's just map where email is the element, emails is the list, and everything you write inside that scope is the function that gets passed the element each time (except in your case the function (i.e. the loop body) can also see the whole list, which is prone to bugs).

    def fn(a,b):
        return str(b) + a + str(b)

    reduce(fn, [1,2,3], "0")

    Start with "0" (we call this the accumulator value)
    Read the first element of the list (1)
    Pass "0" and 1 to fn
        Turn 1 into "1"
        Stick it on the front and back of "0"
        Return "101".
    Use "101" as our new accumulator value.

    Read the next element of the list (2)
    Pass "101" and 2 to fn
        Turn 2 into "2"
        Stick it on the front and back of "101"
        Return "21012".
    Use "21012" as our new accumulator value.

    Read the next element of the list (3)
    Pass "21012" and 3 to fn
        Turn 3 into "3"
        Stick it on the front and back of "21012"
        Return "3210123".
    Use "3210123" as our new accumulator value.

    Notice that we've reached the end of the list, return our latest accumulator value.

I think the main difficulty in converting your example to a functional style is how to express the idea of a for loop which builds up a result as it goes along, without using a mutable variable to store this result. Here's an attempt to explain how that the ideas in the parent are helpful in solving that problem.

You can think of the body of a for loop in python as the body of a function. In that case, a for loop is like the built-in map function, which applies that function to every element of the list. So convert your for loop into:

  def body(email):
    domain = email.split("@")[1]
    if domain not in domains:
        domains.append(domain)

And instead of a for loop we can use the standard function, 'map'.

  domains = []
  map(body, emails)

Now, obviously the data here isn't immutable. But what if, instead of changing 'domains' every time the function is called, we passed in the current value of 'domains', and returned a changed value, like so:

  def body(domains, email):
    domain = email.split("@")[1]
    if domain not in domains:
        return domains + [domain]
    else:
      return domains

Then, we could apply this function to each element of the list in turn, passing the current list of domains at each stage to the body. This is the standard function 'reduce' in Python (which the parent calls by its other common name, 'fold'):

  domains = reduce(body, emails, [])
   

You could think of 'reduce' in python being implemented like:

  def reduce(func, l, currentResult):
    for item in list:
      currentResult = func(currentResult, item)
    return currentResult
    

Or, it could also be implemented recursively, which means it wouldn't need to use mutation internally:

  def reduce(func, l, currentValue):
    if len(l) == 0:
      return currentValue
    else:
      return reduce(func, l[1:], func(currentValue, l[0]))
      

Many for loops that build up a result can be expressed instead using 'reduce', so reduce is one of the most important building blocks of functional programming.

Here is some scala code does the same thing

FileIterator("input.txt").map{_.split('@').last}.distinct.toFile("output.txt")

Lets compare it to the Python version. It looks much shorter, but many constructs are similar to what you wrote and it can be argued that the Scala code is merely a rearrangement of the tokens in the Python code. So let us explicitly call out the tokens/items I did not use in the Scala code, but you did in the Python code.

domains = [] domains.append(domain) out.close() infile.close() // I think you missed closing the input file, a handle leak bug

The map method encapsulates the construction of the output list and the FileIterator and toFile methods encapsulate the opening and closing of files. In particular, the Scala code hjas no handle leak bug. What functional languages are really good at is abstraction. map has abstracted away iteration and construction of an output list, while the file handling methods abstract away resource usage. As programs get bigger and more complex, this power of abstraction becomes increasingly powerful.

(Note that FileIterator and toFile are constructs that I wrote for myself a long time ago, differing constructs are available in the Scala std lib)

In functional style, but still in Python (given that python method calls are equivalent to function calls with an additional first argument of the receiver object, and indexing is equivalent to a method call) -- this uses mutable objects, but doesn't actually rely on mutating them:

  addEmail = lambda |doms,email| doms.union([email.split("@")[1]])
  domains = reduce(set(),addEmail,open("file_with_emails.txt","r")))
  open("file_with_domains.txt","w").writelines(domains)

(Loses order because of use of set for deduplication; you could do it with a list and keep order, but then addEmail becomes more complex, and I don't think its strictly necessary to illustrate the general process. Also, its not clear to me that order-preservation is really part of the intended function here or just an artifact of the implementation. Note that this could be a one-liner, its just split up into three lines with two as assignments for readability.)

And, more how I'd really write it in Python (which is also functional, though perhaps less obviously so, and leverages Python set comprehensions):

  domains = { email.split("@")[1] for email in open("file_with_emails.txt","r") }
  open("file_with_domains.txt","w").writelines(domains)