[callumacrae]

I've done a bit of Haskell when I was working with JSCheck and PHPCheck :-D

[@Tom]

Kyek, on 11 July 2012 - 05:35 AM, said:

Yo, wrong thread for that convo

Don't worry we moved to private conversation

[Kyek]

gibbonweb, on 11 July 2012 - 07:01 AM, said:

Having only experience in C and related languages, functional languages tend to freak me out. Also, I normally don't really "get" them when I try to ... How can I fix that?
Also, why should I even care about functional programming? (no trolling/flaming intended, just a very direct, honest question )

I'm not in deep enough to answer this question fully yet, so take this with a grain of salt -- but one of the core aspects of functional programming is that data is fully immutable. It can exist, it can be garbage collected, but it can never be changed. The only exception to this rule is that you can have a pointer to data that can change, but most of that is abstracted away from the top levels of the language anyway.

What this allows for is writing the routines of the program, and now portions of it can be automatically scaled up or down, run in multiple threads, etc without ever needing to worry about whether an operation is thread-safe or not. Entire processes can fail out (see also: fail-first design) without affecting your app as a whole, or corrupting data. The built-in scalability and failure mitigation is why Erlang is becoming such a popular choice for database servers (like CouchDB and Riak), because it just makes sense. Clojure has picked up a lot of steam because it operates under the same concepts, but runs in a JVM -- so you can compile your app to a WAR or EAR and deploy it in Tomcat or JBoss or Geronimo under and infrastructure that many business already have set up for traditional Java apps. It's kindof a beautiful system.

I think part of why Clojure seems to flow so nicely for me is (and I'm showing more of my geekitude than usual here) I was once-upon-a-time enthralled with the idea of universal spoken languages, and started reading up on, and learning a little bit of, lojban. I swear I'm not as much of a nerd as that makes me sound like. Regardless, though, lojban is set up like function calls. You state your verb, and then you follow it with the arguments to that verb. It's not "I eat pizza", it's

(eat i "pizza")

. Of course the punctuation I used isn't lojban (And for that matter the words aren't either -- just the order of them), but you see how very closely Clojure compares . So if you get into a mindset of speaking that way, much of Clojure becomes natural language programming, which is pretty cool.

/nerd

[TheEmpty]

gibbonweb, on 11 July 2012 - 07:01 AM, said:

Also, why should I even care about functional programming? (no trolling/flaming intended, just a very direct, honest question )

Word is it will be the new OOP

[gibbonweb]

Kyek, on 11 July 2012 - 08:39 AM, said:

I'm not in deep enough to answer this question fully yet, so take this with a grain of salt -- but one of the core aspects of functional programming is that data is fully immutable. It can exist, it can be garbage collected, but it can never be changed. The only exception to this rule is that you can have a pointer to data that can change, but most of that is abstracted away from the top levels of the language anyway.

What this allows for is writing the routines of the program, and now portions of it can be automatically scaled up or down, run in multiple threads, etc without ever needing to worry about whether an operation is thread-safe or not. Entire processes can fail out (see also: fail-first design) without affecting your app as a whole, or corrupting data. The built-in scalability and failure mitigation is why Erlang is becoming such a popular choice for database servers (like CouchDB and Riak), because it just makes sense. Clojure has picked up a lot of steam because it operates under the same concepts, but runs in a JVM -- so you can compile your app to a WAR or EAR and deploy it in Tomcat or JBoss or Geronimo under and infrastructure that many business already have set up for traditional Java apps. It's kindof a beautiful system.

I think part of why Clojure seems to flow so nicely for me is (and I'm showing more of my geekitude than usual here) I was once-upon-a-time enthralled with the idea of universal spoken languages, and started reading up on, and learning a little bit of, lojban. I swear I'm not as much of a nerd as that makes me sound like. Regardless, though, lojban is set up like function calls. You state your verb, and then you follow it with the arguments to that verb. It's not "I eat pizza", it's

(eat i "pizza")

. Of course the punctuation I used isn't lojban (And for that matter the words aren't either -- just the order of them), but you see how very closely Clojure compares . So if you get into a mindset of speaking that way, much of Clojure becomes natural language programming, which is pretty cool.

/nerd

Wait. If data is immutable (which to me sounds weird if we're talking about a programming language, since it's supposed to process data), does that mean that the input and the output of a function coexist in the runtime at any time? I don't know if this statement makes sense. But wouldn't this mean that the runtime eats a WHOLE lot of memory because it has to store all those in-between states of your data when you pass it through 30 different functions? In other words, how is data "immutable" if I want to, lets say, write a "slugifier" which will turn "Süßes Häschen" into "suesses-haeschen"? The latter doesn't exist before the function has been called, so how is this "immutable"?

