Erik Meijer: Functional Programming

Posted By: Charles | Jan 18th @ 11:13 AM

I caught up with the venerable Erik Meijer recently to discuss functional programming languages, academic versus real-world application of functional programming languages (there are very good reasons why people don't program Windows applications in, say, Haskell...) and, well, Erik. Why does Erik work here? What's his history?

Of course, as an academic type (he also ships software so he's not purely academic...), Erik is a big fan of strict functional or pure functional, as it were.

This is a deep interview and Erik spends most of the time on the whiteboard.

Enjoy. There's lots to learn in this one...

For those who are bandwidth challenged, here's a low res version for download.

Tags: Erik Meijer, Functional Programming, Programming

Rating:

Views (37,849)

Comments (68)

Downloads

dot_tom

Oh man I've been waiting for this since Brian's video on Monads. Awesome! Big Smile

MetaGunny

This doesn't make any sense at all.

If in order to be truly "pure", why don't we just replace our code with nothing but a bunch of constants?

We could then go around saying I write constants instead of I write code.

I don't understand the thinking that in order to be truly pure, it has to return the same value. Why can't it be pure if it returns the data type specified? I.e., if I say I'm goign to pass you back a string, then you can know for a fact you are going to get a string returned.

Why do we care what the actual value is?

Why would it make sense to have to specify not only the data type returned, but also that it's not a constant value by plaing <IO> in front of it?

Also, what's up with the Let? Why can't we just say x = "whatever"

I think it would be better if you show a sample application, where this type of functional programming language shines.

When we don't want our "world" to change, why doesn't it make more sense to use the concept of Interfaces when needed?

I think the problem with the concept of purity and functional programming, is that it's trying to force programmers into a box of how mathmeticians think. That logic falls apart because the need for a programming language is not simply to solve mathmetical equations.

To step back and keep it simple, rather than talking about how it works;

What problems does it solve?

How does it make programming or the end-result better?

MetaGunny

Let me answer my own question here a little bit.

Where I think this would be useful is as a feature in an existing language.

For example, if you could create a certain type with a certain state. That way, if you have that special type you also know it has a certain state, or a certain value. The equivalent (somewhat) of saying what Erik said in his video of you know you're going to get a certain type and a certain value, but really I mean state.

This would be beneficial in the case of a string for example. Let's say you create a new stringempty type, where whenever you get this value you back you know it will never be nothing.

Why would this matter?

It would eliminate all of the exceptions for people who don't check if string is nothing before trying to call the Trim() method on it for example.

Imagine how many exceptions this would elimnate and how many lines of code it would eliminate.

The bottom line is I don't care if a string is nothing, I just want to get the value, trim it, and see if it's equal or not equal to a certain value.

JChung2006

Why functional programming? See Joe Duffy's video on ParallelFx here on C9 and Simon Peyton Jones' papers on Software Transactional Memory on the MS Research site for a couple approachs to improving the concurrency of applications in this multi-core age we live in.

MetaGunny

I've watched all of the related videos.

However, I'm assuming that you reference reading other material because you yourself don't truly understand the why.

If you did, you could have explained it.

ifeanyie

FP is a toolset that makes some problems easier to tackle and some problems harder to tackle.

You'll get better at your craft as you take the time to learn your tools, what they're good for and what they arent.

I think what is often taken for granted and omitted in these conversations is what real world scenarios certain techiques shine

Here are some places where functional programming concepts are put to good use:

++++++++++++++++++++++++++++++++++++++++++++++++
A nice use of Monads to model async queries
http://www.aboutcode.net/2008/01/14/Async+WebRequest+Using+LINQ+Syntax.aspx
Based on
http://blogs.msdn.com/wesdyer/archive/2008/01/11/the-marvels-of-monads.aspx

Throw in a Maybe Monad or an Exception Monad and you could get robust error handling in there too.

++++++++++++++++++++++++++++++++++++++++++++++++
Benefits of and a series on immutabability in C#
http://blogs.msdn.com/ericlippert/archive/2007/11/13/immutability-in-c-part-one-kinds-of-immutability.aspx

BTW System.String is immutable and that alone removes so many headaches compared to dealing with LPCTSTR or even CString

++++++++++++++++++++++++++++++++++++++++++++++++
The ability to clearly describe and implement certain kinds of computations. (The Monads sample counts toward this)
http://notes-on-haskell.blogspot.com/2007_12_01_archive.html

Take a look around and experiment a bit with languages. You dont have to use them but you can be surprised what they can bring to the table.

Charles

Excellent points, ifeanyie.

MetaGunny

Ifeanyie,

Of course. I would had said the same thing.

However, a couple of things:

1) The samples you gave used object oriented languages, not functional programming languages exclusively.

2) I've watched all of the C9 videos on these functional programming languages. I only remember one referring to a real world scenario which was in telecommunications. I even watched a video on youtube when the interviewee was younger and the demo showed them crashing the system, where only one process or thread would die, and it wouldn't bring down the whole system. How they could make changes live to the system and it would only affect new processes, etc.

