Back to Questions
3.2k
views12
comments
F# tutorials clean slate
f#

Hi,

First exposure to F# at a local INETA presentation last week. I've been surfing and toying with the latest CTP and VS 2008 since. There's a lot to like with what I've seen so far. Unfortunately, nearly every tutorial, blog post and video has put F# in the context of C#. Sure, most coming to F# will have a C# or VB perspective - but even for these, a clean slate approach might be better.

What I'd like to see is F# presented as a new mindset, as well as a new language. Yes, interfacing with C# and VB code is important, but save that for later.

Anyone know of some tutorials and videos that avoid all the imperative language references?

Thanks,

BRN..

.

I haven't really found a tutorial with the requirements you mention (although I haven't really looked for one). I knew Haskell, Lisp and ML before I started using F#, so it was easier for me to identify and use the bits related to the functional paradigm, so I think a good strategy would be to look into other functional languages to check where you need to focus your efforts.

The Foundations of F# book starts by using the functional bits without really mentioning C# until later. Maybe that would help.

By on 11/20/2009 7:53 AM ()

Hi,

Thank you. Each reference helps. I suppose the biggest difference between F# and other functional languages is that Microsoft intends it to be a full member of the managed languages it will support within Visual Studio - and, I'm guessing, may become the preferred language for other MS technologies, like DSL Tools.

I'd just like to encourage others that will be creating tutorials and introductions, of the value of not assuming a C# to F# translation is necessary or preferable.

Thanks for the reference,

BRN..

By on 11/20/2009 10:27 AM ()

Thanks for the info and suggestions, Brian. You have highlighted a real need - ie. the need for a functional programming tutorial in F#.

When I got started with this two years ago it was very difficult to master the FP style, and I found that the OCaml tutorials were the most useful - although there were quite a few difficulties with this approach.

I would recommend the exercises and solutions from the University of Innsbruck. One problem is that it uses OCaml capitalization, and probably other stylistic differences from F#. Another problem is that one of the solutions is a reference to OCaml documentation. I got around that by installing OCaml on a Linux computer - and I have found it useful having OCaml available as an occasional reference for F# problems. Nevertheless, it is a very good kick-start with FP, and will also help you master whatever environment you are using (presumably VS)

Apart from the F# books, as mentioned in the previous response, I would also highly recommend the F# Wikibook. I don't know who's behind that, but whoever it is has done a really good job! It does begin with some comparisons with C#, but quickly launches into functional programming.

By on 11/21/2009 3:15 PM ()

Hi,

Your reference suggestions are appreciated. I probably won't opt to explore OCaml, to get a better handle on F# (but glad some have for me); I'm prone to wander further from immediate objectives out of curiosity. I've added the Wikibook link to a fast growing collection of bookmarked tabs - looks like a good one.

A lot of the C# flavored tutorial/video/references have good content; but the conceptual flow is interrupted, rerouted, or otherwise compromised by the imperative/OOP/C# style/paradigm references.

A concern I have, is that the strong (and highly beneficial), connection to Microsoft and the .Net frameworks, will compel those directing the development of F# to mold it in terms C#/OOP to make it more accessible to accomplished C# developers - is adding the option of mutability a feature or a crutch?

Still too little experience on my part to say; but haven't you seen examples where F# code has been shoehorned into a C#/OOP mindset and style? There are plenty of C#/OOP to F# links out there; hope to find a few that let F# have its head.

Thanks again for the links,

BRN..

By on 11/22/2009 9:11 AM ()

Hi,

>> is adding the option of mutability a feature or a crutch?

mutability is available in OCaml, in mostly the same places as F#. My quick experiment found that one can't declare a mutable "let" variable in OCaml ("let mutable x = o"), but mutable record fields are the same ("type index = {name : string; mutable index : int"}. I assume that this is because the functional programming field found a need for it.

>> haven't you seen examples where F# code has been shoehorned into a C#/OOP mindset and style?

Yes - kinda. A lot of .Net code (eg. a stream reader) translates into nearly identical F# code. I have sometimes wondered whether there is a more "functional" way of doing it, but each time I've tried, haven't been able to find it. The underlying reason (I suspect) is the .Net is object oriented, so, to use .Net, we have to write object oriented code. There are still enermous advantages in using .Net (and not just the libraries), so, overall, it's worth learing the mixed-style approach.

I think you are making a good choice in wanting to master the functional aspects of F#, separate from the OO and .Net style.

Cheers,

Javaman

By on 11/22/2009 3:02 PM ()

Hi JM,

Good points.

During the presentation I saw at local INETA meeting, I asked about the MS CLR and F#. The response was along the lines of what you have said. The CLR will process the code from the different managed languages; but the CLR was written with a C#/OOP mindset - so the current CLR doesn't exploit the functional aspects of F# as well as it might.

I agree, the benefits of being a fully supported .Net language should not be under estimated. (and around here anyway, we get gobs of support from MS; .Net Road Shows, Code Camps, we had a XaML Fest tour stop here in the spring, and the MS Boston/Cambridge facilities are a 2 hour ride from here).

