So the question boils down to: are
there any reasons, apart from a
preference of one paradigm to another
or some team or corporate preferences,
that would make you pick F# rather
than IronPython or vice versa?
Assuming you are equally confident in
both? Or are they exactly equivalent
for all practical purposes?
As is usually the case, "it depends on what you're doing" But since you asked, start here:
Toolset diversity
In my point of view, IronPython is essentially the same as C# with a little different syntax -- I know, its a sweeping generalization for two languages with wholly dissimilar type systems, but they're no much else I can say about yet another imperative, OO language. Whether its C#, or Java, or C++, or Python, you solve languages using roughly the same techniques, idioms, strategies, style, etc. If you're a .NET developer, you've almost certainly worked with C# or VB.NET, and you've already been writing code in an imperative style for as long as you've been using the languages.
The biggest point in favor of F# is simply that it encourages more functional programming styles, downplays abstractions through OO inheritance in favor of function composition, immutability as a default instead of as an after thought, and so on. If you want to write functional code, you need to use a functional language.
Granted, you can write functional style in C# and Python, but functional features are grafted on as an afterthought. Python lacks multiline lambdas, and C# is too verbose and occasionally buggy to make use of functional style in the places where you want to use it, C# in particular has a whole boatload of gotchas regarding delegates and capturing local variables, both languages lack tail-call optimizations almost everywhere that you'd want to use them, C#'s type inference is a joke compared to F#. I've tried using C# as a functional language with hilariously bad results :)
Now most people might concede that problems make it difficult, but not impossible to program in a functional style using C# or Python. However, in my experience, its not the languages that make it impossible, its the programmers on your team. If you've got 10 or 12 people writing code in an imperative language, you won't be able to enforce a functional style for very long -- the languages don't do anything to discourage imperative style. And since programmers already code in that style, that's what you get. Unless you have some really hardcore and slightly masochistic FP enthusiasts on your team, I don't think could enforce a purely functional programming style in an imperative language for very long.
The best argument in favor of F# isn't necessarily functional programming itself, but really diversity of your toolset. You get a bigger ROI pairing up F# and C# (different programming paradigm and similar type system) than pairing up IronPython and C# (same programming paradigm and different type system).
Case study of my company
Ok, so with that being said, I've been trying to push for F# at my company. I won't go into a huge amount of detail on what we do, but essentially my team guides users through the process of ordering cable and phone services for companies like Time Warner, ComCast, and other cable providers.
Its really a more involved process than it sounds. For a start, there is a complicated rules engine which determines availability of products, dependencies and exclusions between products, etc. We walk the rule engine graph and build a decision tree out of it, then we hand the tree to a client so they can display it to the user and collect user input, client maps GUI back to our decision tree structure, we walk the tree and validate everything against the rules engine, etc.
I'd say 95% of our code is simply navigating, manipulating, and processing tree-like data structures. Right now, everything we write is C# and its kind of a mess. Incidentally, one of F#'s strengths is manipulating ASTs and symbolic processing (see a comparison of C# and F# code for processing ASTs), and its all possible because pattern matching is awesome.
Pattern matching is a real killer feature, its exactly what our C# code needs to clean it up, and that's why we need F#. We don't have any use for IronPython because its no better at symbolic processing than C#.
Summary
Functional programming paradigm and pattern matching are two killer features I enjoy with F# everyday. I could go about F#'s async threading model, message passing concurrency primitives, support of monads, novel features like active patterns, and so on, but those are all bullet point comments. For me, its those two killer features that make the case for F# over Python -- at least for my own projects.
Setdata structure. – BuggySetusable is yest3erday, and you gave a wrong example of usage where the priority queue is used for sorting which is not its main point. Still, if you can convince me or convince other people on the other question that F#Setfunctions as a priority queue I will make the modification here. – SickenSetas a priority queue. I thought you were talking about performance because you cited asymptotic time complexity as the difference between these abstract data structures. – Buggy