I suggest you ...

Metro development from F# without the need for C# assemblies

I believe that today it's not possible to create a top-to-bottom F# app that takes advantage of SL/Metro on desktop and Windows Phone. Some degree of support from C# assemblies is still needed. Making it possible to write a 100% F# app of that flavor would be a great improvement. My 2 cents.

332 votes
Vote
Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
seattleite09 shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

We agree that it would be nice to be able to use F# for all parts of an application, but given that there are always bounds on time and resources, features need to be prioritized.

F# will have support for building Metro applications using portable libraries, as described in Don Syme’s BUILD talk (http://channel9.msdn.com/Events/BUILD/BUILD2011/SAC-904T), but the front-end of the application will have to be written in VB/C#. The primary focus of the upcoming release is on information-rich programming through type providers and query expressions, so we chose to invest as much as possible in those areas, while still enabling core Metro application scenarios. This approach is similar to our Silverlight support.

Donna Malayeri
Program Manager, Visual Studio F#

14 comments

Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
Submitting...
  • Jon Harrop commented  ·   ·  Flag as inappropriate

    FWIW, I had the opportunity to advertise microsoft tablets to one of the world's largest insurance companies but the lack of support for F# led them to buy 10000 apple ipads instead.

  • Vipul S. Chawathe commented  ·   ·  Flag as inappropriate

    Considering all the good that F# brings, perhaps MSDN may document 1. how & 2. to which extent F# can contribute to Windows 8 RT (for ARM) application when F# ships in the current build of Visual Studio. Right now, by manually doing decentralized search on internet, as a software architect all I get is a hunch & it's rather unreasonable to stall development due to lack of decisiveness.

  • Ryan Riley commented  ·   ·  Flag as inappropriate

    @Ray, Given the apis we get with other .NET languages, I actually find the WebSharper approach quite refreshing. So it's just my $0.02. :)

  • Ray commented  ·   ·  Flag as inappropriate

    Why bother with WebSharper and Javascript? You can build Metro apps with C# and VB alone. Why not F#??

  • AdminVisual Studio Team (Product Team, Microsoft Visual Studio) commented  ·   ·  Flag as inappropriate

    My previous comment may have caused some confusion, so please let me clarify the response. We agree that it would be nice to be able to use F# for all parts of an application, but given that there are always bounds on time and resources, features need to be prioritized.

    F# will have support for building Metro applications using portable libraries, as described in Don Syme's BUILD talk (http://channel9.msdn.com/Events/BUILD/BUILD2011/SAC-904T), but the front-end of the application will have to be written in VB/C#. The primary focus of the upcoming release is on information-rich programming through type providers and query expressions, so we chose to invest as much as possible in those areas, while still enabling core Metro application scenarios. This approach is similar to our Silverlight support.

    Donna Malayeri
    Program Manager, Visual Studio F#

  • Ryan Riley commented  ·   ·  Flag as inappropriate

    I think it will be totally possible to generate a Metro app with F# in much the same way as WebSharper allows you generate a web or mobile app.

  • Claus Jørgensen commented  ·   ·  Flag as inappropriate

    The question is if the language itself is up to the task. C# and Visual Basic have the large advantages of supporting partial classes, which makes integration with declarative UI frameworks (be it HTML or XAML), a lot easier.

    This is the primary reason why F# isn't useful for Windows Phone or Desktop development today.

    As for web-integration, I think it's more a issue of tooling, than anything else. Since HTTP is stateless, F# would be as suitable as any other language, but without the templates and IDE integration, it won't cut it for real-world development.

    Now if F# want to remain pure, we need a way to utilize meta-programming (read: attributes) to set a compiler flag for integration with generated code. Basically solving the issue the same way Haskell did, with monads.

    Now of course, this won't work without IDE integration to ensure that XAML is actually compiled.

    Ultimately the F# language group, needs to work a lot closer with the Visual Studio team, if they want F# to be utilized for desktop/mobile development. Anyone thinking it's possible today is wearing blinders.

  • Noldorin commented  ·   ·  Flag as inappropriate

    Care to be more specific? What exactly do you feel you can't do purely in F# currently, and how would you change it?

  • Marc Sigrist commented  ·   ·  Flag as inappropriate

    It is in the interest of every F# programmer that the language becomes more mainstream. This is only possible if it is perceived not as an esoteric, cryptic-looking nerd language, but as the more-elegant, more-efficient, "general-purpose multiparadigma language" which it actually is.

    To achieve this goal, it is essential that one can build _complete_ solutions with it, including UI code generators and everything else that one expects from a major Visual Studio language (and yes, it might be necessary to generate lots of impure/imperative event-based UI code - but so what? Some impure code must exist anyway, be it in C# or F#).

    As long as one is _forced_ to use another VS language besides F#, there is always some degree duplication of assemblies: For instance, you end up implementing a) "MyCompany.MyProduct.Common.dll" who is suitable for "any CLI client", and b) "MyCompany.MyProduct.CommonFS.dll" who is optimized for F# clients (using unions, records, measures, FSharpAsync, curried parameters, special operators, etc.).

    The constant need to think about two different kinds of library-consumers makes organizing big, real-world applications, with dozens of libraries, overly complicated. As a consequence, companies will tend to generally prefer C# (which they know much better anyway), and will use F# only narrowly and hesitatingly, e.g., for pure mathematical computations, etc. This cannot be the future of F#.

  • Johann Deneux commented  ·   ·  Flag as inappropriate

    Playing the devil's advocate here: Why would it be a great improvement to be able write an app exclusively in F#? I personally don't mind if my app must have some boiler-plate code in another language, as long as it's possible to delegate the interesting code to F# libraries.
    What supports your suggestion though is that programming tools in the .NET world should never depend on a specific language, they should rely on .NET IL instead.

Feedback and Knowledge Base