My impression so far, is that F# should make a better partner than C# with data modeling, and data manipulation. Immutability and safety are in line with concerns about inadvertent, or unmanaged, alterations to data. The ORM methodology I use is based on set theory, First Order Logic and predicate calculus - all important in F# as well. We get Tuples out of the box, so what more can I want.

Eventually, I'd like to try to leverage much of what an architect has done in an open source tool (a VS plug-in using DSL custom tools), that supports ORM (using C#), using F# and Silverlight/XaML for a tool that would cover a complementary aspect of the process.

I'm glad I got in after MS has added F# support in VS 2008 and the 2010 beta, and with a more mature syntax and feature set. I'm sure the learning curve is less bumpy than for those that had only Notepad and a CMD window.

Thanks again,

BRN..

By on 11/23/2009 8:04 PM ()

Hi Brian,

Thanks for the interesting points.

Another suggestion for learning F# is to look at the coding problems which come up in these forums, particularly in General Discussions, and Howtos and Snippets.

Many of these problems are about functional programming in F#, and others are about .Net programming that raise interesting issues.

When you see an interesting problem, try and work out the solution yourself. It can be quite enlightening when you've worked out an 8 line solution, and then someone posts a one or two line answer!

This will also get you going with coding, which is what it's all about!

Regards,

JM

By on 12/8/2009 3:04 PM ()

Hi JM,

More good suggestions; thanks.

I've backtracked a bit on saying I wouldn't look at OCaML. I found a book on functional programming, which uses Haskel to illustrate points. While I'd rather not muddy the waters with yet another syntax (as I'm still only learning F#'s), it seems worthwhile. Perhaps it's like taking a bearing from more than one position - it helps to better locate the target. I'm finding it more helpful than using imperative/OOP comparisons.

I take your point about tending towards brevity and elegance (Newton's F=ma and all that); but metrics and motivations are something I've thought about quite a bit. All else being equal, more concise, better performing, quicker into production equates to better code. However, "all else" is seldom"equal."

You're right, no substitute for writing some code, and seeing what happens. Fortunately (for me), F# is far enough along to provide some assistance. FSI is a big help too - immediate feedback. It won't remind me that computing the factorial for 300 (typo'd 30) may take a while; but that would be asking too much.

First significant snowfall here today - enjoy start to summer, down under.

BRN..

By on 12/9/2009 3:43 AM ()

Hi JM,

I found a book on functional programming, which uses Haskel to illustrate points. While I'd rather not muddy the waters with yet another syntax (as I'm still only learning F#'s), it seems worthwhile. Perhaps it's like taking a bearing from more than one position - it helps to better locate the target. I'm finding it more helpful than using imperative/OOP comparisons.

BRN..

That can only strike me as a very good idea. I think that until one masters the functional aspects in isolation, it will always be a bit like trying to win a car race, using an automatic transmission.

And, it should be a lot of fun. I haven't used Haskell myself (apart from "hello, world"), but I've got a book on it there, that I'm intending to work through (Purely Functional Data Structure), as intellectual stimulation, and to make me a better F# programmer. You've inspired me to get on with it.

First significant snowfall here today - enjoy start to summer, down under.

Sighhh... brings back happy memories of a Vancouver winter, many years ago. Still, thanks for the wishes, and I'm looking forward to a hot Christmas, and farm holiday. Enjoy the snow and short days!

By on 12/9/2009 4:28 PM ()

I just started reading "Purely Functional Data Structure" and I can say it is quite good but learning some ML notation before starting with it is recommended.

By on 12/10/2009 4:45 AM ()

Hello Bernadette,

Yours was the first reply to suggest looking at other functional languages as an intro to F#. I think that is good advice for anyone.

One thing that comes through is that the creators of F# have added features to make it useful in OOP/imperative situations as well. Without a sense of the thinking behind functional programming, it's easy to miss the demarcations - and I'd think wondering between paradigms in a program would make it harder to sort out logical errors.

Depending on the programmer's intentions, it may be wise to keep to the functional way of doing things, when F# offers a choice. I wouldn't be surprised if some people, coming from an imperative language background, automatically gravitate to those features of F# that are familiar; and so miss out on the advantages of an alternative approach.

Thanks again for your good advice,

BRN..

By on 12/10/2009 12:35 PM ()

I wouldn't be surprised if some people, coming from an imperative language background, automatically gravitate to those features of F# that are familiar; and so miss out on the advantages of an alternative approach.

I agree with you, having non-functional tools available distract you from using the functional ones unless you are familiar with the paradigm. Furthermore, it makes harder to reveal the functional goodies of F# as it may appear to others like just another .NET language with a slightly cumbersome syntax.

I believe the best way to tackle this problem is to focus on the functional bits from day one and pretty much ignore the rest as much as possible. It might take some time to get used to the paradigm, but the effort pays off since quite a lot of the information relevant to functional programming (specially the one in other programming languages) is less confusing and could be adapted to F#.

On that topic, I came across this Functional Programming Tutorial using Graham Hutton's Programming in Haskell. Highly recommended stuff![8-|]

By on 12/11/2009 7:27 AM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper