F# programming language

[Jon Harrop]

Like a business application that has grids and dialogs to edit
"entities" that are stored in a database? That's what the majority of
applications seem to be... but I fail to see how a functional solution
would reduce the amount of code for these apps.

Sounds like an ideal task for higher-order functions.

Don't get me wrong, I
think functional programming languages have their applications but just
because you have a hammer doesn't mean that everything else is a nail.

Sure. That was based on my own experience, which is mostly science/
graphics/compilers.

 

[Kevin Spencer]

Yes, I realized it while eating my Thanksgiving dinner. I haven't touched a
guitar in 10 years now. Back then I would have known it right off the bat.
I'm so ashamed!

:-(

Kevin Spencer
Microsoft MVP
Ministry of Software Development
http://unclechutney.blogspot.com

Never trust a dunderhead with a blunderbuss.

Generally speaking, only when using a 12 tone diatonic scale [1]

<%= Clinton Gallagher
NET csgallagher AT metromilwaukee.com
URL http://clintongallagher.metromilwaukee.com/
MAP http://wikimapia.org/#y=43038073&x=-88043838&z=17&l=0&m=h

[1] http://en.wikipedia.org/wiki/Diatonic

Still wrong. F# would be Gb

 

[Kevin Spencer]

I would think that the greatest benefit of XAML is eXtensibility. Being XML,
it is inherently extensible, platform-independent, and transformable (via
XSL) to virtually any GUI format.

--
HTH,

Kevin Spencer
Microsoft MVP
Ministry of Software Development
http://unclechutney.blogspot.com

Never trust a dunderhead with a blunderbuss.

 

[Christopher Ireland]

Jon Harrop wrote:
| Microsoft Research are developing a functional programming language
| called F# for .NET and I've been playing with it recently. I've
| uploaded some demos here:
|
| http://www.ffconsultancy.com/dotnet/fsharp/
|
| I'm keen to see what Windows developers think of this language as
| we're considering using it to develop commercial applications on the
| Windows platform.

I've just read on Don Syme's blog that you've started a blog of you're own
... all the best of luck with it!

P.S. it would be great if ray tracer compiled with the latest publicly
available version of F#!

 

[Jon Harrop]

P.S. it would be great if ray tracer compiled with the latest publicly
available version of F#!

No, that's a really bad idea. If you can tweak the code then you'll sink an
enormous amount of time into fiddling with it. Take yesterday for example,
I barely got any work done... ;-)

 

[Christopher Ireland]

Jon Harrop wrote:
| Christopher Ireland wrote:
|| P.S. it would be great if ray tracer compiled with the latest
|| publicly available version of F#!
|
| No, that's a really bad idea. If you can tweak the code then you'll
| sink an enormous amount of time into fiddling with it. Take yesterday
| for example, I barely got any work done... ;-)

Out of interest, do you find your code more or less buggy in F# than in C#?
If there is a bug, in which language is it easier to trace and fix?

 

[Laurent Bugnion]

Hi,

Yes, I realized it while eating my Thanksgiving dinner. I haven't touched a
guitar in 10 years now. Back then I would have known it right off the bat.
I'm so ashamed!

