.net - F# vs IronPython: When is one preferred to the other? -

while languages f# , ironpython technically dissimilar, there large overlap between potential uses in opinion. when 1 more applicable other?

so far me f# computationally more efficient while ironpython inherits better library python. happy corrected.

there relevant question is f# ironpython/ironruby c# vb.net? of answers there language paradigms rather actual applicability.

edit: guess should add bit more background. have experience python in general, , have learnt f# after few hesitant functional programming steps before, in erlang. feel able continue using either python or f# in future. decide 1 should use , where. example:

1. python has data structures part of standard library. other day needed equivalent of python's heap module , not available in standard f#/.net library. point ironpython.
2. f# can used build more convenient libraries, easier access other .net languages. .net residing library prefer f#.
3. cross-platform development. ironpython better here. f#/mono usable smaller set of platforms , f#/ocaml compatibility not easy maintain in terms of libraries.
4. the ironpython interactive shell seems me easier fsi. ymmv.

so question boils down to: there reasons, apart preference of 1 paradigm or team or corporate preferences, make pick f# rather ironpython or vice versa? assuming equally confident in both? or exactly equivalent practical purposes?

edit: ok guys, looks have judged stupid question, downvoting and answers. @ least honest. please hint. impossible differentiate between 2 or entering secret taboo asking question? if looks troll can please inform me?

so question boils down to: there reasons, apart preference of 1 paradigm or team or corporate preferences, make pick f# rather ironpython or vice versa? assuming equally confident in both? or equivalent practical purposes?

as case, "it depends on you're doing" since asked, start here:

toolset diversity

in point of view, ironpython same c# little different syntax -- know, sweeping generalization 2 languages wholly dissimilar type systems, they're no else can yet imperative, oo language. whether c#, or java, or c++, or python, solve languages using same techniques, idioms, strategies, style, etc. if you're .net developer, you've worked c# or vb.net, , you've been writing code in imperative style long you've been using languages.

the biggest point in favor of f# encourages more functional programming styles, downplays abstractions through oo inheritance in favor of function composition, immutability default instead of after thought, , on. if want write functional code, need use functional language.

granted, can write functional style in c# , python, functional features grafted on afterthought. python lacks multiline lambdas, , c# verbose , buggy make use of functional style in places want use it, c# in particular has whole boatload of gotchas regarding delegates , capturing local variables, both languages lack tail-call optimizations everywhere you'd want use them, c#'s type inference joke compared f#. i've tried using c# functional language hilariously bad results :)

now people might concede problems make difficult, not impossible program in functional style using c# or python. however, in experience, not languages make impossible, programmers on team. if you've got 10 or 12 people writing code in imperative language, won't able enforce functional style long -- languages don't discourage imperative style. , since programmers code in style, that's get. unless have hardcore , masochistic fp enthusiasts on team, don't think enforce purely functional programming style in imperative language long.

the best argument in favor of f# isn't functional programming itself, diversity of toolset. bigger roi pairing f# , c# (different programming paradigm , similar type system) pairing ironpython , c# (same programming paradigm , different type system).

case study of company

ok, being said, i've been trying push f# @ company. won't go huge amount of detail on do, team guides users through process of ordering cable , phone services companies time warner, comcast, , other cable providers.

its more involved process sounds. start, there complicated rules engine determines availability of products, dependencies , exclusions between products, etc. walk rule engine graph , build decision tree out of it, hand tree client can display user , collect user input, client maps gui our decision tree structure, walk tree , validate against rules engine, etc.

i'd 95% of our code navigating, manipulating, , processing tree-like data structures. right now, write c# , kind of mess. incidentally, 1 of f#'s strengths manipulating asts , symbolic processing (see comparison of c# , f# code processing asts), , possible because pattern matching awesome.

pattern matching real killer feature, our c# code needs clean up, , that's why need f#. don't have use ironpython because no better @ symbolic processing c#.

summary

functional programming paradigm , pattern matching 2 killer features enjoy f# everyday. go f#'s async threading model, message passing concurrency primitives, support of monads, novel features active patterns, , on, bullet point comments. me, 2 killer features make case f# on python -- @ least own projects.