However, that really didn't relate back to the concepts of "purity", etc", of the why someone should use functional programming languages.

I'm not approaching this with an argument of why not to use functional programming.

Rather, I'm simply asking someone to explain the reasoning behind FP in a "KISS" way on why it's better than an existing programming language.

Or, maybe it's not meant for real world use in today's world. Maybe it's more of theory and bits and pieces are taken to enhance existing languages.

I'm just looking for clarity on this subject.

sylvan

MetaGunny, it matters because purity is easier to reason about, and it's also easier for the compiler to process (if you want the compiler to help you sort out parallelism and concurrency, it almost always needs your code to be pure -- if the language is pure the compiler can guarantee that this is the case).
For example if you have a function that writes to a global variable when you call it, then you can not safely perform 100 tasks simultaneously which all use this function - the side effects mean that sequencing matters all of a sudden. And even if sequencing doesn't matter it's very likely that you'll need to protect the global variable with a lock, which destroys parallelism because of contention.

If you instead write your algorithms in a functional style then not only is it easy to reason about (e.g. if you ever see that a function returns the wrong results given a set of input parameters, then you already have all the information you need to fix the bug, whereas in C++ you may have hours of "quality time" with the debugger before you're even able to figure out exactly what series of events lead to an inconsistent state). It's just more explicit, whereas with side effects everywhere you have all these hidden data flows that can mess up your program but are very difficult to find.
I work at a games company, so I do use C++ every day, and I would estimate that probably 80%+ or so of all bugs I encounter simply could not happen in a functional language because you'd just write things differently.

Basically the issue I find is that when you write imperative code where you update state you need to sort of keep a "mental log" of what your code does as you read it. So at any point in the code you have to keep track of what happend before and go "Okay, so if I end up in this branch then X is not null, and Y is greater than zero" etc. etc. It just fills up your mental resources book-keeping all the state changes that you've done to make sure you're doing the right thing at the right time. In a purely functional world all that disappears. All you have is input and output. You combine the input into the output somehow, but you don't have to keep track of N previous operations to do it correctly, you only have to worry about inputs and outputs. You can feel how much more "mental resources" you have to spend on the actual problem, as opposed to book-keeping.

Also, in an imperative programming language the "meaning" in a program consists of both "values" and "statements". The values can be statically typechecked, but statements can not. In other words, if you swap parameters around in a function call, chances are good that the compiler will tell you about it, but if you swap the order of two statements around chances are good that it will keep compiling happily (and chances are high that the program will not do the right thing anymore). In a purely functional language the meaning is 100% values, so everything gets statically checked. It may not always be enough to ensure no bugs get through, but I think you'd be surprised at how often Haskell programs "just work" when you compile them, even after large changes (which almost never happens in C++!).

Finally the merits of being able to split effects up into separate monads is notable for example in STM. With STM the "readTVar" etc. operations are all in the "STM" monad (not "IO"), in that monad you can only read and write transactional variables (no other effects). This means that the compiler can statically guarantee that no irrevocable effects happen inside a transaction (which is dangerous because a transaction can be preempted and have to be re-run).