Learning F#
-
Josh Smith wrote:
The problem is, the existing F# tutorials SUCK.
Let's ask Chris to change that Java section of CodeProject into a F# section... :)
Hope is the negation of reality - Raistlin Majere
Fernando A. Gomez F. wrote:
Let's ask Chris to change that Java section of CodeProject into a F# section...
Yeah, then it might actually be used!
:josh: My WPF Blog[^] Without a strive for perfection I would be terribly bored.
-
Ennis Ray Lynch, Jr. wrote:
If I had a dollar for all the times I had to explain basic data structures and algorithms ...
You'd be a CompSci professor?
:josh: My WPF Blog[^] Without a strive for perfection I would be terribly bored.
Seriously though, a lot of the code I end up fixing would never had been authored if the original author had a foundation in computer science. I try not to be pedantic and ignore it most of the time but sometimes they are so bad that something must be said for the greater good. My most insane political belief is that social problems can be solved with good education. It equates well to any field.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway -
peterchen wrote:
from -< to
Haha. Stop screwing with my brain! ;P
:josh: My WPF Blog[^] Without a strive for perfection I would be terribly bored.
Sorry, this was an honest typo (but a good one! :cool: ) It was supposed to be from -> to, as in mathematical notation, e.g. f: N2 -> N would be equivaluent to C monkeys int f(int x, int y)
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!|FoldWithUs! | sighist -
Sorry, this was an honest typo (but a good one! :cool: ) It was supposed to be from -> to, as in mathematical notation, e.g. f: N2 -> N would be equivaluent to C monkeys int f(int x, int y)
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!|FoldWithUs! | sighistpeterchen wrote:
Sorry, this was an honest typo (but a good one! :cool: )
Ok, I understand. Thanks for the advice!
:josh: My WPF Blog[^] Without a strive for perfection I would be terribly bored.
-
I've been spending some of my free time trying to learn about F# because it seems really interesting. The problem is, the existing F# tutorials SUCK. I think that the language tutorials provided by Microsoft were written by brainiacs in the Microsoft Research group, so it's not really helpful at all. For example, I read that this:
int -> int
...represents a function which takes and int and returns an int. The problem is, the author failed to mention which "int" represents the return type and which the parameter type. :| There's only one F# book out there yet, and all the reviews I've read of it say that it sucks too. Come on MS, if you're gonna publicly announce[^] that F# is on the rise, at least give us some good introductory material first!! Don't make it so f#ckin hard for us! ;)
:josh: My WPF Blog[^] Without a strive for perfection I would be terribly bored.
Hi Josh, First of all, I should mention that I started learning F# more than a year ago and I'm using it a lot (so I'm very glad to hear that it will get more support from Developer Division). Regarding the books, I have seen both of them. "Foundations of F#" by Robert Pickering and I think it is a great book that I would recommend to anyone with C# backround. There is also second book "Expert F#" by Don Syme and others, which explains more details and uses the new F# syntax, so if you want to become F# expert, you'll need this one (too) :-). I agree that there are only a few resources about F#, but I hope that it will get better. As someone already mentioned, you can read an introduction to OCaml language, because F# is largely based on this language. Anyway, I started writing a tutorial about F# some time ago (though it is quite short and covers many things, so it may not be appropriate for a complete beginner in the field). It is almost done :-), but I still have a few remaining parts to finish, but if you (or anyone else) wanted to read at the unfinished version, send me a private message. I hope to publish it on my blog in a next few days. BTW: I'd be glad to post it to the F# section at CodeProject once Chris creates this section :rolleyes:
Homepage: TomasP.net | Photo of the month: Calendar | C# and LINQ, F#, Phalanger: My Blog
Latest article: Phalanger, PHP for .NET: Introduction for .NET developers -
leppie wrote:
It's called common sense, aka from 'int' -> (to) 'int'
You call that common sense? I call that conditioning. Every language I've ever worked with before, all of which are C-based, put the return type on the left side.
:josh: My WPF Blog[^] Without a strive for perfection I would be terribly bored.
Actually, languages like ML (which F# is based on), Haskell, etc all do the same sort of thing. It's very math-oriented.
-
I've been spending some of my free time trying to learn about F# because it seems really interesting. The problem is, the existing F# tutorials SUCK. I think that the language tutorials provided by Microsoft were written by brainiacs in the Microsoft Research group, so it's not really helpful at all. For example, I read that this:
int -> int
...represents a function which takes and int and returns an int. The problem is, the author failed to mention which "int" represents the return type and which the parameter type. :| There's only one F# book out there yet, and all the reviews I've read of it say that it sucks too. Come on MS, if you're gonna publicly announce[^] that F# is on the rise, at least give us some good introductory material first!! Don't make it so f#ckin hard for us! ;)
:josh: My WPF Blog[^] Without a strive for perfection I would be terribly bored.
-
Blanking out one letter of the F-bomb does not make it kid-sister-friendly. Please clean up your language.
bscaer wrote:
Please clean up your language.
:zzz:
:josh: My WPF Blog[^] Without a strive for perfection I would be terribly bored.
-
I've been spending some of my free time trying to learn about F# because it seems really interesting. The problem is, the existing F# tutorials SUCK. I think that the language tutorials provided by Microsoft were written by brainiacs in the Microsoft Research group, so it's not really helpful at all. For example, I read that this:
int -> int
...represents a function which takes and int and returns an int. The problem is, the author failed to mention which "int" represents the return type and which the parameter type. :| There's only one F# book out there yet, and all the reviews I've read of it say that it sucks too. Come on MS, if you're gonna publicly announce[^] that F# is on the rise, at least give us some good introductory material first!! Don't make it so f#ckin hard for us! ;)
:josh: My WPF Blog[^] Without a strive for perfection I would be terribly bored.
Your head's really going to flip when you get to binary functions:
int -> int -> int == int -> (int -> int)i.e. if
plus x y = x + ythen the expression
plus 3is syntactically and semantically correct, and returns a function of type
int -> int. Andplus 3 5is really(plus 3) 5. Learn Haskell[^] first, and then F#'ll be a piece of cake! But you'll miss cool features of Haskell like type classes and such like. -
Your head's really going to flip when you get to binary functions:
int -> int -> int == int -> (int -> int)i.e. if
plus x y = x + ythen the expression
plus 3is syntactically and semantically correct, and returns a function of type
int -> int. Andplus 3 5is really(plus 3) 5. Learn Haskell[^] first, and then F#'ll be a piece of cake! But you'll miss cool features of Haskell like type classes and such like.Stuart Dootson wrote:
Your head's really going to flip when you get to binary functions:
Sounds like fun! You seem to know quite a bit about functional programming, so let me ask you a question. From a business app developer's perspective, what are the benefits of using a functional language like Haskell in a real world app dev scenario? I know that there is a lot of fervor around multi-core/multi-processor computing, but what else is there? I'm just looking for more fuel to add onto my F# fire. Thanks. :)
:josh: My WPF Blog[^] Without a strive for perfection I would be terribly bored.
-
Stuart Dootson wrote:
Your head's really going to flip when you get to binary functions:
Sounds like fun! You seem to know quite a bit about functional programming, so let me ask you a question. From a business app developer's perspective, what are the benefits of using a functional language like Haskell in a real world app dev scenario? I know that there is a lot of fervor around multi-core/multi-processor computing, but what else is there? I'm just looking for more fuel to add onto my F# fire. Thanks. :)
:josh: My WPF Blog[^] Without a strive for perfection I would be terribly bored.
Josh Smith wrote:
From a business app developer's perspective, what are the benefits of using a functional language
Probably not a lot at present :-) - the frameworks and infrastructure are still aimed at imperative languages. I think it's more realising what's good about the functional approach, and applying that to programmiing with your favourite language. There are two big things to take from functional programming, IMO - referential transparancy (a.k.a no updateable state) and functions as first class objects. Once you catch onto referential transparency, you realise that it's often a lot easier to create a new object rather than try to modify an existing one, which leads you to define objects as immutable (i.e. after they're constructed, you can't modify them). Functions as first class objects...well, you already have that in C# with delegates, really - lambdas in C# 3.0 just make it even easier to do anonymous functions. It's the whole idea of providing customisation points by allowing a function to be passed into some generic code, rather than implementing as a class with virtual functions. The C++ STL does this nicely with some of its algorithms. e.g.
template<class RandomAccessIterator, class Pr> void sort(RandomAccessIterator _First, RandomAccessIterator _Last, BinaryPredicate _Comp);You're passing in the sort criteria as a function. This is what enables 'iteration' functions like
map,fold,filteretc in functional languages - you internalise looping within those functions by passing the loop body in as a (usually anonymous) function. Of course, there's lots of other good stuff in languages like F# and Haskell - partial function application (that's theplus 3thing in my original reply), type inferencing, algebraic data types, pattern matching, polymorphism with type classes to ensure type correctness (that's Haskell only, and is incredibly powerful). Anyway - I find direct use of functional languages best for prototyping some of the more theoretical things I do - parsing, tree and term rewriting...although I have written a simple, multi-threaded web server in Haskell (just for larks!) in about 150 lines of (commented) code. However, functional programming has made big changes in how I write my (C++) code, making it simpler, s -
Josh Smith wrote:
From a business app developer's perspective, what are the benefits of using a functional language
Probably not a lot at present :-) - the frameworks and infrastructure are still aimed at imperative languages. I think it's more realising what's good about the functional approach, and applying that to programmiing with your favourite language. There are two big things to take from functional programming, IMO - referential transparancy (a.k.a no updateable state) and functions as first class objects. Once you catch onto referential transparency, you realise that it's often a lot easier to create a new object rather than try to modify an existing one, which leads you to define objects as immutable (i.e. after they're constructed, you can't modify them). Functions as first class objects...well, you already have that in C# with delegates, really - lambdas in C# 3.0 just make it even easier to do anonymous functions. It's the whole idea of providing customisation points by allowing a function to be passed into some generic code, rather than implementing as a class with virtual functions. The C++ STL does this nicely with some of its algorithms. e.g.
template<class RandomAccessIterator, class Pr> void sort(RandomAccessIterator _First, RandomAccessIterator _Last, BinaryPredicate _Comp);You're passing in the sort criteria as a function. This is what enables 'iteration' functions like
map,fold,filteretc in functional languages - you internalise looping within those functions by passing the loop body in as a (usually anonymous) function. Of course, there's lots of other good stuff in languages like F# and Haskell - partial function application (that's theplus 3thing in my original reply), type inferencing, algebraic data types, pattern matching, polymorphism with type classes to ensure type correctness (that's Haskell only, and is incredibly powerful). Anyway - I find direct use of functional languages best for prototyping some of the more theoretical things I do - parsing, tree and term rewriting...although I have written a simple, multi-threaded web server in Haskell (just for larks!) in about 150 lines of (commented) code. However, functional programming has made big changes in how I write my (C++) code, making it simpler, sStuart, you rock! Thanks a lot for sharing your thoughts. :cool:
:josh: My WPF Blog[^] Without a strive for perfection I would be terribly bored.
-
Stuart Dootson wrote:
Your head's really going to flip when you get to binary functions:
Sounds like fun! You seem to know quite a bit about functional programming, so let me ask you a question. From a business app developer's perspective, what are the benefits of using a functional language like Haskell in a real world app dev scenario? I know that there is a lot of fervor around multi-core/multi-processor computing, but what else is there? I'm just looking for more fuel to add onto my F# fire. Thanks. :)
:josh: My WPF Blog[^] Without a strive for perfection I would be terribly bored.
Josh Smith wrote:
From a business app developer's perspective, what are the benefits of using a functional language like Haskell in a real world app dev scenario?
a decade from now when your app is running on a 1024 core machine instead of an 8 core box it'll gracefully scale to use all the extra horsepower without requiring a rewrite. :cool:
-- If you view money as inherently evil, I view it as my duty to assist in making you more virtuous.
-
Josh Smith wrote:
From a business app developer's perspective, what are the benefits of using a functional language like Haskell in a real world app dev scenario?
a decade from now when your app is running on a 1024 core machine instead of an 8 core box it'll gracefully scale to use all the extra horsepower without requiring a rewrite. :cool:
-- If you view money as inherently evil, I view it as my duty to assist in making you more virtuous.
dan neely wrote:
a decade from now when your app is running on a 1024 core machine instead of an 8 core box it'll gracefully scale to use all the extra horsepower without requiring a rewrite.
That's awesome.
:josh: My WPF Blog[^] Without a strive for perfection I would be terribly bored.
-
dan neely wrote:
a decade from now when your app is running on a 1024 core machine instead of an 8 core box it'll gracefully scale to use all the extra horsepower without requiring a rewrite.
That's awesome.
:josh: My WPF Blog[^] Without a strive for perfection I would be terribly bored.
But unfortunately, not quite right. Unless you actually design your app to use more than one concurrent thread (and I don't necessarily mean kernel threads), it'll only ever be single-threaded and will only be able to use one core. You need to make liberal use of whatever concurrency paradigm is provided, in such a way that the runtime can perform balancing of threads across cores for you. So, in Erlang - use lots of processes! In .Net languages, use the threadpool liberally, I guess (I am certainly not a .Net expert - my usual language is C++). In Haskell, you'd want to use a reasonable number of threads via forkIO. Where FP does help you is that as data is (in general) immutable, shared data isn't updateable, so doesn't need to be locked - and also means you need to find some other way of communicating updates. Erlang probably has the nicest paradigm, with very lightweight processes (tens of thousands of processes are not a problem[^]), using message passing to communicate (but then, it was designed from ground up to be suitable for highly concurrent systems). Haskell has inter-thread channels, MVars and STM (software transactional memory).
-
But unfortunately, not quite right. Unless you actually design your app to use more than one concurrent thread (and I don't necessarily mean kernel threads), it'll only ever be single-threaded and will only be able to use one core. You need to make liberal use of whatever concurrency paradigm is provided, in such a way that the runtime can perform balancing of threads across cores for you. So, in Erlang - use lots of processes! In .Net languages, use the threadpool liberally, I guess (I am certainly not a .Net expert - my usual language is C++). In Haskell, you'd want to use a reasonable number of threads via forkIO. Where FP does help you is that as data is (in general) immutable, shared data isn't updateable, so doesn't need to be locked - and also means you need to find some other way of communicating updates. Erlang probably has the nicest paradigm, with very lightweight processes (tens of thousands of processes are not a problem[^]), using message passing to communicate (but then, it was designed from ground up to be suitable for highly concurrent systems). Haskell has inter-thread channels, MVars and STM (software transactional memory).
Stuart Dootson wrote:
Erlang probably has the nicest paradigm, with very lightweight processes (tens of thousands of processes are not a problem[^]),
:omg:
:josh: My WPF Blog[^] Without a strive for perfection I would be terribly bored.