:-(
Kevin Spencer

And now it's on Internet for ever and ever bwahahahaha ;-)

Don't let this spoil your holidays.

Greetings,
Laurent

 

[Lucian Wischik]

Out of interest, do you find your code more or less buggy in F# than in C#?
If there is a bug, in which language is it easier to trace and fix?

The bugs were of a completely different nature. My F# code ends up
being far more ambitious in scope, far more sophisticated in its data
structures and algorithms, deals with more complex problems. The bugs
I get in it tend to be conceptual ones of algorithm design. My C# code
ends up less ambitious, more "engineery". The bugs I get in it tend to
be normal bugs, like missed initializations or unkept invariants. Also
the C# code never has the same "agility" as F#, the agility to easily
restructure the algorithms and datastructures.

The F# compiler tends to catch more bugs than the C# one does. That's
because it's somehow easier in F# to describe your abstractions in the
type system.

When there are normal bugs in F#, though, they're harder to trace than
C#. I think that's because F# code is more concise and tends to use
"lambdas" a lot more. Consider this F# code:
foldr (fn x y => x+y) 0 mylist;
versus this C# code:
int sum=0;
foreach (int x in mylist)
{ sum+=x;
}
In the C# it's easy to know where to set your breakpoint and where to
run it. In the F# it's not.

 

[Christopher Ireland]

Lucian Wischik wrote:
| The bugs were of a completely different nature.

That's very interesting, thank you for your insights!

 

[Laurent Bugnion]

Hi,

The bugs were of a completely different nature. My F# code ends up
being far more ambitious in scope, far more sophisticated in its data
structures and algorithms, deals with more complex problems. The bugs
I get in it tend to be conceptual ones of algorithm design. My C# code
ends up less ambitious, more "engineery". The bugs I get in it tend to
be normal bugs, like missed initializations or unkept invariants. Also
the C# code never has the same "agility" as F#, the agility to easily
restructure the algorithms and datastructures.

The F# compiler tends to catch more bugs than the C# one does. That's
because it's somehow easier in F# to describe your abstractions in the
type system.

When there are normal bugs in F#, though, they're harder to trace than
C#. I think that's because F# code is more concise and tends to use
"lambdas" a lot more. Consider this F# code:
foldr (fn x y => x+y) 0 mylist;
versus this C# code:
int sum=0;
foreach (int x in mylist)
{ sum+=x;
}
In the C# it's easy to know where to set your breakpoint and where to
run it. In the F# it's not.

Interesting post, thanks for sharing.

One more question though: You mention that C# is more "engineery". Is it
your opinion (like I think after reading what you wrote) that C# is more
targeted at software engineers (like me) and F# at scientists? I got the
feeling that scientists are more able to deal with the abstraction level
you mention, while engineers prefer to see what's going on in the code.

What are your thoughts?
Greetings,
Laurent

 

[Jon Harrop]

Jon Harrop wrote:
| Christopher Ireland wrote:
|| P.S. it would be great if ray tracer compiled with the latest
|| publicly available version of F#!
|
| No, that's a really bad idea. If you can tweak the code then you'll
| sink an enormous amount of time into fiddling with it. Take yesterday
| for example, I barely got any work done... ;-)

Out of interest, do you find your code more or less buggy in F# than in
C#? If there is a bug, in which language is it easier to trace and fix?

I'm coming from a C++ vs ML background, so I can't comment on C# vs F#
specifically. For ML vs C++, I'd say:

1. ML is ~10x more productive, i.e. 1/10th development times.
2. ML has 2-5x higher code density.
3. ML code is much more reliable than C++ code but I can't quantify how
much.

I guess the reliability of ML code is reflected in the development time.

 

[Jon Harrop]

If there is a bug, in which language is it easier to trace and fix?

When I started programming in OCaml I found its errors messages mostly very
good but sometimes devilishly obscure. F# is in a similar boat.

However, it only took me 6 months to get more efficient in OCaml programming
than I was in C++, having been programming in C++ for 10 years.

Type inference is the main difference. You rarely declare types in F# code
because the compilers infers them all for you. That is usually great
because you write a lot less code and the code is a lot clearer. However,
when it goes wrong, the error messages can be confusing primarily because
they'll contain the wrong types because the wrong types have been inferred.

I should also mention that, for a large class of problems, F# code tends to
work first time once it is compiled. Aside from good language design, I
don't think there is any logical reason to expect that but it certainly
works. There are examples where F# is less effective at checking your code
but it always seems to remain significantly more effective than the
competition.

 

[Jon Harrop]

One more question though: You mention that C# is more "engineery". Is it
your opinion (like I think after reading what you wrote) that C# is more
targeted at software engineers (like me) and F# at scientists?

I'm a scientist and I'd actually have said quite the opposite. F# seems to
be taking leaves from Matlab's book and I consider Matlab to be an
engineer's tool.

There's a lot of overlap between scientists and engineers, of course, and I
think a real killer feature for F# will be a graphical version of the
interactive mode. It is actually really easy to start writing one, you just
replace the pretty printer for a given type with one that pops up a window.

I got the
feeling that scientists are more able to deal with the abstraction level
you mention, while engineers prefer to see what's going on in the code.

We probably need a quiz to answer that. If the engineers in the audience can
understand the comparison I drew between the C++ and OCaml implementations
of my ray tracer then I think they'll be fine with F#:

http://www.ffconsultancy.com/free/ray_tracer/comparison.html

