Learning F#
-
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.