is F# to IronPython/IronRuby as C# is to VB.NET?

Question

I just listened to podcast of Chris Smith talking about F# in which he talks about how F# is a language which allows you to approach problems in a different way than in C#/VB.NET, i.e. instead of "pushing bits around" you "chain together data transformations", and that how F# will "become like XML", something that you use in addition to your language of choice (C# or VB.NET) in order to solve certain problems in a more efficient way.

This got me to thinking about the relationship of the .NET languages, here's how I understand them:

• C# and VB.NET are syntactically but not substantially different, i.e. a C# programmer would not learn VB.NET in order to "approach problems in a new way"
• however, a C# or VB.NET programmer would learn F# in order to "approach programming problems in a functional way"

But what about IronPython and IronRuby? Chris mentioned that "F# learned a lot from Ruby and Python" so I would think that F# has a similar relationship to IronRuby/IronPython and C# has to VB.NET. However, a little googling around tells me that IronRuby and IronPython are both built on the DLR but F# is not.

How are the relationships between F#, IronRuby and IronPython to be best understood?

Rarefaction

F# has roots in OCaml which is far from IronPython and IronRuby... I don't see any direct relationships. – Brucebrucellosis

Isn't IronPython (just) an implementation of Python in .NET? F# is a new language altogether.... – Overripe

I think you mean Chris Smith not Chris Sells. – Oestradiol

@Robert, thanks, right: Chris Smith. – Rarefaction

Answer 1

F# and IronPython/IronRuby are light years apart from a language perspective. F# is a functional, highly typed compiled language. IronRuby/IronPython are dynamically typed, interpreted languages.

I believe IronPython does additionally support compilation but I'm not 100% sure, and less about ruby.

The relationship between VB.Net and C# is much closer.

Dewain

I'd go so far as to say that F# is much closer to VB.NET and C# than IronRuby/IronPython. – Hanafee

F# is just a different paradigm, as our friends said, its compiled, and that makes it very different to the Iron family. If you look arroung, you will see Haskel, Charity, Clean as exemples of pure functional programming. Then there are others that allow function programming but they have their own main paradigm, C/C++/C#, List, Matematica, Python are exemples of that. – Eda

Depends on what you mean by "compilation" -- both IronRuby and IronPython really are compilers. – Intromit

By compilation most people mean you have a distinct compile step and emit some sort of binary like an exe, dll, or java class file. – Hindi

Answer 2

In many ways F# and Ruby/Python are superficially similar. All three languages allow you to concisely express ideas without littering your code with many types. However, F# is actually very different from Ruby and Python, since F# is a statically typed language, while Ruby and Python are dynamically typed. Idiomatic F# code rarely mentions types, but the compiler infers types and any type errors will be flagged by the compiler during compilation. For Ruby and Python, using a value at the wrong type will only generate errors at run-time. Ruby and Python’s dynamism means that both are more amenable to metaprogramming than F# is (types can be modified at runtime, for instance). On the other hand, F# is going to be more performant for most tasks (comparable to C#), and offers many nice functional abstractions such as discriminated unions with pattern matching. It’s certainly true that learning any of these languages well will lead you to think about problems differently than you do in C# or VB.NET, but your approach will probably vary a lot between F# and Python/Ruby as well.

Pommard

Answer 3

I'd say F# learned a whole lot more from OCaml than it did from Ruby and Python combined. The only real comparison is that F# is brings ML to .NET in the same way that IronPython/Ruby bring Python/Ruby to .NET.

Booze

I think they often get because F# and IronPython/Ruby both have concise syntax where you don't explicitly need to state they type of each identifier. – Oestradiol

I can see that, but even so they each have concise syntax for different reasons and don't need explicity identifiers for different reasons. The similarities are very superficial. – Booze

Answer 4

F# is more of a "tool" language where there are specific problems that are best tackled with a functional approach. F# is inherently thread safe which gives hope that it will be helpful in scaling an application to use multiple processors. I see F# being used to build components that will be used in VB.NET or C# to handle specific problems.

Lucretialucretius

F# is inherently thread safe is - unfortunately - just not true. F# provides mecanisms which facilitate thread safe code, but it doesn't just magically, or automatically, happen out of the box. – Hilariohilarious

Having completely replaced C# with F# in a project, I don't see how it's a narrow "tool" language that just steps in when C# doesn't cut it. Apart from a few remaining interop issues (and lack of tool support), F# is pretty much a superset of C#, functionality-wise. – Marconigraph

WOW, that's interesting perspective. I've heard the main concern about F# is that business apps lend themselves to OO and imperative programming and those apps traditionally aren't approached with a functional language. The "tool" comment implies that a developer would divide the problem into domains and best apply F# where it made sense. – Lucretialucretius

It takes a bit to get the hang of it, but you can do classes and all of that in F#, and they are usually more succinct. – Mulhouse

Answer 5

There are aspects of F# that are similar to dynamic languages; however, JaredPar's answer sums it up really. F# is in it's own category of functional programming where as IronRuby and IronPython are dynamic languages and C#/VB OO Languages. They can all do the same things and just depends on how you want to do it. Each has it's pros and cons for a given problem.

Glauce

Answer 6

NOTE: This is mostly a compilation of my thoughts and observations on the subject. I'm a C# programmer by day and Python by night.

Yeah I agree with some of the stuff that has been said, but I have some time and feel like elaborating and sharing my thoughts.

F# is a functional language. Which means you are really more concerned with the verbs so to speak. It is still statically typed and runs on the CLR, but you structure your code differently and work through problems differently. Usually people think that functional languages are more mathematical in structure and easier to prove formally. Of course that is generally regarded as mostly academic.

C# and other statically typed OO languages are really more focused on the nouns to further my analogy. So you structure your code and work through problems in regards to that. Of course there are also natural problems with maintaining state and having non-deterministic methods on objects that tend to come up more often in OO languages.

And of course F# has some features and ideas borrowed from OO languages while C# has ideas and features borrowed from functional.

Comparing Python and C# is more about the difference between dynamic and static typing (although python does offer some functional features that C# still does not). Dynamic typing usually being far easier to handle introspection/reflection activities and run-time modification while adding the risk of run-time errors due to typos or incorrect objects used in "regular" code.

Static languages usually have some developer overhead that dynamic languages do not have. The overhead seems to usually be due to having to create layers to abstract things away and creating inheritance hierarchies and interfaces to work with the needed/wanted abstraction. Since you are trying to avoid dependencies to types.

It seems like statics languages can be much easier to manage in larger teams. Plus you get the advantages of refactoring very easily with all the checking and tools out there.

Firstfoot

Nice thoughts. I am working on some Python projects that are growing pretty large and the lack of automated refactoring definitely creates extra work. – Psychophysiology