Hacker News Reader

Comment by Nate75Sanders | Hacker News Reader

Python and Ruby aren't functional languages.

You can write code in them in a functional manner, but for anything more than toy programs you _likely_ wouldn't.

They're heavily Object-Oriented, but could probably safely be called multi-paradigm. Not just "functional", though.

Functional languages are Haskell, ML, others, where you express computation by composing functions (in the mathematical sense). You make lots of copies and you don't modify state directly like procedural and OO languages do where you modify state a lot.

View on HN

I remember it took me a dozen times of carefully reading explanations like this before I finally got what "functional" meant... I'll try to provide an explanation my former self would have easily got.

  lambda x: x+1

If you only program with lambda's like these, your program is functional.

  def dosomething(x):
      y = x + 3 # y is a global variable
      return x + 1

As soon as you have a function like this, your program is no longer 100% functional.

The dosomething function modified `state` when it changed a global variable. Another function that modifies state is "print()". Generally any function that returns nothing is almost certainly going to modify state outside of it. (Otherwise what is the function for?)

State is memory that is not `local` to the function itself.

  def dosomething(x):
      y = x + 3 # y is a local variable
      return x + 1

The dosomething function here is functional, because the only `state` it modified was local to the function.

There you have it.

Even more simply - are you writing code for a von Neumann architecture (http://en.wikipedia.org/wiki/Von_Neumann_architecture ), or something more abstract?

To my understanding the issue is not whether "state" has side effects (e.g. your global vs. local example), but rather whether there is any concept of "state" (e.g. shuffling stuff from one memory slot to another).

My experience is from Prolog, where the statement "X is X + 1" results in an error, because once unified, the variable X cannot be modified - X is not a memory slot. Once you try to let go of the idea of a machine with memory slots, alternative-paradigm programming gets a little bit easier. Of course in practice state is often needed, so it often gets added through some mechanism.

That's a good explanation.

My explanation is catered to people accustomed to the von Neumann architecture, however. :)

Reply on news.ycombinator.com