Still a novice at it, maybe I'd call it needed because of things that don't meld well with existing languages for parallel programming is a big part, there's support for that with a limited instruction set to prevent pp errors. Other languages can be used
for pp but there's a lot of pitfalls, very tricky, but that makes f# not very useful for regular programming, it's more a needed new project for most solutions that use clouds and networks for data or workflow logic-applications.
I see the use of the term "hybrid applications" now and that's where I think it's going, nothing is pure cloud or pure network anymore so they have to be mixed in most environments, at least for large enterprises and even some small businesses.
Anyway, can recommend getting vs2010 RC if you can, there's a f# tutorial project worth checking out, you can add f# to vs2008 now as well.
Click "Mark as Answer" on the post that helped you.
This earns you a point and marks your thread as Resolved so we will all know you have been helped.
FAQ on the correct forum http://forums.asp.net/p/1337412/2699239.aspx#2699239
You can write OO programs in F#, also parallel computations and other styles. That means
yes and no. It can do some things with much less work than some other languages, but it can also do what the mainstream languages do (albeit a bit differently and with less code, in many cases).
I've been using Petricek & Skeet's "Real-world Functional Programming: With examples in F# & C#" and find it very useful for understanding functional programming, pointing out lamba & other ways to use C# since V3 for things F# is designed to do, so it's more
compact syntax to do the same thing.
Can highly recommend it for C# coders, I learned & used C# when .net first came out, used mainly vb.net for the last company.
I've been using Petricek & Skeet's "Real-world Functional Programming: With examples in F# & C#"
Please give us the ISBN reference of the book.
Click "Mark as Answer" on the post that helped you.
This earns you a point and marks your thread as Resolved so we will all know you have been helped.
FAQ on the correct forum http://forums.asp.net/p/1337412/2699239.aspx#2699239
F# by having a simple syntax that references functions, it's based on OCaml somewhat, you can solve complex problems well, hard to describe ...
Many examples in the book are ways to deal with "all of the above" in F# with comparable code in C#.
Currently I'm coding up an app to compute the drag on a real-world cyclist in great detail, with surface area for the rider, their arms & legs, the frame & wheels, all treated separately, an allowance for gusty conditions, changes in angle-of-attack, functions
to inter-relate the drag coefficients between the rider position <- handlebars <- arm position <- legs related to the frame <- position <- legs related to the wheels <- legs and where you can enter local conditions like altitude and temperature.
Then the program computes the total drag of each part to satisfy world hour records for wattage & speed, then as the program ages all the component Cd's are found.
This doesn't exist ... the bicycle companies are wind-tunnel oriented, publish no work so are not scientists, so, this has never been done before in the public arena and took about a week to approach and now finally have running, adding in the client page
to enter data & charting this week. Part of what made it easy to solve are using data structures based on tuples ... too handy, knowing C# & VB.NET, no way it would code up as easy.
F# is unique as a functional language mainly in that it's a .net language so can interop & use any .net library. My take was MS is playing hardball now for Azure to grab cloud market vs IBM & others so put in the effort to make it relatively easy to refactor
& add parallel-asynch to existing critical app's, and to me vs2010 was a great IDE jump in ease-of-use for this.
I haven't touched fluid dynamics etc. for years, but I have a sense of how hard jobs like that can be if the language gets in the way.
I imagine the units of measure feature has been useful in this work.
If you ever publish details of the project, I'd appreciate a mention on this thread, so that I can read it.
On the other question from Johan. I imagine that F# can work well in those categories, in the back end DLL's. For UI creation I imagine many developers may go with the UI design tools of the more established languages like C# and VB.NET.
However in the book Expert F# (I'm using the first edition ISBN-13: 978-1-59059-850-4; Don Syme, Adam Granicz, Antonio Cisternino) there is a chapter entitled "Working with Window Forms and Controls" which illustrates a way to
write form UI's. A refreshing approach! So you are not shut out from writing UI's!
I think the answer depends more on what you actually want to or are inclined to do, and how. If your thinking is purely OO then VB.NET, C# and F# will, arguably, serve you about equally. If you have been bitten by the functional bug and are sometimes thinking
in a different way you could find yourself hooked on F#.
If your choice of language is constrained by the availability of programmers your choice might be different. There seem
not to be a lot of F# programmers around yet, and the financial community is
actively trying to vacuum them up! Longer term, I sincerely hope, that the elegance and power of F# persuades many to become accomplished F# programmers. (That might take a while in a world full of misleading Web 2 noise, inaccuracy and
distraction!)
JohanNL
Participant
1644 Points
1227 Posts
F# compared to OO and Procedural
Feb 23, 2010 06:50 AM|LINK
Is F# (Functional Programming) the next level, after procedural and object oriented programming?
MCPD, MCSE, MCTS BizTalk 2006
==============================
Please mark the most helpful reply/replies as "Answer".
timallard
Member
636 Points
160 Posts
Re: F# compared to OO and Procedural
Apr 06, 2010 09:31 PM|LINK
Still a novice at it, maybe I'd call it needed because of things that don't meld well with existing languages for parallel programming is a big part, there's support for that with a limited instruction set to prevent pp errors. Other languages can be used for pp but there's a lot of pitfalls, very tricky, but that makes f# not very useful for regular programming, it's more a needed new project for most solutions that use clouds and networks for data or workflow logic-applications.
I see the use of the term "hybrid applications" now and that's where I think it's going, nothing is pure cloud or pure network anymore so they have to be mixed in most environments, at least for large enterprises and even some small businesses.
Anyway, can recommend getting vs2010 RC if you can, there's a f# tutorial project worth checking out, you can add f# to vs2008 now as well.
hth,
analyst/architect, SDE
TATWORTH
All-Star
72415 Points
14017 Posts
MVP
Re: F# compared to OO and Procedural
May 02, 2010 04:42 PM|LINK
You could also ask at the following F# forum:
This earns you a point and marks your thread as Resolved so we will all know you have been helped.
FAQ on the correct forum http://forums.asp.net/p/1337412/2699239.aspx#2699239
MikeGale
Member
235 Points
81 Posts
Re: F# compared to OO and Procedural
Sep 07, 2010 01:10 AM|LINK
You can write OO programs in F#, also parallel computations and other styles. That means yes and no. It can do some things with much less work than some other languages, but it can also do what the mainstream languages do (albeit a bit differently and with less code, in many cases).
timallard
Member
636 Points
160 Posts
Re: F# compared to OO and Procedural
Sep 07, 2010 01:35 PM|LINK
I've been using Petricek & Skeet's "Real-world Functional Programming: With examples in F# & C#" and find it very useful for understanding functional programming, pointing out lamba & other ways to use C# since V3 for things F# is designed to do, so it's more compact syntax to do the same thing.
Can highly recommend it for C# coders, I learned & used C# when .net first came out, used mainly vb.net for the last company.
analyst/architect, SDE
TATWORTH
All-Star
72415 Points
14017 Posts
MVP
Re: F# compared to OO and Procedural
Sep 07, 2010 09:08 PM|LINK
Please give us the ISBN reference of the book.
This earns you a point and marks your thread as Resolved so we will all know you have been helped.
FAQ on the correct forum http://forums.asp.net/p/1337412/2699239.aspx#2699239
timallard
Member
636 Points
160 Posts
Re: F# compared to OO and Procedural
Sep 08, 2010 12:21 AM|LINK
Apology,
Paetricek & Skeet, "Real-World Funtional Programming: With examples in F# and C#"; Manning, Greenwich, CT, 2010
ISBN 978-1-933988-92-4
cheers,
tom
programming F# C# functional
analyst/architect, SDE
JohanNL
Participant
1644 Points
1227 Posts
Re: F# compared to OO and Procedural
Sep 08, 2010 07:30 AM|LINK
In what kind of applications will F# be used best?
Web
Games
Desktop
Services
Mobile
Other...
MCPD, MCSE, MCTS BizTalk 2006
==============================
Please mark the most helpful reply/replies as "Answer".
timallard
Member
636 Points
160 Posts
Re: F# compared to OO and Procedural
Sep 08, 2010 05:03 PM|LINK
F# by having a simple syntax that references functions, it's based on OCaml somewhat, you can solve complex problems well, hard to describe ...
Many examples in the book are ways to deal with "all of the above" in F# with comparable code in C#.
Currently I'm coding up an app to compute the drag on a real-world cyclist in great detail, with surface area for the rider, their arms & legs, the frame & wheels, all treated separately, an allowance for gusty conditions, changes in angle-of-attack, functions to inter-relate the drag coefficients between the rider position <- handlebars <- arm position <- legs related to the frame <- position <- legs related to the wheels <- legs and where you can enter local conditions like altitude and temperature.
Then the program computes the total drag of each part to satisfy world hour records for wattage & speed, then as the program ages all the component Cd's are found.
This doesn't exist ... the bicycle companies are wind-tunnel oriented, publish no work so are not scientists, so, this has never been done before in the public arena and took about a week to approach and now finally have running, adding in the client page to enter data & charting this week. Part of what made it easy to solve are using data structures based on tuples ... too handy, knowing C# & VB.NET, no way it would code up as easy.
F# is unique as a functional language mainly in that it's a .net language so can interop & use any .net library. My take was MS is playing hardball now for Azure to grab cloud market vs IBM & others so put in the effort to make it relatively easy to refactor & add parallel-asynch to existing critical app's, and to me vs2010 was a great IDE jump in ease-of-use for this.
Hope this is useful,
tom
analyst/architect, SDE
MikeGale
Member
235 Points
81 Posts
Re: F# compared to OO and Procedural
Sep 08, 2010 09:17 PM|LINK
Tom.
That's a great example.
I haven't touched fluid dynamics etc. for years, but I have a sense of how hard jobs like that can be if the language gets in the way.
I imagine the units of measure feature has been useful in this work.
If you ever publish details of the project, I'd appreciate a mention on this thread, so that I can read it.
On the other question from Johan. I imagine that F# can work well in those categories, in the back end DLL's. For UI creation I imagine many developers may go with the UI design tools of the more established languages like C# and VB.NET.
However in the book Expert F# (I'm using the first edition ISBN-13: 978-1-59059-850-4; Don Syme, Adam Granicz, Antonio Cisternino) there is a chapter entitled "Working with Window Forms and Controls" which illustrates a way to write form UI's. A refreshing approach! So you are not shut out from writing UI's!
I think the answer depends more on what you actually want to or are inclined to do, and how. If your thinking is purely OO then VB.NET, C# and F# will, arguably, serve you about equally. If you have been bitten by the functional bug and are sometimes thinking in a different way you could find yourself hooked on F#.
If your choice of language is constrained by the availability of programmers your choice might be different. There seem not to be a lot of F# programmers around yet, and the financial community is actively trying to vacuum them up! Longer term, I sincerely hope, that the elegance and power of F# persuades many to become accomplished F# programmers. (That might take a while in a world full of misleading Web 2 noise, inaccuracy and distraction!)