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?

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.

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.

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.

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.

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.

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.