If we have a problem that can be solved mathematically, we can write code that is very similar to the actual formula to solve the problem.

I like that explanation. Very succinct. Thanks.

Herbie

Not fully complete, however. Functional styles have a wider applicability. List processing, which includes text parsing, is often easier and more succinct to code in a functional manner. LINQ is a great example of the functional style that will be easier
to grasp as an example of where the domain shines for someone only used to C-style languages.

I don't know ML at all, so right now the F# code I've looked at looks like Swahili. I have used several other functional languages, though, such as Lisp. It's exciting that functional languages are coming to .NET, but I'm still partial to C-style syntax.
So I'll look into F# for academic interests, but I'll probably stick to C# and hope it continues to become more functional over time.

﻿OK, now I don't have a CS background and I fell into the C-family of languages (with a short stroll through Pascal and Basic at the start), so I'm a mainly OOP developer, and I come up a bit short on the rest of this stuff.

Can anyone suggest examples of functionality that would be better written in F# than in C#?

When would I want to use it?

Herbie

I wouldn't say there's anything that's *better* to write in F# (or any other functional language), personally I hate the way people pigeonhole technologies like that. I would say you would program in F# if you like writing in a functional style.

It's very difficult to explain the point of functional programming to people that have only ever written in imperitive languages I'm affraid. I did two years of ML at university and it took me a long time to get it and even then I haven't used ML (or any other
functional language) since I graduated.

If I had to summarise the point of it - functional programming from a programmers perspective allows for more succinct expression of algorithms, i.e. complex algorithms written in functional languages can be easier to understand and work on for people that
understand those languages.

It's also worth pointing out that since functional programming is strictly a subset of procedural programming, you can write functional code in C# if you want, although it will be much less efficient than if you had used the same coding pattern in ML. For example,
your basic method of itteration in functional programming is recursion and we all know you can write recursive code in procedural languages like basic or C#, but when you recurse in those languages you use up stack frames each time round the loop so you don't
want to do it too much, the call and return operations have a certain amount of overhead. The compilers for functional languages do a lot to re-write the code so that recursive functions become simple loops. I know it seems like there's no point in that, but
a lot of algorithms make more sense when expressed recursively (Quicksort being the golden example) so you want a language that allows you do use recursion free of concern for efficiency or running out of stack space.

Functional languages also offer interesting type systems and while a lot of the more useful stuff has been replicated in procedural languages through object orientation and generic types, there are still some beautiful things you can do in languages like ML.
I haven't looked at F# so I don't know if this has an interesting type system like ML or if it's just like the C# type model with a functional syntax.

If we have a problem that can be solved mathematically, we can write code that is very similar to the actual formula to solve the problem.

I like that explanation. Very succinct. Thanks.

Herbie

Not fully complete, however. Functional styles have a wider applicability. List processing, which includes text parsing, is often easier and more succinct to code in a functional manner. LINQ is a great example of the functional style that will be easier
to grasp as an example of where the domain shines for someone only used to C-style languages.

I don't know ML at all, so right now the F# code I've looked at looks like Swahili. I have used several other functional languages, though, such as Lisp. It's exciting that functional languages are coming to .NET, but I'm still partial to C-style syntax.
So I'll look into F# for academic interests, but I'll probably stick to C# and hope it continues to become more functional over time.

See, now I know why it made me feel a bit uncomfortable. Any language that even comes close to Lisp makes me shudder

Dr Herbie wrote:﻿OK, now I don't have a CS background and I fell into the C-family of languages (with a short stroll through Pascal and Basic at the start), so I'm a mainly OOP developer, and I come up a bit short on the rest of this stuff.

Can anyone suggest examples of functionality that would be better written in F# than in C#?

When would I want to use it?

Herbie

I wouldn't say there's anything that's *better* to write in F# (or any other functional language), personally I hate the way people pigeonhole technologies like that. I would say you would program in F# if you like writing in a functional style.

Faster and more efficient = better, no?

we have ML programs that take 12+ hours to run (analyzing hundred+ gigs of data), imagine if that was running through C#, or VB.NET or Java.

Also, it is much easier for the math geeks to understand.
if a model is visibly off, they can look through the code and usually find where the calculation is running amok.

rhm wrote:

﻿

It's very difficult to explain the point of functional programming to people that have only ever written in imperitive languages I'm affraid. I did two years of ML at university and it took me a long time to get it and even then I haven't used ML (or any other
functional language) since I graduated.

If I had to summarise the point of it - functional programming from a programmers perspective allows for more succinct expression of algorithms, i.e. complex algorithms written in functional languages can be easier to understand and work on for people that
understand those languages.

It's also worth pointing out that since functional programming is strictly a subset of procedural programming, you can write functional code in C# if you want, although it will be much less efficient than if you had used the same coding pattern in ML. For example,
your basic method of itteration in functional programming is recursion and we all know you can write recursive code in procedural languages like basic or C#, but when you recurse in those languages you use up stack frames each time round the loop so you don't
want to do it too much, the call and return operations have a certain amount of overhead. The compilers for functional languages do a lot to re-write the code so that recursive functions become simple loops. I know it seems like there's no point in that, but
a lot of algorithms make more sense when expressed recursively (Quicksort being the golden example) so you want a language that allows you do use recursion free of concern for efficiency or running out of stack space.

Functional languages also offer interesting type systems and while a lot of the more useful stuff has been replicated in procedural languages through object orientation and generic types, there are still some beautiful things you can do in languages like ML.
I haven't looked at F# so I don't know if this has an interesting type system like ML or if it's just like the C# type model with a functional syntax.

