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.
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.
Fibonacci is basically the "Hello, World" program of functional programming--it's trivial but succinctly summarizes several disparate language features. The reason you see it so often is that you are (naturally) reading introductory articles. I imagine if you didn't know anything about imperative programming, the endless stream of "Hello, World" and contrived OO examples (Dog is an Animal...) would also seem onerous.
Lists, on the other hand, are actually very useful in functional programming. Lists and their corresponding higher-order functions are the equivalent of loops in imperative languages.
The real issue you're seeing, though, is that you have to start small to understand everything. This is true of everything, not just functional programming. I remember learning C++ and being really frustrated that all I ever wrote were silly command-line programs; however, I could hardly have jumped into UI development with practically no understanding of the language.
However, most practical applications require you understand the very basics: recursion, list operations, types... An article that just jumped into something like FRP (Functional Reactive Programming, a really awesome approach to making UIs) would just confuse you unless you've spent at least a little bit of time with Fibonacci and friends.
Ultimately, the only way to know if functional programming is better for some problem you have is to first understand its fundamental building blocks.
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#.
I am not quite sure you don't make lists on a daily basis. I do it all the time when I program -- and I would guess that most people do so too.
Calculating the Fibonnaci sequence is really not that interesting, true enough, but it serves as a relatively simple way to demonstrate recursion (please don't claim you never use it, it is just masked as loops in C#).
I find it funny that you want to retrieve data from web APIs and create XML ducuments -- which is a case where you would often use lists (e.g an XML document is essentially a tree which is just a list of trees and nodes) -- so any language which makes it easy to process list would make you more productive in solving exactly the problems you want it to, if only you would learn it.
I can't really speak from any experience as I've only just started programming in F# myself, I think for the most part it's not meant to replace the things you mention. The reason I looked into it initially was because of its applicability with mathematical calculations and parallelism. Because of the .Net angle though you can mix and match your projects on Windows systems. Here's a Stack Exchange question about what proficient F# programmers use it for: http://stackoverflow.com/questions/568827/what-areas-of-code...
Something to keep in mind is that you can make your C# surprisingly functional using LINQ. It's inspired by Haskell and functional programming. It makes the transition from "imperative with functional features" to "functional" very simple.
And you can use Reactive Extensions in C#, which is the most accessible framework for FRP (functional reactive programming) out there and very useful for UI and asynchronous tasks. I've just started exploring it, but it's pretty fun so far.
There are some books that go over using functional programming for "real world" tasks. Two off of the top of my head are Real-World Functional Programming by Tomas Petricek and Jon Skeet (.NET focused, and might be a bit aged now), and Real World Haskell (http://book.realworldhaskell.org/). So indeed, there are resources to help answer this question by walking you through common things like drawing graphs, database querying, working with XML, etc.
I've given F# a try recently for some of those tasks, and while it certainly is very capable of accomplishing them, I've found that using the .NET libraries, or having to expose my own APIs to C# developers in a way that will be natural to them, often leads me to simply writing C# with F#'s syntax. This is certainly no worse than having done so in C# directly, but the core ideas behind functional programming just seem to get diluted. On a side note, I think that with a bit of more design in mind, it should be possible to at least keep the core components 'functional' and then just have a middle layer that defines the classes and handles interop so your code can then be used from C# in an OO way.
ml like languages are THE perfect languages for working with xml. The algebraic datatypes which you spend the majority of your time creating in them are xml dtd's. The functions you create are xsl transformations. The compiler doesn't allow you to make silly mistakes in any part of your code. See cduce and ocamlduce which are completely based around the idea of xml.
More generally they best suited for "symbolic" programming, compilers being the main example. They don't offer much when you're doing a few things with an api or numeric code (python and numpy are better in that case because of their libraries and because you don't need the additional safety of types when writing small programs/scripts),
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:
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.
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.
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.
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).
Thanks for the feedback. To be honest I haven't really grasped all the ins and outs of functional programming yet so tried to ignore it as a first step. From what I've seen so far, I do like how much all the typing takes care of itself.
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.
[+] [-] AndrewDucker|14 years ago|reply
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.
[+] [-] tikhonj|14 years ago|reply
Lists, on the other hand, are actually very useful in functional programming. Lists and their corresponding higher-order functions are the equivalent of loops in imperative languages.
The real issue you're seeing, though, is that you have to start small to understand everything. This is true of everything, not just functional programming. I remember learning C++ and being really frustrated that all I ever wrote were silly command-line programs; however, I could hardly have jumped into UI development with practically no understanding of the language.
However, most practical applications require you understand the very basics: recursion, list operations, types... An article that just jumped into something like FRP (Functional Reactive Programming, a really awesome approach to making UIs) would just confuse you unless you've spent at least a little bit of time with Fibonacci and friends.
Ultimately, the only way to know if functional programming is better for some problem you have is to first understand its fundamental building blocks.
[+] [-] profquail|14 years ago|reply
- 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#.
[+] [-] tomjen3|14 years ago|reply
Calculating the Fibonnaci sequence is really not that interesting, true enough, but it serves as a relatively simple way to demonstrate recursion (please don't claim you never use it, it is just masked as loops in C#).
I find it funny that you want to retrieve data from web APIs and create XML ducuments -- which is a case where you would often use lists (e.g an XML document is essentially a tree which is just a list of trees and nodes) -- so any language which makes it easy to process list would make you more productive in solving exactly the problems you want it to, if only you would learn it.
[+] [-] lifebeyondfife|14 years ago|reply
[+] [-] scarmig|14 years ago|reply
And you can use Reactive Extensions in C#, which is the most accessible framework for FRP (functional reactive programming) out there and very useful for UI and asynchronous tasks. I've just started exploring it, but it's pretty fun so far.
[+] [-] nxn|14 years ago|reply
I've given F# a try recently for some of those tasks, and while it certainly is very capable of accomplishing them, I've found that using the .NET libraries, or having to expose my own APIs to C# developers in a way that will be natural to them, often leads me to simply writing C# with F#'s syntax. This is certainly no worse than having done so in C# directly, but the core ideas behind functional programming just seem to get diluted. On a side note, I think that with a bit of more design in mind, it should be possible to at least keep the core components 'functional' and then just have a middle layer that defines the classes and handles interop so your code can then be used from C# in an OO way.
[+] [-] marshallp|14 years ago|reply
More generally they best suited for "symbolic" programming, compilers being the main example. They don't offer much when you're doing a few things with an api or numeric code (python and numpy are better in that case because of their libraries and because you don't need the additional safety of types when writing small programs/scripts),
[+] [-] Zak|14 years ago|reply
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|14 years ago|reply
[+] [-] xentronium|14 years ago|reply
[+] [-] xentronium|14 years ago|reply
[1] http://web.mst.edu/~tauritzd/courses/cs347/whyfp.pdf
[+] [-] Confusion|14 years ago|reply
[+] [-] mjbellantoni|14 years ago|reply
Is this really a strict property of functional languages? :)
[+] [-] nandemo|14 years ago|reply
[+] [-] marshallp|14 years ago|reply
[+] [-] lifebeyondfife|14 years ago|reply
[+] [-] mushishi|14 years ago|reply
[+] [-] itechnofuture|14 years ago|reply
[deleted]
[+] [-] josh5555|14 years ago|reply