F# is now the real deal: We've made it an official .NET language

phreaks wrote:



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.

Dr Herbie wrote:



phreaks wrote:  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

Dr Herbie wrote:



phreaks wrote:  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

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

wkempf wrote:



Dr Herbie wrote:  phreaks wrote:  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.

rhm wrote:



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.

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.

This is great news.

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!

Woohoo, it's time for some celebration!

Dr Herbie wrote:

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

When would I want to use it?


Herbie

ScanIAm wrote:



Dr Herbie wrote:  phreaks wrote:  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

That sounds interesting, now. 

Can it deal with differentials and integrals?  Or do you need to approximate?

W3bbo wrote:



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?

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.

magicalclick wrote:

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.

Andrew Davey wrote:

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

JChung2006 wrote:



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?

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.

Reference

Don Clugston wrote:

I have been trying to come up with a convincing use case for the new
mixins (and for metaprogramming in general). My best effort to date can
be found at:
http://www.dsource.org/projects/mathextra/browser/trunk/mathextra/Blade.d

It generates near-optimal x87 asm code for BLAS1-style basic vector
operations. 32, 64 and 80 bit vectors are all supported.

Compile with -version=BladeDebug to see the asm code which is generated.

Typical usage:

void main()
{
     auto p = Vec([1.0L, 2, 18]);    // a vector of 80-bit reals.
     auto q = Vec([3.5L, 1.1, 3.8]);  // ditto
     auto r = Vec([17.0f, 28.25, 1]); // a vector of 32-bit floats
     auto z = Vec([17.0i, 28.1i, 1i]); // a vector of 64-bit idoubles
     real d = dot(r, p+r+r);
     ireal e = dot(r, z);
     q -= ((r+p)*18.0L*314.1L - (p-r))* 35;
     d = dot(r, p+r+r);
}

Notice that mixed-length operations (real[] + float[] - double[]) are
supported.

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.

Enjoy.

Andrew Davey wrote:

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