Jeremy D. Miller -- The Shade Tree Developer

 research.microsoft.com/.../pj-lester-book

Keep us updated!

Hi Jeremy,

Other problem categories ideal for functional are:

- Processing very large data sets. E.g. There is a team at MS processing 7TB data sets using 100 LOC F#. This is, of course, enabled through Lazy Evaluation.

- Concurrency-oriented programming. No side effects makes concurrent programming easier. Maybe StoryTeller could partition test execution over a large map/reduce cluster ;-)

Cheers,

Andrew.

Hi Jeremy,

I'm not a guru but I use haskell to:

- do pattern matching (extracting data from various formats, pretty printing, conversion, etc.)

- process mass data (generate report data and other statistics from huge datasets ... up to hundreds of MBs not TBs though:)

And playing of course:)

P

F# is a dialect of ML so while these are links to ML resources they should be fairly relevant. I learned how to use functional programming with this course :

www.cl.cam.ac.uk/.../FoundsCS

Which is a little basic as it assumes no programming knowledge but moves quickly has well written notes and it has lots of example questions.

If you want a good book this one is good.

www.amazon.co.uk/.../052156543X

I bought it when I was a student and thought it was a bit rubbish but now I have become a more experience programmer I have been rereading it and it is really excellent. If you are serious about functional programming then I would really recommend getting a copy.

If you think that OO programming and functional programming are different was of solving problems then I think I would disagree. I always think of OO as a way or organizing programs whereas functional programming is a different way of coding algorithms. But it is wrong to think of languages like f# and ml as pure functional languages as they can do imperative stuff too!

The functional language ML was developed to build theorem provers so if you want to really see what functional languages are good at then you should build one of those :). ML for the working programmer has some example projects in the back but they have a strong theoretical computer science slant (one of them for example is to  but a theorem prover). Not all I do is program c#, SQL and winforms these days so it should be telling you how completely useless all this theoretical stuff is and how in the real world nobody uses any of this stuff (I certainly don't) but I honestly think there is a lot to be said for look doing a more theoretical project like a theorem prover. After all we spend most of our lives solving the same problems over and over again like writing a content management system, writing revenue reports and finding slight better working processes. We get a bit better at doing these each time but when you have been in the industry for a while you will have the the most problems before (not all problems obviously). Admittedly each time it is there is a slightly different slant but the general problems remain the same. This means you build up a standard way of solving these problems based on the way you have seen others do them and the ways that have worked for you in the past. If one really wants to grow as a programmer I think you have to find radically different problems to solve and see the way that people have approached those problems. This kicks you out of that comfortable little world that we all like to program in and means makes you start having to think again. It also means you get a completely a whole new set of standard solutions to problems which will make you as a programmer much more effective. After all you will now have many more ways of solving problems. All this sound a little abstract so some examples. Why learn ruby it is after all just another imperative language with slightly different syntax. It might let you solve problems a little quicker than c# and be a little bit more flexible but it isn't that radically different. Instead why not take the time to learn Prolog. This is a completely different way of thinking about how to do programming. It might not be a immediately useful as ruby but it sure as hell is going make you think differently about ways to solve a certain class of problems.

Anyway coming back on topic If you have never written a syntax checker before then writing it in f# is not a bad idea but you will probably write if faster in c# and more people will be able to help you maintain it. You would probably find it more useful to do something really off the wall and write something like a theorem prover in F#. Since ML evolved to write theorem provers when you write one then you will understand the mindset of a theorem prover writer. This will really give you an incite into why they invented ML and understand the mindset of solving problems in that way. Understanding theorem proving will also give you a new way of solving a certain class of problem (where you have a problem and you know where you want to go but don't know how to get there). Knowing more methods of how to solve problems can only be a good thing.

Hmm having just reread this comment it all sounds a bit pompous and not very useful but it is so seldom I write anything these days I may as well post it anyway :)

Lionel

I have been reading "Programming Erlang". It may be a good place for you to check out functional programming. I also have been looking to use a functional language and use it properly - the paradigms ARE different and i also do not want to just try to use the OO-isms in that context - but REALLY to learn where the functional languages shine.

-Chris

Common Lisp

depth first searches are good problems (any tree based problem in general, including n-linked which is your typical domain)

Can I recommend a book? I promise it will make your imperative code better if nothing else. "Purely Functional Data Structures"

Cheers,

Greg

The map/reduce programming model is a cannonical application of functional programming.

See this:

labs.google.com/.../mapreduce-osdi04.pdf

and this:

www.joelonsoftware.com/.../01.html

to grasp why functional programming is waaayyy cool.

--

David