Python – F# vs IronPython: When is one preferred to the other

%fironpythonnetpython

While the languages F# and IronPython are technically dissimilar, there is large overlap between their potential uses in my opinion. When is one more applicable than the other?

So far it look to me like F# is computationally more efficient while IronPython inherits a better library from Python. I am happy to be corrected.

There is a somewhat relevant question is F# to IronPython/IronRuby as C# is to VB.NET? but most of the answers there are about the language paradigms rather than their actual applicability.

Edit: I guess I should add a bit more background. I have good experience with Python in general, and have just learnt F# after a few hesitant functional programming steps before, mainly in Erlang. I currently feel able to continue using either Python or F# in the future. I would like to decide which one I should use and where. For example:

Python has very good data structures as part of the standard library. The other day I needed an equivalent of Python's heap module and it is not available in the standard F#/.net library. Point for IronPython.
F# can be used to build more convenient libraries, easier to access from other .Net languages. So for a .Net residing library I would prefer F#.
Cross-platform development. IronPython is better here. F#/Mono is usable is a much smaller set of platforms and F#/OCaml compatibility is not easy to maintain especially in terms of libraries.
The IronPython interactive shell seems to me easier than fsi. YMMV.

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?

Edit: Ok guys, it looks you have judged this to be a stupid question, downvoting it and the answers. But at least it is honest. So please just a hint. Is it impossible to differentiate between the two or am I entering into some secret taboo by asking this question? If it looks like a troll can somebody please inform me?

Best Answer

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.

This is the style that Microsoft tends to use in their examples.

It appears that the guidance in this area may have changed, as StyleCop now enforces the use of the C# specific aliases.

Python – Finding the index of an item in a list

>>> ["foo", "bar", "baz"].index("bar")
1

Reference: Data Structures > More on Lists

Caveats follow

Note that while this is perhaps the cleanest way to answer the question as asked, index is a rather weak component of the list API, and I can't remember the last time I used it in anger. It's been pointed out to me in the comments that because this answer is heavily referenced, it should be made more complete. Some caveats about list.index follow. It is probably worth initially taking a look at the documentation for it:

list.index(x[, start[, end]])
Return zero-based index in the list of the first item whose value is equal to x. Raises a ValueError if there is no such item.

The optional arguments start and end are interpreted as in the slice notation and are used to limit the search to a particular subsequence of the list. The returned index is computed relative to the beginning of the full sequence rather than the start argument.

Linear time-complexity in list length

An index call checks every element of the list in order, until it finds a match. If your list is long, and you don't know roughly where in the list it occurs, this search could become a bottleneck. In that case, you should consider a different data structure. Note that if you know roughly where to find the match, you can give index a hint. For instance, in this snippet, l.index(999_999, 999_990, 1_000_000) is roughly five orders of magnitude faster than straight l.index(999_999), because the former only has to search 10 entries, while the latter searches a million:

>>> import timeit
>>> timeit.timeit('l.index(999_999)', setup='l = list(range(0, 1_000_000))', number=1000)
9.356267921015387
>>> timeit.timeit('l.index(999_999, 999_990, 1_000_000)', setup='l = list(range(0, 1_000_000))', number=1000)
0.0004404920036904514

Only returns the index of the first match to its argument

A call to index searches through the list in order until it finds a match, and stops there. If you expect to need indices of more matches, you should use a list comprehension, or generator expression.

>>> [1, 1].index(1)
0
>>> [i for i, e in enumerate([1, 2, 1]) if e == 1]
[0, 2]
>>> g = (i for i, e in enumerate([1, 2, 1]) if e == 1)
>>> next(g)
0
>>> next(g)
2

Most places where I once would have used index, I now use a list comprehension or generator expression because they're more generalizable. So if you're considering reaching for index, take a look at these excellent Python features.

Throws if element not present in list

A call to index results in a ValueError if the item's not present.

>>> [1, 1].index(2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: 2 is not in list

If the item might not be present in the list, you should either

Check for it first with item in my_list (clean, readable approach), or
Wrap the index call in a try/except block which catches ValueError (probably faster, at least when the list to search is long, and the item is usually present.)