TheEmpty, on 11 July 2012 - 09:39 AM, said:

Word is it will be the new OOP

I get that part, I just don't get the "getting" part. OOP is something i can natually understand.

[Kyek]

gibbonweb, on 11 July 2012 - 12:08 PM, said:

Wait. If data is immutable (which to me sounds weird if we're talking about a programming language, since it's supposed to process data), does that mean that the input and the output of a function coexist in the runtime at any time? I don't know if this statement makes sense. But wouldn't this mean that the runtime eats a WHOLE lot of memory because it has to store all those in-between states of your data when you pass it through 30 different functions? In other words, how is data "immutable" if I want to, lets say, write a "slugifier" which will turn "Süßes Häschen" into "suesses-haeschen"? The latter doesn't exist before the function has been called, so how is this "immutable"?

Think of it like Java, Javascript, or PHP. In those languages, strings are immutable. You can create a string, and it's stored in memory. You can replace all instances of 'e' with 'a', and instead of modifying that string, it will create a new string in a new memory address. If something still has a variable pointing at the old memory address, that variable still has the old, non-replaced string. But when there are no longer any variables pointing to that old string in memory, bam, the garbage collector deletes it from memory and now that space can be used for something else.

Now let's talk about more complex types. Objects, even though that concept is a little different in most functional languages. Consider this javascript:

var myObj = {
    hello: "world"
};

var yourObj = myObj;
myObj.hello = 'Mars';

console.log(yourObj.hello); // Mars

Again, bear with me, because I still don't have a lot of experience with this in Clojure yet. But the above would only be possible if you explicitly tell Clojure that you want it to point to the same physical memory space, which will never happen automatically. So if you pass an object to a function, and that function modifies it, it will copy the modified sections to a new place in RAM and the pointers to those sections will be local to the function. The code that called the function, then, can ALWAYS count on that variable never ever changing. No testing, no checking for race conditions, the variable will *always* be what you expect it to be, 90 threads or 1. And the second that there are no active pointers to that data in the RAM (or, more accurately, no pointers that are being used ahead in the code), it gets cleared out so you're not maintaining 90 copies of the same thing. RAM usage stays about the same as what you're used to over time, but locally there's more swapping data in/out of RAM to ensure each function owns its own data.

[_Sam]

Ah now I know why you want to learn LISP: http://www.crackingagrippa.net/

[Sephern]

As Kyek said, all data structures are immutable. Adding to that, in pure functional languages you can't cause 'side effects'. What that means is that you can't change any state (for example, properties in a OO language) within a method. In simple terms, if you put something in to a function, you will always get the same value back.

A simple example of this is trivial mathematics. If you take the mathematical function of addition, it has no side effects (it doesn't change any state of the world). If you put 2 values in, then they will always return the same thing (1 + 3 is always 4 for example).

There are 2 happy side effects of this.

1. Things are inherently parallel. Because you can't change state (using side effects), and because all data is immutable anyway, there is absolutely no risk of race conditions. My thread can't change a property your thread is accessing, if neither of us can modify the value. That means you can scale algorithms written in functional languages very, very easily.

2. Because there's no side effects, you can mathematically prove your code. This is almost impossible to do with conventional methods of programming. There's quite a few programs out there that can analyse functional code. While that might not be massively relevant to most people, it certainly is in a few sectors. For example, in the banking industry, where losing a penny per transaction could lose your bank billions - are you going to pay a few thousand more a year for Haskell developers if they can mathematically prove that their code isn't going to lose you money? Of course.

So, as for why you should care - Functional programming languages are very good at parallelism, maths, mission critical things, writing Domain Specific Languages (extended to programming languages), and a few other things. If nothing else, it will enhance the way you think about programming in general.

The word on the street that functional programming is the 'new OO' is ridiculous. Its a completely different paradigm which is suited to completely different things. It falls down to that classical thing of choosing the right tool for the job. There's stuff that Functional languages are obviously a much better choice for. For a ton of other stuff, it makes absolutely no sense whatsoever to use a functional paradigm.



In response to the original question, I've worked on a product professionally with some F# in (not stuff that I was directly involved in writing or maintaining, but it was a small excel-formula-style DSL. Quite cool stuff), and am using it in a personal capacity for Project Euler (more as a learning exercise for Functional stuff).