Your qsort function takes a list and returns a new list. So for the outside, it's pure, no matter how it is internally implemented. Loops and local side-effects are not bad. You can use them if you think it will help.

Here you can find the sort function from the OCaml standard library. It is optimized without any side-effect (but it's a merge sort): [link:docs.camlcity.org]

In most cases, you can write efficient code without mutables. If you need to optimize a critical loop, you might need to use mutables in some places.

Laurent.

By on 3/23/2011 11:40 AM ()

Thanks for the answers

So, am I right, I can use any mutable variables whenever I want? Of course it's better not to use them, I mean how often I could switch to imperative programming?

And if it's really difficult to write some algorithms in F#, what is the benefit? I mean F# imperative doesn't really much differ from C#, why should I use F# there?

If I will chose to use C# there, it would be difficult to combine C# and F#, that's why it would be easier to use just C#. If I will chose to use F# as imperative and functional - it's just a little harder to support F# imperative. For example it is harder to debug it. And a little harder to read.

In some sort, this is a question of code-styling. Is there any code design guides for using F#?

I choose to learn F#, because I'm just bored of C#. I want to try some other paradigm, take a deep breath of a fresh air. Though I do not want to use F# only for fun. I want to know in what situations it's better to use it, and in what it's better to use my old school.

Honestly, F# as a Multi-paradigm language is scaring me a little. Though I hadn't such feeling when I learnt C# despite C# is a multi-paradigm lang to

By on 3/25/2011 4:29 AM ()

You can use mutable variables each time you need it. Some algorithms are easier or more efficient when written in an imperative way. Some other are much more suited to function programming. And some other can be written in both ways.

F# favors functional programming: values are not mutable by default, some imperative constructs from C# are missing (no return, break, continue, do while), F# library helps you to write functional code (there are very few side effects in it). My suggestion is: Try functional, try to avoid side effects (especially when it's modifying global state). If at some point you feel you need mutable values, you'll know it's there. But most of the time, you won't need them. In F#, functional solutions tend to be cleaner and more succinct.

F# has many features that are not present in C#. Try learning and using them. For example: pattern matching, list comprehensions, units of measure, async. etc. To avoid loops, learn to use the library functions: List.map, List.fold and so on (the Seq module is also very handy).

Laurent

By on 3/29/2011 4:22 PM ()

Hi

here: [link:www.haskell.org] you can find a comperison for Haskell (for those simple examples Haskell is more or less the same as F# - think of it as C# vs. VB.net - most simple programs in Haskell can easily be translated into F#)

If you want "assembler-level" optimization then NO you can't write "efficient" code in F# without mutables (but for this matter you can't in C# or any other .net languague)

If not then look at the quicksort in C/C++ - you have to copy elements around and this is in the big-Oh notation not worse then construction a (or two) new list with "filter"

So IMHO you can write very "effective" algorithms in F# but maybe you can make those faster in C or assembler. But not "it matters in big-O" - faster if you do your FP right.

As a conclusion: just use your imperative technique for qsort or even better use what the .net-framework gives you ;)

No one statet that FP is *faster* then the imperative way (and how could it - the CPU will do it's work VERY imperative in the end) and this might be your missunderstanding

By on 3/23/2011 10:52 AM ()
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