

.NET Fiddle adds F# - refactormonkey
http://dotnetfiddle.net/AT4DxW

======
agentultra
I found F# to be rather neat. This is a great way to see for yourself.

~~~
JeremyMorgan
I've done very little but it seems really concise. I like that.

One place some predict it will emerge is in the Web API arena, and I could
totally see that happening.

~~~
dyml
Why? What makes it better than C# in web Web API area? (honest question)

~~~
bjg
Type providers for one: [http://msdn.microsoft.com/en-
us/library/hh156509.aspx](http://msdn.microsoft.com/en-
us/library/hh156509.aspx)

[http://channel9.msdn.com/posts/Tomas-Petricek-How-F-
Learned-...](http://channel9.msdn.com/posts/Tomas-Petricek-How-F-Learned-to-
Stop-Worrying-and-Love-the-Data)

~~~
_random_
Anything specific on F# applied to Web API?

~~~
bunderbunder
F# has asynchronous workflows, which is a nice API for task parallelism built
on computation expressions, which are sort of tamed monads.

That edge dulled quite a bit with C# 5.0 and async/await, though.

------
virtualwhys
Cool to "see" F# in action.

Like the union types, but not so much the list operations; seems more natural
to:

[1;2;3;4] filter isEven sum

vs.

List.filter isEven [1;2;3;4] |> List.sum

in Scala it's: List(1,2,3,4) filter isEven sum

Of course I'm not familiar with F# so don't know all of the WIN within (Type
Providers, for example, are very impressive, would love to see that on the
Scala side of the fence one day).

~~~
bunderbunder
I've got little experience with Scala, but judging from your sample it looks
like what's happening is that Scala follows more Java-y idioms for how code is
structured.

So in

    
    
      List(1,2,3,4) filter isEven sum
    

it looks like filter and sum are instance methods on the List class, and I'm
guessing isEven is a predicate that's being passed as an argument to the
filter method.

F# leans closer to its functional roots in this respect, so it's more
idiomatic to keep object-oriented constructs at arm's reach in most your code.
The language has full support for OOP, it's just that you're not expected to
trot it out except when you're writing public interfaces that are meant to be
consumed by code that might be written in C# or VB.NET. So the List class
mostly sticks to static methods in its public interface because that approach
fits better with traditional functional idioms.

That gets you as far as something like this:

    
    
      List.sum (List.filter isEven [1;2;3;4])
    

The next step is the "pipeline" operator, which is defined as

    
    
      let inline (|>) x f = f x
    

So it's just letting you swap a function and its argument, which facilitates
reorganizing the code so that the functions are listed in the order in which
they execute. That's what gets you to the example you give - or better yet:

    
    
      [1;2;3;4]
      |> List.filter isEven
      |> List.sum
    

which I think captures some of the natural expression that you were talking
about while still sticking with functional idioms instead of object-oriented
ones.

~~~
jdmichal
> So the List class mostly sticks to static methods in its public interface
> because that approach fits better with traditional functional idioms.

And also fits perfectly with the C# and VB.NET extension method syntactic
sugar, which was used extensively for LINQ. They're really just static methods
in the .NET VM and bytecode.

~~~
frowaway001
> that approach fits better with traditional functional idioms

Just interested, what's the real value here? "Familiarity" alone seems to be a
pretty poor reason.

> They're really just static methods in the .NET VM and bytecode.

Doesn't this mean that either your methods won't be dynamically dispatched or
that you would need to rewrite your code if you ever change from e. g. List to
Array?

Looks like a bad compromise to me.

~~~
jdmichal
> Doesn't this mean that either your methods won't be dynamically
> dispatched...

The MSIL (.NET bytecode) for calling an extension method and a static method
are exactly the same. So yes, it will not be dynamically dispatched.
Specifically, it emits a "call" and not a "callvirt" instruction.

However, the compiler will always prefer a class method over an extension
method of the same signature. Meaning that extension methods can be
specifically implemented by a class and the compiler will emit a "callvirt"
instruction for that instance method instead.

> ... or that you would need to rewrite your code if you ever change from e.
> g. List to Array?

