It allows your data and function definitions to take as few lines of code as they should be taking.

Record and variant declarations, which are given on a single line usually, would correspond to one member per component and a class per constructor in C#. The LOC ratio is large, even more if you define redundant accessors and follow other ‘good style’ guidelines.

Pipelining is something you can do about the same in C# (although the examples you’ve looked at have likely been simple), and this is thanks to additions inspired exactly by the paradigm F# is representing.

The family of languages F# comes from is very old though, it could be less verbose. In a Haskell-like language, which is more to my preference, you could define your function as:
squarelist = map (^2)
It gets more fun with larger examples of course, such as where the name is not longer than the definition.

To find computations where F# gets more concise you have to look at recursive algorithms, uses of the variant types and such. A function to insert a node into a binary tree might be 5 lines in F#, but 50 in C#.

The code ends up being more horizontal, and your eyes stay on the same line more often when you’re reasoning instead of jumping around the page.

You might not care much for all the line counting being used to C#, but compact code is certainly easier to navigate and manipulate rapidly.

I recently wrote a physics engine in C#, and taking care to clean up and optimize all the code I took from, I ended up at under 1k lines, being fully featured. This should make the engine excellent for educational and customization purposes.
If I’d written it in F# (it was my first use of .NET, so I somewhat needed IDE hand-holding), it might be even half that. How cool would that be.

I also recently took a look at your SyntaxBox component, it was like 30k lines? After some problems and more browsing I decided I’d write my own renderer and parser, in F# this time; I don’t think it will be above 1k lines, with all the same features. That’s sort of my coding style.

Ahh, cheers

it’s good that you independently came up with the MiscUtil stuff which is impressive, but it is nothing like the performance of inline, doesn’t play nice with mixing compatible types with coercion and doesn’t support other user types that provide operators
Want your Complex struct to work for example? code it all yourself.

> “I’m building DSL’s/compilers too, and I’m still not sold on F#.”

Truly amazed.

Try this in c#
http://blogs.msdn.com/ashleyf/archive/2010/01/15/fscheme-0-0-0.aspx

you mean like this? :-)
http://rogeralsing.com/2008/02/27/linq-expressions-calculating-with-generics/

(ok, it’s not 100% clean)

And it’s not like I only do LOB things.
I’m building DSL’s/compilers too, and I’m still not sold on F#.

Your expectations seem way too high. There will be plenty of stuff of about the same effort, plenty much nicer in c# (bit manipulation, massively/heavily recursively dependent type hierarchies) and plenty much nicer in f#.

Many of the examples given to you that really are much better in f# you haven’t acknowledged but the sort of people using them in finance aren’t going to just put the code online :)

Another one you can’t ever approximate:

Ever found the inability to express operators in generic constraints in c# a pain? take a look at ‘inline’ c# has nothing like it at all.

That those things don’t matter to you (or to many LOB apps) is by the by. Not every one ids doing what you do.

That doesn't mean that I think F# is a horrible language, it means that what I've seen so far isn't that exciting.

I explicitly asks for samples that can enlighten me.
Read the bottom part of the post…

My arguments are based on the samples that have been shown in public on F#.
e.g. various async RSS readers and what not.
Pretty much all of those samples can be done in C# with almost the same amount of code.

First, I don’t see where F# is being marketed as the “new best thing”. Perhaps you should site examples. After browsing over msdn.microsoft.com/fsharp and msdn.microsoft.com/visualstudio, I didn’t see anything to support your claim. The titling on the F# page reads:

“F# is a functional programming language for the .NET Framework. It combines the succinct, expressive, and compositional style of functional programming with the runtime, libraries, interoperability, and object model of .NET.”

Pretty benign statement of fact that is.
Not only am I not seeing your point, I’m starting to thing you’re trolling for … I don’t know what… traffic? attention? There’s no interesting debate happening here.

never, ever has it done this.

The people that wrote f# admit it’s abilities are better at ‘programming in the small’ rather than writing vast interlinked OO libraries (like say a widget toolkit) but that the in the small bits can be massively powerful and then trivially exposed in most cases to other more conventional .Net languages.

You are putting words in their mouth, this is… disingenuous. You may have a point, but you must argue that point from some reasonable basis.

I have seen *immensely* powerful and useful ‘scripts’ in f# with some decent backing functionality (mix of f# and c#) that utterly removes the need for previous use of statistical analysis toolkits like R/S+. They are faster, 64bit capable, debug-able with VS, much easier to tweak to how the team wants it.

That most of the primary developers were trained in FP from university helps, but the people with no previous FP knowledge now using the system are vastly more productive.

I’m well aware that there are domain problems that F# solves much better than C#.
But Microsoft markets F# as the new best thing, functional programming für alles.

And in that aspect, it fails, far from everyone will need it.

So what I’m saying is that I don’t get it from the perspective of the MS marketing hype.

It isn’t for everyone, it doesn’t make life easier for the majority of developers.

C# let us write considerably less code than if we would write the same code in CIL.

F# doesn’t let us write considerably les code than C#.
It helps on some areas, but IMO, not enough give a better ROI than C# in most cases.

>>Why doesn’t C# do tail recursion? it has been in the BCL since 2.0, improvements have been made in it’s structure with 4.0.

Because you can write itterative algorithms that are easier for normal people to grasp than some recursive beast?