You may find this series worthwhile http://www.ibm.com/developerworks/library/j-ft1/
Onor.io
kostonstyle
g4143
In my programming evolution I went from knowing it all in C/ASM and then proceeded to C++ and other OOP and languages and thought I knew it all. I’m now trying to learn functional programming with a new and correct attitude that I know very little to nothing and I find that attitude helps with the preconceived notions and arrogant feelings of - I already know that. I found once I took the advise of most intro functional books - forget everything you know about imperative/OOP programming before beginning functional programming - I was able to grasp the many, many simple concepts encouraged in functional programming…
Its true. If you can drop all your preconceived notions and proceed with a bare slate then you can move at a steady place in functional programming. If you drag your imperative/OOP practices into functional programming then you can expect a rough ride that will only confuse you.
1
vasspilka
For a funcion to be considerate pure two requirements MUST apply.
- there must be absolutely no side-effects.
F(x)=ymust always be true for any x. (will explain further down)
The first one is probably the easiest to grasp what it simply means is that a function must get some input do calculations and produce an output without interfering with anything else. If this was always true for Elixir/Erlang we would have to say goodbye to messages. As any message is essentially a side-effect.
F(x)=y means that the function with these specific arguments is essentially equal to its resulted output. Lets say you have the following function
def hello(name), do: "Hello #{name}"
You can replace hello("John") with the string "Hello John" and the program would be working perfectly. However consider the next example.
def greeting(name) do
cond do
Time.now.hours > 18 -> "Good evening #{name}"
Time.now.hours > 12 -> "Good afternoon #{name}"
Time.now.hours < 6 -> "Good night #{name}"
true -> "Good morning #{name}"
end
end
## Time.now.hours does not exist and in fact is the exact oposite of a pure function,
## we can see how using impure function can spread the impurity along
We can easily see that everytime we call greeting("John") there is a big change we get a different output, we cannot simply replace it with any of the strings in the function and be sure its going to work as intended. To make this function pure we would have to supply the date as an argument, like so greeting("John", "20:45") now we could safely replace this call with "Good evening John" and everything would be fine.
Finally consider a function that takes an input sends a message and then returns a tuple.
Considering the function was pure we could replace the function call with the tuple, if we do that however the message would never be sent therefore the function call and its output are not equal.
For a language to be considerate purely functional, it must not only allow the above two requirements but it must enforce them.
While in Elixir/Erlang one can write purely functional programs it is the norm to allow some side-effects for effectiveness.
Other languages like Haskell use monads to address these issues and retain their purity, but you should ask someone else about this since I have only the slightest idea of how it works.
2
OvermindDL1
Monads are actually a very simple concept (as the 50000 tutorials state but are still being made, that shows how easy they are! /s), let me try a simple description without using code. It is just a container for carrying state around in an immutable way. Think of an implicit hidden argument being passed around function (in an elixir’ish way or a global ‘this’ in OOP languages) that things can return new versions of.
1
g4143
So much hype has grown up around monads that they have become mythical in nature. Monads just bury state in a shallow grave.
This probably the best description of them…
2
peerreynders
José Valim: Beyond Functional Programming with Elixir and Erlang
functional programming is not a goal in the Erlang VM. It is a means to an end.
Erlang (and Elixir) are practical languages and there is nothing wrong with that. If you are interested in the History of Erlang - Joe Armstrong: 26 years with Erlang or How I got my grey hairs:
Here it becomes clear that some of Erlang’s roots actually come from Prolog (that is where all the emphasis on pattern-matching comes from), a declarative, logic programming language that doesn’t even support functions. But the issue of this topic is “Thinking Functional”.
It is often asserted that it is possible to apply “functional practices” in traditional imperative languages but in my personal experience that is not an efficient way towards adopting “functional thinking” because the imperative escape hatch is always so close by. Even in Haskell it is possible to write in an imperative style - the difference is that it typically sticks out like a sore thumb (so you better have a good excuse ready 
) - Haskell is functional by default since it is based on lambda calculus. Learning Haskell is a bit like going to the (functional) language immersion school - everybody gives you dirty looks when you revert to your familiar imperative ways.
That being said Haskell is probably too much of a “full frontal assault” if one has had very little exposure to “thinking functionally”. In my personal case Clojure (a Lisp dialect) was the first successful wrecking ball to chip away at my imperative mindset - if one has no Java development background then it may make sense to look elsewhere (however I think it is important not to get too enchanted with Lisp just because on the surface “it does everything I need to do” but one should certainly learn to appreciate and wield it (certainly come in handy with emacs)).
Now I’m no static typing bigot - but in my personal assessment dynamically typed languages like Clojure, Erlang, and Elixir may not push the programmer/designer enough to actively “reason about types” (and their “compositionality”) in the same way strong static typing in Haskell tends to. Of course ultimately this leads down the path to Category Theory for Programmers.
At the very least there seems to be one repeating theme for “things I wish I was told before I started” - “Dialyzer”, e.g. Bernard Duggan: Erlang in production: “I wish I’d known that when I started”
For the time being I simply view concepts like semi-group, monoid, functor, applicative, monad, etc. as “design patterns on steroids”. Actually design patterns from the OO realm (as helpful as they can be) are more like “sloppy laundry lists” compared to these concepts. Basically design a type that strictly observes the identified “laws” (constraints) and enjoy all the other guarantees that go with it by default. Often people get too hung up on one particular instance (e.g. the IO monad) and a particular use case (e.g. dealing with side-effects) and never stick around long enough to understand the full scope of power that these abstractions can yield (on the flip-side dwelling too much on them probably will end in “type” analysis paralysis - but balance is key, as always).
When it comes to “thinking functionally” it may also make sense not get too fixated on one particular language (it’s always handy to have a secondary) but to also have a look at those languages that hang out in the same neighborhood - but are just a little bit different.
Garrett Smith: Why The Cool Kids Don’t Use Erlang
In the case of Elixir you could work with Phoenix on the back end but use something like Elm, PureScript or BuckleScript to further push the envelope of the “functional programming experience” on the front end.
5
StefanHoutzager
Just on the incorporation of functional programming in languages like java and c#: http://queue.acm.org/detail.cfm?id=2611829 (Erik Meijer: “Mostly functional” programming does not work)
1
mkunikow
There is no 100% pure functional language. You will always need to deal with state and side effects.
But there should be clear separation in code: pure functions vs rest.
0
Qqwy
TypeCheck Core Team
@mkunikow: It depends a little on your definition of ‘functional purity’. There are some implementations, most notably Nock/Urbit comes to mind, that simply says ‘as far as code on our platform is concerned, there is nothing outside of the platform. Therefore, all function calls can be considered pure, and data structures can be made persistent.’
Other languages, like Haskell, that are basically syntactic sugar around the mathematical lambda calculus (which is pure by definition) preserve purity when dealing with side-effects by returning an object that represents a changed state of the world (It’s basically a reminder stating ‘Look! This was the second time I did a change!’). These values, which are of type IO in Haskell, can be used to chain multiple side-effectful operations together in a fixed order. This is necessary because there otherwise is no way to know in what order the functions are called, as this happens lazily. (more information on the Haskell wiki)
Can this be considered pure? Most people think yes, but of course this is subjective.
It is an interesting fact that the operations used for ‘passing the IO baton’ around together form a Monad, but you do not need to know how monads work in order to use side effects in Haskell.
If people want I can write a little introduction to how Monads work. Of course, it is very easy to fall for the ‘Monads are like Tacos’ fallacy: It is a very abstract concept, and an explanation that worked for me might not work for you.
Nevertheless, I think I can make a stab at it, using some great analogies with Fruit Salads and cooking that have their origins in the fun_land package.
0