I'm not sure what you mean here. Arrays implement IList, so if you need random
access, you would just write a method against IList. If you don't need random
access, you should write it against IEnumerable, which all collections
implement.

~~~
jasomill
Perhaps what the parent is saying is that if you implement an extension method
to IList, you can't subsequently implement an extension method to Array and
expect it to be called on an Array _stored in an IList variable?_ Which is
true for exactly the reason you state.

~~~
jdmichal
Ah, yes. That would be true.

------
zequel
Can anyone comment how F# compares to other functional languages? Just
curious.

~~~
throwaway344
F# is very un-functional in many ways. Immutable variables are the default but
mutable variables are made with just the "mutable" keyword. There are also
lots of imperative control structures, like while, and for. Those two combined
means that imperative algorithims typically have two distinct translations
into F#.

First you can translate it literally, where F# looks like a slightly more
verbose version of Python. Second you can exploit all the functional features
of F#, and using immutable variables, recursion and pattern matching.

F# also has extensive support for OOP, and uses it where OCaml-ers might use
modules or functors.

In that way, F# can be a sort-of stepping stone between the imperative, OOP C#
to more functional features of F#.

~~~
mmavnn
Un-functional might be a bit misleading for an ML-based, default immutable
language. Impure might be slightly more accurate.

Having seen F# written by C# coders who've just learnt the syntax, and haskell
programmers who are having to work in a .net environment, I'd say F# does a
fairly good job of supporting both. It does make some trade offs to allow easy
interop with the rest of the .net world (it's type system is much less
powerful than Haskell, Scala or (especially) Idris) but depending on your
environment that can be out weighed by the massive scale of the .net
ecosystem, easy interop with your existing .net code and very, very good
tooling.

~~~
throwaway344
Yeah, perhaps unfunctional wasn't the best word I could use. Either way, I'm a
huge fan of F# and I think it's imperativeness is all-in-all a very good thing
for adoption of the language.

------
balsam
Anybody managed to install F# on Ubuntu? There are recommended steps [0] but
they've never worked for me even on a new 13.04 (& later) image on
DigitalOcean.

[0] [http://fsharp.org/use/linux/](http://fsharp.org/use/linux/)

~~~
profquail
I use F# on Windows and FreeBSD, but I've used it on Ubuntu a few times before
for testing. Here's how I did installed it:

    
    
      git clone git://github.com/mono/mono.git
      cd mono
      autogen.sh
      sudo make install clean
      cd ..
      git clone git://github.com/fsharp/fsharp.git
      cd fsharp
      autogen.sh
      sudo make install clean
    

It takes a while to build Mono from scratch, but this way has always worked
for me.

~~~
balsam
Your steps are almost the same as the one I linked. But I tried them, just in
case. And it still does not build. The fsharp build fails with some error
about casting types. Do you have version details?

~~~
profquail
Try building the 'fsharp_30' branch instead. The master branch just switched
over to F# 3.1, so its possible they haven't worked out all of the bugs for
every possible system yet.

When I ran F# on Ubuntu before, it was on the x86 version of 12.04 LTS. I used
whatever the latest version of Mono was; I don't remember specifically, but it
was almost certainly one of the 3.2.x versions.

Would you mind posting the build output from your F# build that fails (e.g.,
to pastebin or Gist)? I can forward it along to the right people so it gets
fixed. Or, post it as a Github issue:
[https://github.com/fsharp/fsharp/issues](https://github.com/fsharp/fsharp/issues)

------
refactormonkey
Small interruption. Looks like scaling to 2 servers on Azure to handle extra
traffic crashed the original one.

~~~
el_tone
Azure will reset your VMs when you update their configuration. Normally this
involves a rolling reset but as you only have one instance this was not
possible.

~~~
refactormonkey
Thanks for the info. I thought changing Scale would keep original server and
just add new ones. But I guess it is a bit more intrusive.

------
physicslover
I would like to see an interactive loop to fsi. Seems like you could use
websockets for this.

~~~
latkin
Another option you might want to look at is
[http://www.tryfsharp.org/Create](http://www.tryfsharp.org/Create) Runs code
locally via Silverlight.

------
JeremyMorgan
I'm getting my fizz buzz on.