I liked Haskell because it allowed me to specify complex stuff in a few lines of code. Really cool!

It takes some time to get it but when you got it it is really nice and expressing complex problems in a few lines of code is just plain cool. Imagine you do a Quicksort in like 5 lines of code instead of 50-100 or even more in C/C++. No worrying about pointer
and stuff - you use lists and operate on the elements.

Also it is then way easier to extend the code in pointer later in time.

But probably if you only code data layers and that stuff you won't need it that much... but I might be wrong! Who knows...

However, can someone at Microsoft help to give
Boo and Nemerle the same love F# got?

Whilst these are not MS developed languages, they are fantastic. Boo especially has an excellent developer community. The language has so many powerful features and is super easy to learn - better then VB.NET I'd say!

We need to get these into VS.NET!

Royal​SchrubberOne. How many time travellers does it take to change a lightbulb?

Can anyone suggest examples of functionality that would be better written in F# than in C#?

When would I want to use it?

Herbie

In addition to some of the other things people mentioned already, F# is a functional language without side effects, which means the variables are immutable, which means programs written with it can be parallelized without worrying about the kind of issues that
overwriting a variable from a parallel thread would cause.

Provided the functional language has access to a CAS, yes. That's what Mathematica (both the language and the CAS) is.

Anyway, IRT OP: So F# is now an "official" language. With J# being dropped lately, does this mean F# will be a part of the IDE?

It doesn't need access to a CAS to do integrals or differentiation. I mean an integral is just a sum... In fact, it is very easy to represent an integral in functional languages. It is done in one of the first video lectures listed below.

Dismissing functional languages as only for math intensive operations is missing the point completely. If you use LINQ you are taking advantage of constructs from functional languages. They have many applications.

Anyways, a good intro to functional style programming can be found here -

I think I have tried it in my college years. Functional Programming is very specific to solve certain type of problem. It is not designed for most applications, like PC games, movie player, photo editor, and other mainstream applications.

OOP languages also can do Functional Programming fairly easily. It is very easy to reference a math library and do those more advanced calculations. 3D games usually have some calculus math library included.

And I believe a lot of optimizations are already used in C# anyway. The data dependency is a very basic complier optimization on OOP languages.

Anyway, Functional Progamming Language is way to tricky for me. It is not as straight forward as OOP.

﻿I think I have tried it in my college years. Functional Programming is very specific to solve certain type of problem. It is not designed for most applications, like PC games, movie player, photo editor, and other mainstream applications.

OOP languages also can do Functional Programming fairly easily. It is very easy to reference a math library and do those more advanced calculations. 3D games usually have some calculus math library included.

And I believe a lot of optimizations are already used in C# anyway. The data dependency is a very basic complier optimization on OOP languages.

Anyway, Functional Progamming Language is way to tricky for me. It is not as straight forward as OOP.

Whether you use it day to day or not isn't really the point. When you truly take the time to learn the functional approach to solving problems, it only helps you. It is more about the process, than the syntax. Functional languages aren't better than imperative
languages, and vice versa. It is just that the more tools you have and approaches you can take to solve complex problems the easier life becomes.

I am extremely excited about this anouncement, it just makes .NET that much more compelling of a platform to develop on. Its all about options

Andrew Davey wrote:﻿However, can someone at Microsoft help to give
Boo and Nemerle the same love F# got?

What do Boo and Nemerle do that F# and IronPython can't?

Nemerle is functional, but doesn't force that "flavor" unless you want it. This means you can write imperative code that looks a lot like C#. However, as you learn more about functional programming you can improve your coding style.

Boo is awesome. It has the right mix of static typing with optional dynamic typing. The syntax is super-lightweight, making it ideal for teaching programming to students. In addition, making domain specific languages is easy.

Both have a syntactic macro systems, enabling even higher level meta-programming (think DSLs again). (I know F# has macros of some form too.)

Both have super smart programmers innovating on their development and rich communities.
I'm not saying don't use F# or IronPython. I'm saying please take a good look at Boo and Nemerle as well.

D/2 is also getting some powerful syntax and semantics. It has a very powerful template system as well as compile-time function evaluation (CTFE). It is also able to compose strings at compile-time which can be mixed-in and used as part of the "end" program.
Some powerful stuff has been made using that, for example mixing in compile-time generated inline asm for optimized vector expressions.

Like the C++ Blitz++ library, expression templates are used to convert
vector expressions into efficient element-wise operations. Unlike that
library, however, there is no reliance on the compiler's optimiser.
Instead, the expression template is manipulated as text, converted into
postfix, and then passed to a simple CTFE compile-time assembler, which
creates highly efficient asm code which is used as a mixin.
To understand the later parts of the code, you need some knowledge of
x87 assembler. In fact, you probably need to have read Agner Fog's
superb Pentium optimisation manual (www.agner.org).

Some observations:
* I was amazed at how simple the expression template code is (it is
somewhat cluttered by the code to check for real/imaginary type mismatch
errors).
* I've often read that the x87 floating-point stack is notoriously
difficult for compilers to write code for, but it works quite well in
this case.
* The major workarounds are:
- inability to use a tuple element directly from asm code (bug #1028);
- inability to define operators for built-in arrays (hence the use of
'Vec' wrappers).
- inability to index through a tuple in a CTFE function (solved by
converting types into a string).
* There have been mutterings about how unhygenic/dangerous the new
mixins are. In this case, the mixin forms the _entire_ body of the
function. This is an interesting situation which I think a language
purist will find more palatable.