F# vs IronPython: When is one preferred to the other?
Question:
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?
Answers:
Which one do you prefer more (within bounds of your functional — and political — requirements)? Which one requires more initial investment? Which one do you want to maintain (long-term investment)? And which one will help you solve your problem(s) the best?
IronPython is, well, Python. That also means it is considerably more dynamic — which adds run-time overhead — than F#. If you prefer Python over F#, and it runs fast enough for you, then why not use it? As you mentioned, it does have better ‘Python library’ support, so if you can leverage that to your advantage, then score IronPython.
On the other hand, “just” being constrained to the .NET (and F#-friendly) libraries really isn’t so bad for a language like F#, as long as the libraries to do what you need to do exist or can be marginalized.
However, it really does come down to the paradigm as well as the preference and experience of the developers.
I personally avoid dynamic languages where I can 🙂
The biggest difference between F# and IronPython is that:
F# is a static language
and
IronPython is dynamic.
While at small levels(e.g. a 100-line script), dynamic and static languages don’t have much difference. When it comes to software design/component design, these two languages have two different thinking patterns. The type system in F# is also much powerful than Python’s.
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.
The two main differences between F# and Iron Python are:
- F# is statically typed, while Iron Python is not.
- The foundation of F# is functional programming while the foundation of Iron Python is object-oriented programming. (With both having good support for other-paradigms.)
These are relatively major differences, and they directly lead to the main practical reasons to prefer one over the other.
As you said, Iron Python is slower than F# due to the lack of static typing. In the Computer Language Benchmarks, Iron Python is 25x in the median, and 120x slower in the worst case. So if runtime performance is a consideration, F# is likely preferable.
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=ironpy&lang2=fsharp
Since both are .NET, each can use the libraries of the other with just a little work. So I don’t see this as a major issue, although I guess it’s possible to use SciPy in IronPython, while it would be tedious from F#, and the corresponding best free library for F# isn’t quite as good.
Functional programming can be a very powerful style, and allows F# to have some powerful features like workflows, including asynchronous workflows which are well supported by the F# libraries. You could roughly emulate such things in Iron Python, but it wouldn’t work quite as smoothly, in part because of lack of support in the libraries.
Object orientation is more familiar to many programmers, and they might prefer Python for that reason.
Static typing also allows an IDE to provide better support to programmers. The type of each variable can be reported to the programmer (via hovering in VS), and feedback on errors can be given while the code is being edited. As a university lecturer I can say that this immediate feedback is extremely useful to my students while they are learning F#. This enables them to manage more complex programs than they could otherwise.
Dynamic typing sometimes allows small, simple programs to be written slightly more quickly. If this is the only coding you’ll be doing then Python may be preferable. But, if there’s a chance a program will grow into something larger, then I’d prefer F#.
Ironpython’s dynamic interpretation shines as an alternative to the monotonous javascript syntax in client browser user-agents. F#’s static type checking covering custom types allows SI, or any such measurement system portable library, so back-end tier fetching data from clouds can remodel it as useful information more meaningfully. While like most programming languages they can be used interchangeably to these and more things, these citations exhibit altogether separate strengths of the two within client apps. F# plays critical role in composite app, whereas Ironpython plays role inside user-agent browser based interaction.
F#’s static type checking and lambdas might simplify ASP.net on several Object Oriented occasions closer to the level of classic ASP. Ironpython allows application extensibility by user modifiable scripts that do as well as 3rd party plug-in extensions that have been popular not only with browsers, but media players, and dream-weaver and other editors.
Ironpython maybe re-factored into pure python and .net dependent parts foreseeing re-usability use-cases. F# so far serves as functional paradigm face of the other-wise Object-Oriented paradigm based .net
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
heapmodule 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?
Which one do you prefer more (within bounds of your functional — and political — requirements)? Which one requires more initial investment? Which one do you want to maintain (long-term investment)? And which one will help you solve your problem(s) the best?
IronPython is, well, Python. That also means it is considerably more dynamic — which adds run-time overhead — than F#. If you prefer Python over F#, and it runs fast enough for you, then why not use it? As you mentioned, it does have better ‘Python library’ support, so if you can leverage that to your advantage, then score IronPython.
On the other hand, “just” being constrained to the .NET (and F#-friendly) libraries really isn’t so bad for a language like F#, as long as the libraries to do what you need to do exist or can be marginalized.
However, it really does come down to the paradigm as well as the preference and experience of the developers.
I personally avoid dynamic languages where I can 🙂
The biggest difference between F# and IronPython is that:
F# is a static language
and
IronPython is dynamic.
While at small levels(e.g. a 100-line script), dynamic and static languages don’t have much difference. When it comes to software design/component design, these two languages have two different thinking patterns. The type system in F# is also much powerful than Python’s.
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.
The two main differences between F# and Iron Python are:
- F# is statically typed, while Iron Python is not.
- The foundation of F# is functional programming while the foundation of Iron Python is object-oriented programming. (With both having good support for other-paradigms.)
These are relatively major differences, and they directly lead to the main practical reasons to prefer one over the other.
As you said, Iron Python is slower than F# due to the lack of static typing. In the Computer Language Benchmarks, Iron Python is 25x in the median, and 120x slower in the worst case. So if runtime performance is a consideration, F# is likely preferable.
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=ironpy&lang2=fsharp
Since both are .NET, each can use the libraries of the other with just a little work. So I don’t see this as a major issue, although I guess it’s possible to use SciPy in IronPython, while it would be tedious from F#, and the corresponding best free library for F# isn’t quite as good.
Functional programming can be a very powerful style, and allows F# to have some powerful features like workflows, including asynchronous workflows which are well supported by the F# libraries. You could roughly emulate such things in Iron Python, but it wouldn’t work quite as smoothly, in part because of lack of support in the libraries.
Object orientation is more familiar to many programmers, and they might prefer Python for that reason.
Static typing also allows an IDE to provide better support to programmers. The type of each variable can be reported to the programmer (via hovering in VS), and feedback on errors can be given while the code is being edited. As a university lecturer I can say that this immediate feedback is extremely useful to my students while they are learning F#. This enables them to manage more complex programs than they could otherwise.
Dynamic typing sometimes allows small, simple programs to be written slightly more quickly. If this is the only coding you’ll be doing then Python may be preferable. But, if there’s a chance a program will grow into something larger, then I’d prefer F#.
Ironpython’s dynamic interpretation shines as an alternative to the monotonous javascript syntax in client browser user-agents. F#’s static type checking covering custom types allows SI, or any such measurement system portable library, so back-end tier fetching data from clouds can remodel it as useful information more meaningfully. While like most programming languages they can be used interchangeably to these and more things, these citations exhibit altogether separate strengths of the two within client apps. F# plays critical role in composite app, whereas Ironpython plays role inside user-agent browser based interaction.
F#’s static type checking and lambdas might simplify ASP.net on several Object Oriented occasions closer to the level of classic ASP. Ironpython allows application extensibility by user modifiable scripts that do as well as 3rd party plug-in extensions that have been popular not only with browsers, but media players, and dream-weaver and other editors.
Ironpython maybe re-factored into pure python and .net dependent parts foreseeing re-usability use-cases. F# so far serves as functional paradigm face of the other-wise Object-Oriented paradigm based .net