kvb

F# units can certainly handle the problem given a fixed matrix size, but for a general method handling arbitrary dimensions you'd need variadic measure arguments, which aren't supported (and would probably require quite a bit of bookkeeping for this particular problem, in any language).

It's not true that each element can have its own units; given an MxN matrix there are only M+N-1 degrees of freedom (basically you can choose arbitrary units for each element in the first row and then a single multiplicative factor between the first row and each other row). Otherwise you'll find that either left or right multiplication won't have any compatible vector types.

I think there are several reasons to prefer F#. First of all, you can use all of these features in F# today, but when's C# 7 going to be available, and will the "strong interest" features (not to mention type providers) all make it?

But more fundamentally, adding features like these to C# is awesome, but there's no way to remove now-obsolete patterns without breaking legacy code, so it's still possible to shoot yourself in the foot in many ways that you can't in F#.

Some other authors have also addressed this question recently: [1], [2].

[1] http://fsharpforfunandprofit.com/posts/is-your-language-unre... [2] http://blog.ploeh.dk/2015/04/15/c-will-eventually-get-all-f-...

Could you justify this assertion? Here[1] is an analysis by Andreas Rossberg that indicates that this isn't the case.

[1] http://stackoverflow.com/a/23019436

It depends on what you're looking for, of course. There are certainly a few unique features that are very nice (e.g. type providers, units of measure, etc.). Compared to Scala, there's much better type inference and more of an emphasis on the functional as opposed to object-oriented side, though both languages support both paradigms (and Scala supports things like higher-kinded types which F# lacks). Compared to other ML-family languages, F# has broader access to libraries thanks to its very nice .NET interoperability (but much weaker support for true ML-style modules). F#'s tooling is also much better than that of most functional languages (especially on Windows via Visual Studio, but people seem very happy with the tooling on Linux with Mono, too).

But personally the thing I most like about F# is the community.

Andreas Rossberg comments a bit on the differences between ML modules and Scala objects/traits here [0].

[0] http://stackoverflow.com/questions/23006951/encoding-standar...

Can you elaborate on the issues with running Java on the CLR? I always thought IKVM had a great reputation.

Have you looked at the open source F# type provider for accessing R[1]? It's one way to use R from Visual Studio today.

[1] http://bluemountaincapital.github.io/FSharpRProvider/

F#'s not a pure functional language, it's a multi-paradigm language that has very good support for the .NET object model and imperative programming, even if it is "functional-first".

I can't personally vouch for them, but perhaps try http://fsharp.org/use/mac/ and http://fsharp.org/use/linux/, or the more in-depth http://fsharp.org/guides/mac-linux-cross-platform/?

Increased pesticide use can be a bit misleading, since an increased amount of something like Roundup could still be better for the environment than the typical amount of alternative pesticides.

Thanks for the plug. While it's probably not clear from those two links, the IL builder actually tries to use the type system to enforce much more rigid correctness rules. For example, removing any of the opcodes in this example will result in a compile-time error because the IL would become invalid:

    il {
        ldc_i4 6
        ldc_i4_0
        ldc_i4 7
        add
        mul
        ret
    }

Sadly, there are some circumstances where XAML is virtually inescapable (e.g. constructing templates; you can use the deprecated FrameworkElementFactory, but it's pretty ugly).

Taken at face value I think this is misleading - a typical F# generic type will be represented as a normal .NET generic type at the IL level. However, it is true that some types are erased, like unit-of-measure type arguments or types surfaced by type providers.

Held back from what? I mean, I'd love it even more if it had higher kinded types, but it's a pretty great language as is.

Your String.Split example seems like more of an indictment of the language/library design than the GC. For instance, the language could compile uses of an array literal to a static value that's reused across invocations.

Yes, higher rank types are no problem for C# or Java generics. It's higher-kinder types that are unavailable.

You can easily do this even in a language like C#, it's just that the syntactic overhead can be a bit much:

    interface Transducer<A,B> {
        Func<R,B,R> Apply<R>(Func<R,A,R> f);
    }

Tons of stuff has been productized in various forms. .NET generics, for instance, were initially developed in MSR Cambridge. MSR research has contributed to speech recognition, search technologies in Bing, Excel's Flash Fill, SQL Server's Hekaton in-memory architecture, and many other products.

This is roughly correct, but see Andreas Rossberg's caveats here[1] for some considerations that may be important depending on what you're trying to do.

[1] http://stackoverflow.com/a/23019436/82959

The JVM doesn't directly support higher-kinded types either. It might be a pain to come up with a scheme that interops nicely with other .NET languages, but in principle there doesn't seem to be anything that would make it impossible to build a Scala compiler for .NET (though it might involve lots of boxing and downcasts).

Why do you say there is no downside? As Jonathan Kaplan points out in the comments of the article Crito links to, Ebola is not 100% fatal and several drugs that have worked in animals have proven to have catastrophic effects when administered to humans (see e.g. TGN1412 [1]).

[1] - http://en.wikipedia.org/wiki/TGN1412

Kinect was something like the fastest selling accessory of all time, so you can't expect too many hits at that level. But there have certainly been many other consumer-visible successes, like Excel's flash fill or Skype's upcoming real-time translation. Then there are enterprise things that consumers may be unaware of, like SQL Server's Hekaton technology. And beyond that, there are lots of additional projects that meaningfully translate to value to Microsoft but that aren't really externally visible, like speech recognition improvements, search engine ranking techniques, datacenter networking improvements, efficient algorithms for traffic routing and prediction, etc.

Sure, but there are lots of failures in pretty much every language, right?

You might also take a look at F# running on Xamarin's stack, which is probably a bit more mature.

Great answer, but on a pedantic note, it's not quite true that the derivative of a data type is its zipper. The derivative is the one-hole context, but the zipper is more like a one-substructure context instead. There's a bit more elaboration here: [1].

[1] http://en.wikibooks.org/wiki/Haskell/Zippers

Do you feel that rape jokes are appropriate in every forum? Even if rape could be a fruitful topic "in the hands of an excellent comedian", that's hardly the situation being discussed is it?

I don't think that's fair at all; F#'s integration with the .NET type system is one of its best features. I find that creating class types (and instances) in F# is usually easier than doing so in C#. And with object expressions, you can even program in an arguably purer object oriented style, declaring only interfaces but never concrete class types.

Seems like parametricity ensures that

    Transducer a b 

is isomorphic to

    b -> [a]

Am I missing something?

That's not accurate. In fact, in the .NET 2.0 timeframe the opposite was the case (the 64-bit JIT would fail to honor the IL tail. prefix in many cases, though it would also make tail calls in other cases even when the prefix wasn't applied)[1]. But as of .NET 4.0, both platforms honor the tail. prefix except in a very limited set of circumstances[2] (e.g. calls from untrusted code to trusted code).

As far as I know, F# is the only reasonably popular .NET language to emit the tail. prefix, though[3].

[1] http://blogs.msdn.com/b/davbr/archive/2007/06/20/tail-call-j...

[2] http://blogs.msdn.com/b/clrcodegeneration/archive/2009/05/11...

[3] http://blogs.msdn.com/b/fsharpteam/archive/2011/07/08/tail-c...