I'll put a similar page up comparing C# and F# implementations if you
like...

 

[Christopher Ireland]

I'll put a similar page up comparing C# and F# implementations if you
like...

Thanks again for your input, Jon.

Yes please <g>!

Cheers!

Chris.

 

[Laurent Bugnion]

Hi,

I'm a scientist and I'd actually have said quite the opposite. F# seems to
be taking leaves from Matlab's book and I consider Matlab to be an
engineer's tool.

Really? I remember Matlab from my engineer's school day, wouldn't like
to use that to build a product (I mean, something I can actually sell to
someone). It was a great tool to study mathematical transformations and
the like, but when I want something done, I really prefer C#.

There's a lot of overlap between scientists and engineers, of course, and I
think a real killer feature for F# will be a graphical version of the
interactive mode. It is actually really easy to start writing one, you just
replace the pretty printer for a given type with one that pops up a window.


We probably need a quiz to answer that. If the engineers in the audience can
understand the comparison I drew between the C++ and OCaml implementations
of my ray tracer then I think they'll be fine with F#:

http://www.ffconsultancy.com/free/ray_tracer/comparison.html

I'll put a similar page up comparing C# and F# implementations if you
like...

That would be nice, but I don't think I will work with F# in the near
future (no time...), so do it only if you really have the time, or if
you gain something from it.

Thanks!
Laurent

 

[Ben Voigt]

Microsoft Research are developing a functional programming language called
F# for .NET and I've been playing with it recently. I've uploaded some
demos here:

http://www.ffconsultancy.com/dotnet/fsharp/

I'm keen to see what Windows developers think of this language as we're

Useful for math and logic, not so much for GUI stuff which really requires
imperative programming. But .NET will let you call back and forth so use an
appropriate mixture of languages.

considering using it to develop commercial applications on the Windows
platform.

Last I checked F# was only available for research with no option for a
commercial license. That could be an insurmountable obstacle.

 

[Lucian Wischik]

Type inference is the main difference. You rarely declare types in F# code
because the compilers infers them all for you. That is usually great
because you write a lot less code and the code is a lot clearer. However,
when it goes wrong, the error messages can be confusing primarily because
they'll contain the wrong types because the wrong types have been inferred.

The most important F# lesson I learnt: always declare complete types
for my functions! And declare types for any complicated-looking
variables. This habit reduced my type-inference-debugging-time a lot.

 

[Jon Harrop]

Really? I remember Matlab from my engineer's school day, wouldn't like
to use that to build a product (I mean, something I can actually sell to
someone). It was a great tool to study mathematical transformations and
the like, but when I want something done, I really prefer C#.

You wouldn't use Matlab to make an application but you might write a toolbox
for Matlab and sell it. I think it is possible to do the same thing for F#
but, at the same time, you can write your applications in F# instead of C#.

 

[Jon Harrop]

Useful for math and logic, not so much for GUI stuff which really requires
imperative programming.

I'm going to try to write some GUI programs and I'll see how F# compares.
Presumably C# is likely to come out on top when there is a big GUI and not
much under the hood?

But .NET will let you call back and forth so use
an appropriate mixture of languages.

I've obviously been writing F# code that calls C# APIs but I've yet to try
it the other way around. I assume you have to restrict yourself to the C#
subset of F# when you want your F# code to be callable from C#.

Potentially I could write code in F# and sell it as a DLL for other .NET
programmers to use and they would never even know that I wrote it in F#.
I'd like try that but I've no idea if it is feasible...

Last I checked F# was only available for research with no option for a
commercial license. That could be an insurmountable obstacle.

I'm sure you can write commercial software in F# and sell it. I think the
author is trying to get the whole thing released under a commercial license
so you will even be able to bundle the F# compiler with your product, e.g.
to do metaprogramming.

 

[Christopher Ireland]

I've obviously been writing F# code that calls C# APIs but I've yet to try
it the other way around. I assume you have to restrict yourself to the C#
subset of F# when you want your F# code to be callable from C#.

I think it must be, given that the assemblies built from F# are MSIL.

Try downloading Reflector for .NET (http://www.aisto.com/roeder/dotnet/) and
opening your raytracer.exe .. you'll be able to see the whole thing in C#
(or even Delphi, for that matter <g>).

Cheers!

Chris.