Coffeehouse Thread

39 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

F# is now the real deal: We've made it an official .NET language

Back to Forum: Coffeehouse
  • User profile image
    Dr Herbie

    phreaks wrote:
    

    If we have a problem that can be solved mathematically, we can write code that is very similar to the actual formula to solve the problem.


    I like that explanation.  Very succinct. Thanks.

    Herbie

  • User profile image
    ScanIAm

    Dr Herbie wrote:
    
    phreaks wrote:
    

    If we have a problem that can be solved mathematically, we can write code that is very similar to the actual formula to solve the problem.


    I like that explanation.  Very succinct. Thanks.

    Herbie


    That sounds interesting, now. 

    Can it deal with differentials and integrals?  Or do you need to approximate?

    I'm going to have to check it out some more.  I, too, failed Calc I and Calc II once (each), and gave up when Calc III came around.  That stuff was waaaaaaay to theoretical for me Smiley

  • User profile image
    wkempf

    Dr Herbie wrote:
    
    phreaks wrote:
    

    If we have a problem that can be solved mathematically, we can write code that is very similar to the actual formula to solve the problem.


    I like that explanation.  Very succinct. Thanks.

    Herbie


    Not fully complete, however.  Functional styles have a wider applicability.  List processing, which includes text parsing, is often easier and more succinct to code in a functional manner.  LINQ is a great example of the functional style that will be easier to grasp as an example of where the domain shines for someone only used to C-style languages.

    I don't know ML at all, so right now the F# code I've looked at looks like Swahili.  I have used several other functional languages, though, such as Lisp.  It's exciting that functional languages are coming to .NET, but I'm still partial to C-style syntax.  So I'll look into F# for academic interests, but I'll probably stick to C# and hope it continues to become more functional over time.

  • User profile image
    rhm

    Dr Herbie wrote:
    OK, now I don't have a CS background and I fell into the C-family of languages (with a short stroll through Pascal and Basic at the start), so I'm a mainly OOP developer, and I come up a bit short on the rest of this stuff.

    Can anyone suggest examples of functionality that would be better written in F# than in C#?

    When would I want to use it?

    Herbie


    I wouldn't say there's anything that's *better* to write in F# (or any other functional language), personally I hate the way people pigeonhole technologies like that. I would say you would program in F# if you like writing in a functional style.

    It's very difficult to explain the point of functional programming to people that have only ever written in imperitive languages I'm affraid. I did two years of ML at university and it took me a long time to get it and even then I haven't used ML (or any other functional language) since I graduated.

    If I had to summarise the point of it - functional programming from a programmers perspective allows for more succinct expression of algorithms, i.e. complex algorithms written in functional languages can be easier to understand and work on for people that understand those languages.

    It's also worth pointing out that since functional programming is strictly a subset of procedural programming, you can write functional code in C# if you want, although it will be much less efficient than if you had used the same coding pattern in ML. For example, your basic method of itteration in functional programming is recursion and we all know you can write recursive code in procedural languages like basic or C#, but when you recurse in those languages you use up stack frames each time round the loop so you don't want to do it too much, the call and return operations have a certain amount of overhead. The compilers for functional languages do a lot to re-write the code so that recursive functions become simple loops. I know it seems like there's no point in that, but a lot of algorithms make more sense when expressed recursively (Quicksort being the golden example) so you want a language that allows you do use recursion free of concern for efficiency or running out of stack space.

    Functional languages also offer interesting type systems and while a lot of the more useful stuff has been replicated in procedural languages through object orientation and generic types, there are still some beautiful things you can do in languages like ML. I haven't looked at F# so I don't know if this has an interesting type system like ML or if it's just like the C# type model with a functional syntax.

  • User profile image
    ScanIAm

    wkempf wrote:
    
    Dr Herbie wrote:
    
    phreaks wrote:
    

    If we have a problem that can be solved mathematically, we can write code that is very similar to the actual formula to solve the problem.


    I like that explanation.  Very succinct. Thanks.

    Herbie


    Not fully complete, however.  Functional styles have a wider applicability.  List processing, which includes text parsing, is often easier and more succinct to code in a functional manner.  LINQ is a great example of the functional style that will be easier to grasp as an example of where the domain shines for someone only used to C-style languages.

    I don't know ML at all, so right now the F# code I've looked at looks like Swahili.  I have used several other functional languages, though, such as Lisp.  It's exciting that functional languages are coming to .NET, but I'm still partial to C-style syntax.  So I'll look into F# for academic interests, but I'll probably stick to C# and hope it continues to become more functional over time.


    See, now I know why it made me feel a bit uncomfortable.  Any language that even comes close to Lisp makes me shudder Sad

  • User profile image
    phreaks

    rhm wrote:
    
    Dr Herbie wrote:
    OK, now I don't have a CS background and I fell into the C-family of languages (with a short stroll through Pascal and Basic at the start), so I'm a mainly OOP developer, and I come up a bit short on the rest of this stuff.

    Can anyone suggest examples of functionality that would be better written in F# than in C#?

    When would I want to use it?

    Herbie


    I wouldn't say there's anything that's *better* to write in F# (or any other functional language), personally I hate the way people pigeonhole technologies like that. I would say you would program in F# if you like writing in a functional style.



    Faster and more efficient = better, no?

    we have ML programs that take 12+ hours to run (analyzing hundred+ gigs of data), imagine if that was running through C#, or VB.NET or Java.

    Also, it is much easier for the math geeks to understand.
    if a model is visibly off, they can look through the code and usually find where the calculation is running amok.


    rhm wrote:
    

    It's very difficult to explain the point of functional programming to people that have only ever written in imperitive languages I'm affraid. I did two years of ML at university and it took me a long time to get it and even then I haven't used ML (or any other functional language) since I graduated.

    If I had to summarise the point of it - functional programming from a programmers perspective allows for more succinct expression of algorithms, i.e. complex algorithms written in functional languages can be easier to understand and work on for people that understand those languages.

    It's also worth pointing out that since functional programming is strictly a subset of procedural programming, you can write functional code in C# if you want, although it will be much less efficient than if you had used the same coding pattern in ML. For example, your basic method of itteration in functional programming is recursion and we all know you can write recursive code in procedural languages like basic or C#, but when you recurse in those languages you use up stack frames each time round the loop so you don't want to do it too much, the call and return operations have a certain amount of overhead. The compilers for functional languages do a lot to re-write the code so that recursive functions become simple loops. I know it seems like there's no point in that, but a lot of algorithms make more sense when expressed recursively (Quicksort being the golden example) so you want a language that allows you do use recursion free of concern for efficiency or running out of stack space.

    Functional languages also offer interesting type systems and while a lot of the more useful stuff has been replicated in procedural languages through object orientation and generic types, there are still some beautiful things you can do in languages like ML. I haven't looked at F# so I don't know if this has an interesting type system like ML or if it's just like the C# type model with a functional syntax.


    I agree with the rest.

  • User profile image
    littleguru

    I liked Haskell because it allowed me to specify complex stuff in a few lines of code. Really cool!

    It takes some time to get it but when you got it it is really nice and expressing complex problems in a few lines of code is just plain cool. Imagine you do a Quicksort in like 5 lines of code instead of 50-100 or even more in C/C++. No worrying about pointer and stuff - you use lists and operate on the elements.

    Also it is then way easier to extend the code in pointer later in time. Smiley

    But probably if you only code data layers and that stuff you won't need it that much... but I might be wrong! Who knows...

  • User profile image
    Andrew Davey

    This is great news.

    However, can someone at Microsoft help to give Boo and Nemerle the same love F# got?

    Whilst these are not MS developed languages, they are fantastic. Boo especially has an excellent developer community. The language has so many powerful features and is super easy to learn - better then VB.NET I'd say!

    We need to get these into VS.NET!

  • User profile image
    Royal​Schrubber

    Woohoo, it's time for some celebration!


    Big Smile

  • User profile image
    Richard.Hein

    Dr Herbie wrote:

    Can anyone suggest examples of functionality that would be better written in F# than in C#?

    When would I want to use it?


    Herbie


    In addition to some of the other things people mentioned already, F# is a functional language without side effects, which means the variables are immutable, which means programs written with it can be parallelized without worrying about the kind of issues that overwriting a variable from a parallel thread would cause.

  • User profile image
    W3bbo

    ScanIAm wrote:
    
    Dr Herbie wrote:
    
    phreaks wrote:
    

    If we have a problem that can be solved mathematically, we can write code that is very similar to the actual formula to solve the problem.


    I like that explanation.  Very succinct. Thanks.

    Herbie


    That sounds interesting, now. 

    Can it deal with differentials and integrals?  Or do you need to approximate?


    Provided the functional language has access to a CAS, yes. That's what Mathematica (both the language and the CAS) is.

    Anyway, IRT OP: So F# is now an "official" language. With J# being dropped lately, does this mean F# will be a part of the IDE?

  • User profile image
    nightski

    W3bbo wrote:
    

    Provided the functional language has access to a CAS, yes. That's what Mathematica (both the language and the CAS) is.

    Anyway, IRT OP: So F# is now an "official" language. With J# being dropped lately, does this mean F# will be a part of the IDE?


    It doesn't need access to a CAS to do integrals or differentiation.  I mean an integral is just a sum...  In fact, it is very easy to represent an integral in functional languages.  It is done in one of the first video lectures listed below.

    Dismissing functional languages as only for math intensive operations is missing the point completely. If you use LINQ you are taking advantage of constructs from functional languages.  They have many applications.

    Anyways, a good intro to functional style programming can be found here -

    http://swiss.ai.mit.edu/classes/6.001/abelson-sussman-lectures/

    These are old video lectures from MIT by one of the inventors of the functional language Scheme.

  • User profile image
    magicalclick

    I think I have tried it in my college years. Functional Programming is very specific to solve certain type of problem. It is not designed for most applications, like PC games, movie player, photo editor, and other mainstream applications.

    OOP languages also can do Functional Programming fairly easily. It is very easy to reference a math library and do those more advanced calculations. 3D games usually have some calculus math library included.

    And I believe a lot of optimizations are already used in C# anyway. The data dependency is a very basic complier optimization on OOP languages.

    Anyway, Functional Progamming Language is way to tricky for me. It is not as straight forward as OOP.

    Leaving WM on 5/2018 if no apps, no dedicated billboards where I drive, no Store name.
    Last modified
  • User profile image
    nightski

    magicalclick wrote:
    I think I have tried it in my college years. Functional Programming is very specific to solve certain type of problem. It is not designed for most applications, like PC games, movie player, photo editor, and other mainstream applications.

    OOP languages also can do Functional Programming fairly easily. It is very easy to reference a math library and do those more advanced calculations. 3D games usually have some calculus math library included.

    And I believe a lot of optimizations are already used in C# anyway. The data dependency is a very basic complier optimization on OOP languages.

    Anyway, Functional Progamming Language is way to tricky for me. It is not as straight forward as OOP.


    Whether you use it day to day or not isn't really the point.  When you truly take the time to learn the functional approach to solving problems, it only helps you.  It is more about the process, than the syntax.  Functional languages aren't better than imperative languages, and vice versa.  It is just that the more tools you have and approaches you can take to solve complex problems the easier life becomes.

    I am extremely excited about this anouncement, it just makes .NET that much more compelling of a platform to develop on.  Its all about options Smiley

  • User profile image
    JChung2006

    Andrew Davey wrote:
    However, can someone at Microsoft help to give Boo and Nemerle the same love F# got?

    What do Boo and Nemerle do that F# and IronPython can't?

  • User profile image
    Andrew Davey

    JChung2006 wrote:
    
    Andrew Davey wrote:
    However, can someone at Microsoft help to give Boo and Nemerle the same love F# got?

    What do Boo and Nemerle do that F# and IronPython can't?


    Nemerle is functional, but doesn't force that "flavor" unless you want it. This means you can write imperative code that looks a lot like C#. However, as you learn more about functional programming you can improve your coding style.

    Boo is awesome. It has the right mix of static typing with optional dynamic typing. The syntax is super-lightweight, making it ideal for teaching programming to students. In addition, making domain specific languages is easy.

    Both have a syntactic macro systems, enabling even higher level meta-programming (think DSLs again). (I know F# has macros of some form too.)

    Both have super smart programmers innovating on their development and rich communities.
    I'm not saying don't use F# or IronPython. I'm saying please take a good look at Boo and Nemerle as well.

  • User profile image
    esoteric

    D/2 is also getting some powerful syntax and semantics. It has a very powerful template system as well as compile-time function evaluation (CTFE). It is also able to compose strings at compile-time which can be mixed-in and used as part of the "end" program. Some powerful stuff has been made using that, for example mixing in compile-time generated inline asm for optimized vector expressions.

    Reference

    Don Clugston wrote:

    I have been trying to come up with a convincing use case for the new
    mixins (and for metaprogramming in general). My best effort to date can
    be found at:
    http://www.dsource.org/projects/mathextra/browser/trunk/mathextra/Blade.d

    It generates near-optimal x87 asm code for BLAS1-style basic vector
    operations. 32, 64 and 80 bit vectors are all supported.

    Compile with -version=BladeDebug to see the asm code which is generated.

    Typical usage:

    void main()
    {
         auto p = Vec([1.0L, 2, 18]);    // a vector of 80-bit reals.
         auto q = Vec([3.5L, 1.1, 3.8]);  // ditto
         auto r = Vec([17.0f, 28.25, 1]); // a vector of 32-bit floats
         auto z = Vec([17.0i, 28.1i, 1i]); // a vector of 64-bit idoubles
         real d = dot(r, p+r+r);
         ireal e = dot(r, z);
         q -= ((r+p)*18.0L*314.1L - (p-r))* 35;
         d = dot(r, p+r+r);
    }

    Notice that mixed-length operations (real[] + float[] - double[]) are
    supported.

    Like the C++ Blitz++ library, expression templates are used to convert
    vector expressions into efficient element-wise operations. Unlike that
    library, however, there is no reliance on the compiler's optimiser.
    Instead, the expression template is manipulated as text, converted into
    postfix, and then passed to a simple CTFE compile-time assembler, which
    creates highly efficient asm code which is used as a mixin.
    To understand the later parts of the code, you need some knowledge of
    x87 assembler. In fact, you probably need to have read Agner Fog's
    superb Pentium optimisation manual (www.agner.org).

    Some observations:
    * I was amazed at how simple the expression template code is (it is
    somewhat cluttered by the code to check for real/imaginary type mismatch
    errors).
    * I've often read that the x87 floating-point stack is notoriously
    difficult for compilers to write code for, but it works quite well in
    this case.
    * The major workarounds are:
    - inability to use a tuple element directly from asm code (bug #1028);
    - inability to define operators for built-in arrays (hence the use of
    'Vec' wrappers).
    - inability to index through a tuple in a CTFE function (solved by
    converting types into a string).
    * There have been mutterings about how unhygenic/dangerous the new
    mixins are. In this case, the mixin forms the _entire_ body of the
    function. This is an interesting situation which I think a language
    purist will find more palatable.

    Enjoy.

  • User profile image
    JChung2006

    Andrew Davey wrote:
    Both have a syntactic macro systems, enabling even higher level meta-programming (think DSLs again). (I know F# has macros of some form too.)

    That sounds like Lisp to me!

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.