I wrote a program last month to download a CSV file from the web, parse it, check for dupes, and load it into a database.
It took about 20 lines of F# code.
With C# I couldn't even start on the project with that few lines of code.
It's a lot like SQL and stored procs. If you don't know what you're doing (like me) you thrash around using cursors (for-next-loops) and such making a mess the first time you try to solve a problem.
But then, as you get the hang of it, it all "collapses" into this beautiful, small, piping one-line-type syntax, like one of those origami models that goes suddenly from being folded paper to a bird or something.
If you've ever done this with stored procs and cursors, starting with a lot of cursors and eventually using a regular SQL statement to do something that used to take many lines of code, you know what I'm talking about. It's a thing of beauty. I'm not convinced it reads any clearer (although FP folks say it does) and I'm not convinced large code bases are easier to maintain -- but then again I'm not convinced you'll really have the kind of large code bases you see in C#/Java/etc
Ironically, this means that data structures are the critical thing in functional programming. Even more so than in imperative languages. (In my opinion)
Here is another data point. I tried F# for a GUI application some time ago. F# OOP is confusing, with a lot of syntactic variations and limitations on what kind of expressions you can put where. Subtyping doesn't work well because you have to upcast everywhere. I started again in C# and it was much better. Not only is the OOP better but also the IDE.
F# is okay for data processing like you describe, but Ruby is better.
I've anecdotally heard of F# kicking C#s butt when it comes to throughput, but you'll have to poke around on the web to find out more. Sorry I can't provide more details.
Seems like I remember reading a blog where there were some gamer-programmers who had these huge log files to process. Using C# it was just too much -- it took too long. But by using F# (and block operations I think?) they reduced it to some crazy time like 5 minutes or something.
Theoretically they should be the same; they all run on the CLR. But I think F# lends itself to stuff like tail-recursion and data operations such that the code has a tendency to self-optimize as you write it, which is kinda neat.
> Theoretically they should be the same; they all run on the CLR. But I think F# lends ...
I think you are misunderstanding this part. Tail call optimization can (sometimes) allow functional code be as fast as its imperative equivalent. It's not a magic bullet that makes it faster than the imperative code.
I wrote a program last month to download a CSV file from the web, parse it, check for dupes, and load it into a database.
It took about 20 lines of F# code.
With C# I couldn't even start on the project with that few lines of code.
It's a lot like SQL and stored procs. If you don't know what you're doing (like me) you thrash around using cursors (for-next-loops) and such making a mess the first time you try to solve a problem.
But then, as you get the hang of it, it all "collapses" into this beautiful, small, piping one-line-type syntax, like one of those origami models that goes suddenly from being folded paper to a bird or something.
If you've ever done this with stored procs and cursors, starting with a lot of cursors and eventually using a regular SQL statement to do something that used to take many lines of code, you know what I'm talking about. It's a thing of beauty. I'm not convinced it reads any clearer (although FP folks say it does) and I'm not convinced large code bases are easier to maintain -- but then again I'm not convinced you'll really have the kind of large code bases you see in C#/Java/etc
Ironically, this means that data structures are the critical thing in functional programming. Even more so than in imperative languages. (In my opinion)