

Functional programming for Object Oriented programmers - lifebeyondfife
http://www.lifebeyondfife.com/82-f-sharp.html
With the continuing popularity of functional programming, it doesn't look like it's ever going away. Here's is an introduction to functional programming in F# written with the object oriented (C#) programmer in mind.
======
AndrewDucker
My problem with these things (and I'm not picking on this particular article,
just on introduction to functional programming articles in general) is that
they always tell you how awesomely easy it is to make lists, or calculate the
fibonacci sequence, two things I never have to do in the office.

What I want to know is whether functional programming languages would help me
to write UIs better than C# does, to create XML documents from data, to
retrieve data from web APIs and then display the results, etc.

These are things I have a need to do on a daily basis, and I'd like to know if
F# is the tool for them, or if I should stick to C# unless I'm writing a list
processor or calculation engine.

~~~
profquail
I was a C# programmer for several years, and I've been writing F# full time
now for a little over a year. To briefly answer your points:

\- F# doesn't have tool support for _building_ UIs (e.g., Winforms designer),
but beyond that, it's very good for the code which actually runs the UI (the
eventing and so forth).

\- You could build some functions to manipulate fragments from XML, then build
some higher-level functions from those, etc., then traverse your data
(whatever it is) and use the functions you've built to emit XML in a clean and
_precise_ way. I think Haskell already has such a library -- perhaps someone's
ported it to F#?

\- You can use F# 'async' workflows to retrieve data from web APIs really
easily (and quickly, if you are doing it in bulk). In fact, this is probably
one of the most common code examples shown for async workflows.

In my experience, F# isn't great at everything, but in general, I'm much, much
more productive writing F# than I ever was/am in C#.

~~~
thomasz
Can you share some experiences with F# in bigger projects? I'm a little bit
worried about the accessibility of larger code bases with global type
inference. I would say that I have a pretty good grasp of the language in
general, but I usually feel lost without IDE support or comments because heavy
usage of things like currying and type inference assures that the signature of
a function is pretty meaningless.

~~~
Dn_Ab
Currying and type inference do not make function signatures meaningless,
unfortunately however, reading their types is a skill that you need to
practice for it to become natural.

As for global type inference the one in F# is only partially global (between
Scala and ML , Haskell). Anytime you are dealing with ad-hoc polymorphism,
even when F# has inferred the types, you will often have to put the type in.
Full point free programming also does not always resolve if you are into that.

I have gotten into the habit of putting types and names for complicated
functions in comments (///). I also write short descriptions for particularly
dense pieces of code and have gotten in the habit of writing clearer, less
dense code with full names because otherwise it does take longer to mentally
unpack. That is, functional languages make it easy to write stuff like: let wu
wp wn nu y x = wp * (exp (nu * y * x)) , wn * (exp (-nu * y * x))

------
Zak
The article says

 _List.map function list - Invokes function on every item within list and
returns nothing._

which isn't what map does in other functional programming languages. Applying
a function and returning nothing isn't a very functional thing to do in
general, as whenever possible functions should be called for their return
values, not anything else they might do[0]. Map normally returns a list of the
function applied to every element of the list. I looked up the documentation
for F#'s map, and it appears to do the same thing:

<http://msdn.microsoft.com/en-us/library/ee370378.aspx>

[0] And when possible, a function should _only_ return a value, not do other
things.

~~~
lifebeyondfife
Yes, my mistake sorry. Correcting it now.

------
xentronium
I would recommend "Why functional programming matters"[1] paper to anyone
struggling to understand the purpose of functional programming. It's only
about 20 pages.

[1] <http://web.mst.edu/~tauritzd/courses/cs347/whyfp.pdf>

~~~
Confusion
That paper is a surefire way to scare people and keep functional programming
from those that could use it perfectly well. You, and many others, vastly
overestimate how capable even highly educated programmers are in understanding
the arguments made in such a technical text.

------
mjbellantoni
"Functions are invoked without using brackets or commas"

Is this really a strict property of functional languages? :)

~~~
nandemo
Yeah, the post is mixing essential features of functional languages with
incidental points about a specific language's syntax. It's not wrong but
somewhat misleading.

~~~
lifebeyondfife
I hope it comes across in the preamble that I've been using F# (the only
functional programming language I've ever tried out) for just a few days and
as such I simply don't know which is which yet.

Anybody who's read this blog post and is interested enough to look further
into functional programming should (a) download LINQPad and play around with
the interactive F# tutorial and (b) start reading things by people with a few
years of functional programming experience under their belt, not a few days.

~~~
nandemo
Fair enough. Sorry if my comment came out as negative, I simply meant to
elaborate on bellantoni's comment.

Minor inaccuracies aside, if your post instills the curiosity of a few
programmers out there, it's a good thing. Please keep writing. :-)

~~~
lifebeyondfife
Not at all, I'm really happy it's garnered so much interest and I'm glad
people have taken the time to help correct me / advise what's not quite right.

------
marshallp
One thing missed in a big way by this article and other newbies when it comes
to (static) functional programming is the centrality of types. It really is
what makes ml-derived languages special and it's a shame it's not promoted to
non-functional programmers more. Most of your work is related to specifying
your types, the rest falls into place naturally, and is why you can think and
write code elegantly (and is super fun).

~~~
mushishi
I would really like to hear more about this. I also do type-oriented
programming in OO languages, such as Java. The code naturally falls into
place, too, but it's just because of Java's verboseness, you end up a lot of
hand-waving. But I don't think it differs much from how I would program in
functional style, say, in Scala.

~~~
jberryman
This talk by Simon PJ on type classes might be good
[http://channel9.msdn.com/posts/MDCC-TechTalk-Classes-Jim-
but...](http://channel9.msdn.com/posts/MDCC-TechTalk-Classes-Jim-but-not-as-
we-know-them)

~~~
mushishi
I actually have that on a browser tab, and will take a look at it. I know some
Haskell (have read maybe 4 books but haven't really ever wrote it).

------
josh5555
great article...very useful. tyvm!

