Getting started with the F# and .Net ecosystem
There was a nice video on F# 101 on MSDN recently:<p><a href="https:&#x2F;&#x2F;channel9.msdn.com&#x2F;Shows&#x2F;On-NET&#x2F;A-tour-of-F-with-Phillip-Carter" rel="nofollow">https:&#x2F;&#x2F;channel9.msdn.com&#x2F;Shows&#x2F;On-NET&#x2F;A-tour-of-F-with-Phil...</a><p>There are two passages that I found amusing.<p>First the guest mentions the merits of F#&#x27;s deep implicit typing, where the use of a function at the top may determine the typing of other nested functions. And as one would expect with this level of things happening implicitly, it is very easy to get lost in what is going on, which is exactly what happened to the guest at minute 27, where he couldn&#x27;t figure out why the F# compiler wasn&#x27;t implying the correct type.<p>Later on the guest mentioned that for all their API, they actually create a signature file (i.e. a header file) where you have to declare every function signature separately from the implementation. The host diplomatically mentions that perhaps this might maybe be a little bit cumbersome to maintain. The answer is that it&#x27;s not a problem, as the program simply doesn&#x27;t compile if you have a mismatch.... Hum.<p>I like certain aspects of it, not using too many special characters (kind of python&#x2F;vb style), the immutability, etc. But I can&#x27;t say I am sold and ready to switch though. And many of what are presented as key features are just not the kind of things I have any use for, like declaring lists of consecutive numbers (can&#x27;t remember the last time I needed one) or F# type providers (I rarely have to deal with unexpected file data formats).