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.
Without understanding anything about event loops or closures, you can look at http://www.nodejs.org and think "hey wow, that looks just like what I need!"
Why can't the same hold about programming languages? Why do the functional programming aficionados insist that I get all turned on by a quicksort before telling me how immutability with remove all my multithreading headaches?
I mean, F# for example, has a communication system (Agents) which I find really gorgeous on first glance. These help solve real problems, and can do something you can't really do well in C#.
The point of trivial examples like quicksort is just to illustrate the fundamental differences--mostly advantages--of using functional languages. Using a functional language will change every aspect of your code, so even examples like this are illustrative while being simple enough to fade into the background.
Languages like Haskell do have a ton of cool features, but they are all overshadows by how different they are. Once the fundamental differences are thoroughly explained, other goodies can emerge. For example, look at snap, a really fast web framework for Haskell. It's even faster than node.
- 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#.
Are you talking about Parser combinators? haskell [http://www.haskell.org/haskellwiki/Parsec] and F#'s FParsec [http://www.quanttec.com/fparsec/]?
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))
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.
If we were DOM-walking or similar then I can totally see where functional code would come in useful (LINQ being a halfway house in that respect).
eg.
type BookXml =
| Author of { Name: string }
| Book of { Author: Author ; Title : string }
| Document of Seq<BookXML>
let readAuthor (xml:XmlTextReader) : BookXml =
{ Name: xml.ReadContentAsString() }
let readBook (xml:XmlTextReader) : BookXml =
{ Author = readAuthor(xml); Title = xml.ReadContentAsString() }
let parse xml =
match (xml.Read(),xml.Name) with
| false,_ -> bookList
| _, "Author" -> (readAuthor xml)
| _, "Book" -> (readBook xml))
let rec readDoc (xml:XmlTextReader) (bookList:BookXML) =
seq {
yield! readDoc xml (parse xml)
}
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.
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.
As for exposing I write in a typical functional ways then provide wrappers. But these days even non wrapped code can be trivially consumed from C#.
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),
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.