5 ms·

Just use F# from Xamarin. It's the real deal. C# is just a stop-gap measure to suck in the enterprise devs.

by nbevans 12y ago

saosebastiao 12y ago
Except that all the docs are in C#, which means if I want to consult them, I have to either know C# or know how F# interops with C# (and therefore understand C#). Trust me, I would love to, but I don't have the time to learn two languages for one project.
- louthy 12y ago
  Out of interest what language are you coming from?
  - saosebastiao 12y ago
    I'm all over the map. My day job requires tons of quick and dirty data analysis or concept prototyping which tends to get thrown away, which moves me towards declarative langugages (lots of SQL and Prolog) as well as pragmatic dynamic languages (Clojure,R,Ruby). But if I'm actually building anything that is meant to last more than a month, I tend much more strongly to an ML philosophy. Currently that is mostly Scala and some Rust, but I've been wanting to play with F#/OCaml for a long while.
    - louthy 12y ago
      You might want to consider F# over C# then, there's very little cognitive barriers to using the .NET framework with F#. For example: open System.IO // F# using System.IO; // C# let thing = new Thing(a,b,c) // F# var thing = new Thing(a,b,c) // C# Console.WriteLine("blah") // F# Console.WriteLine("blah") // C# Essentially C# parameter lists become tuples in F#. So interop is mostly quite straight-forward. It's mostly quite a mechanical process to convert C# sample code into F#. It's harder to go the other way, and take F# code into the C# world, because functions in F# allow for partial application. The type inference system is awesome, so you'll end up with more generic functions and use first class functions more. That stuff is tricky to bring back (though not insurmountable). The OO grammar is a little tricky in F#, but I tend to shy away from that. It's not needed most of the time. Then at least you don't have to deal with all the stuff this library is trying to solve ;)
- MichaelGG 12y ago
  There is essentially no language specific documentation in well made APIs. There is a common type system so there is very little that's different. Mainly if you need a semicolon and how you prefer your parentheses. There are some poorly made APIs, like ASP.NET MVC that exploit C#-specific side effects to compensate for C#'s verbosity. These APIs ignore the common type system and just pass object everywhere, breaking tooling and type safety. But as long as Xamarin didn't come up with terrible designs, you're all set. And, even if they do rely on something strange, F# is such a better language, that the small setback of dealing with interop (which doesn't require learning C#) is totally worth it.
  - icedog 12y ago
    I'm an F# developer, but still decided to not use F# to build an android app. Dealing with the UI libraries like support.v4 was just too painful from a functional perspective. If you don't need any object oriented dependencies, then it's smooth sailing.
    - CmonDev 12y ago
      F# is not meant for implementing the complete app anyway. Just use it for business logic where it makes sense.
      - MichaelGG 12y ago
        I've only heard that in context of A: missing tooling, B: Microsoft, in their quest to make customers feel C# is still the real language and F#'s just some science toy. I've used F# for a Web UI via WebSharper and it was lovely. It's just a poor reflection on the state of UI kits if they don't work with F#.
        CmonDev 12y ago
        "It's just a poor reflection on the state of UI kits if they don't work with F#." - well at least they don't start using lower-case names randomly.
nmgafter 12y ago
I beg to differ. C# is a perfectly usable tool to introduce you to programming until you're ready to move on to F#. Wait, did I just agree with you? -Neal (Roslyn team)
- louthy 12y ago
  How's the pattern matching spec coming along? ;)
CmonDev 12y ago
Exactly the kind of attitude that hinders the F# growth. I mean F# is a pretty useful numeric DSL, but let's not blow things out of proportions. Modern languages have R#-like refactoring tools.

Just use F# from Xamarin. It's the real deal. C# is just a stop-gap measure to suck in the enterprise devs.

by nbevans 12y ago

Just use F# from Xamarin. It's the real deal. C# is just a stop-gap measure to suck in the enterprise devs.

Except that all the docs are in C#, which means if I want to consult them, I have to either know C# or know how F# interops with C# (and therefore understand C#). Trust me, I would love to, but I don't have the time to learn two languages for one project.

louthy 12y ago
Out of interest what language are you coming from?
- saosebastiao 12y ago
  I'm all over the map. My day job requires tons of quick and dirty data analysis or concept prototyping which tends to get thrown away, which moves me towards declarative langugages (lots of SQL and Prolog) as well as pragmatic dynamic languages (Clojure,R,Ruby). But if I'm actually building anything that is meant to last more than a month, I tend much more strongly to an ML philosophy. Currently that is mostly Scala and some Rust, but I've been wanting to play with F#/OCaml for a long while.
  - louthy 12y ago
    You might want to consider F# over C# then, there's very little cognitive barriers to using the .NET framework with F#. For example: open System.IO // F# using System.IO; // C# let thing = new Thing(a,b,c) // F# var thing = new Thing(a,b,c) // C# Console.WriteLine("blah") // F# Console.WriteLine("blah") // C# Essentially C# parameter lists become tuples in F#. So interop is mostly quite straight-forward. It's mostly quite a mechanical process to convert C# sample code into F#. It's harder to go the other way, and take F# code into the C# world, because functions in F# allow for partial application. The type inference system is awesome, so you'll end up with more generic functions and use first class functions more. That stuff is tricky to bring back (though not insurmountable). The OO grammar is a little tricky in F#, but I tend to shy away from that. It's not needed most of the time. Then at least you don't have to deal with all the stuff this library is trying to solve ;)
MichaelGG 12y ago
There is essentially no language specific documentation in well made APIs. There is a common type system so there is very little that's different. Mainly if you need a semicolon and how you prefer your parentheses. There are some poorly made APIs, like ASP.NET MVC that exploit C#-specific side effects to compensate for C#'s verbosity. These APIs ignore the common type system and just pass object everywhere, breaking tooling and type safety. But as long as Xamarin didn't come up with terrible designs, you're all set. And, even if they do rely on something strange, F# is such a better language, that the small setback of dealing with interop (which doesn't require learning C#) is totally worth it.
- icedog 12y ago
  I'm an F# developer, but still decided to not use F# to build an android app. Dealing with the UI libraries like support.v4 was just too painful from a functional perspective. If you don't need any object oriented dependencies, then it's smooth sailing.
  - CmonDev 12y ago
    F# is not meant for implementing the complete app anyway. Just use it for business logic where it makes sense.
    - MichaelGG 12y ago
      I've only heard that in context of A: missing tooling, B: Microsoft, in their quest to make customers feel C# is still the real language and F#'s just some science toy. I've used F# for a Web UI via WebSharper and it was lovely. It's just a poor reflection on the state of UI kits if they don't work with F#.
      - CmonDev 12y ago
        "It's just a poor reflection on the state of UI kits if they don't work with F#." - well at least they don't start using lower-case names randomly.

nmgafter 12y ago

I beg to differ. C# is a perfectly usable tool to introduce you to programming until you're ready to move on to F#. Wait, did I just agree with you? -Neal (Roslyn team)

louthy 12y ago
How's the pattern matching spec coming along? ;)

CmonDev 12y ago

Exactly the kind of attitude that hinders the F# growth. I mean F# is a pretty useful numeric DSL, but let's not blow things out of proportions. Modern languages have R#-like refactoring tools.