How to drive F# Adoption - Part 4

[21c-HK]

I was just about to reply to issue "How to drive F# Adoption - Part 1" (#798) when I noticed that it disappeared. Same for Part 2 (#803) and Part 3 (#809). Why do issues get deleted?

Edit: Part 1 - 3 are back up again.

Anyway, I know I am late to this discussion, but I find it still very relevant. There is a great presentation on mainstreaming a programming language by the creator of Elm. He seems to be right since Elm has become relatively popular in the web community in a really short time despite being completely different from what web developers are used to (e.g. Haskell-like syntax and semantics, new concurrency abstractions, new architecture). He did that with great tutorials, usable samples and a frictionless out-of-box experience.

I think @dsyme and @swlaschin have summarized the most important issues driving F# adoption. When it comes to mainstreaming F#, I feel that the following areas have the highest impact:

Awareness

Microsoft needs to put their money where their mouth is. F# should not be a second-class .NET language that is always put behind C# and VB in terms of priority, support and resources.

Microsoft and the F# community also need to change their sales pitch.

Not:

"F# is best for niche domains like data science, machine learning, or financial trading, etc."

But:

"F# is better than C# - for everything!".

For small problems. For large problems. For any domain. We need to make clear that F# is better than C# in every aspect as a language (which it is!). And this is why F# does not need as much tooling as C#, because it is simply more expressive and you can solve problems directly without fiddling around with XML or poorly designed imperative OO APIs. This is not about not-being-nice, but about being honest.

Out-of-box-experience

As Scrott Wlaschin said, the out-of-box-experience must be frictionless (single all-you-need install, no show-stopping compiler bugs or tooling bugs, good project system, working samples, and up-to-date tutorials). The F#-community has to take full control of the out-of-box-experience to make this a reality.

We need to force Microsoft to take F# seriously by making its out-of-box-experience better than C# (imagine that for a second). Only when Microsoft think they are about to miss the train on an opportunity, do they put their gigantic resources behind a technology (see iOS -> WinRT | cloud -> Azure | Docker -> Windows Containers on Windows Server | virtual reality headsets -> Holo Lens | Xamarin -> .NET Core). Only if Swift overtook C# in terms of usage, would they recognize that they have been sitting on an underappreciated gold mine.

Guidance

Don Syme makes a great point (as always) about the upstack technologies that drive F# adoption all being home-grown F# projects by the open souce F# community as opposed to .NET projects by Microsoft (where .NET is synonymous with C#). That's because these F# projects take advantage of F# as a language instead of being held back by C#'s shortcomings.

I actually think that F# needs to get away from trying to be just another .NET language that fits into the Microsoft technology stack of much-delayed and frequently dropped technologies that are unusable without amazing tooling (which C# has and even needs because it itself is not expressive enough).

Scrott Wlashin is right (again). Officially discourage legacy Microsoft infrastructure tools for .NET like VS project files, NuGet and MSBuild, which have already sucked before F# had to rely on them. F# has much better alternatives now (Paket, FAKE, but still needs a good F#-only project system). VS Code with ionide seems to have overtaken Visual Studio with VFT in terms of usability and functionality in a very short time(!). I have the feeling that Microsoft is actually holding the F# community back by diverting its limited resources and focus to integrating with existing Microsoft products instead of efficiently developing new and better solutions.

Target Audience

The target audience should not be existing C# programmers. C# programmers will only consider F# to be a serious alternative when Microsoft tells them to. Until then, most programmers that might be interested in F# are programmers that are already interested in functional programming, which might also end up with Swift, Haskell, Scala, Clojure, Rust, Elm, etc if disappointed with the out-of-box experience of F#. Again, the F# upstack technologies can only pull-in developers from other communities when F# has the best upstack technologies in a certain domain.

Portability

F# absolutely needs to run out-of-the-box on the future platforms of .NET that enable cross-platform development to stay relevant: .NET Core, Xamarin platforms and .NET Standard Library 1.0. This is why I think that it is a mistake that Microsoft.FSharp.Core.netcore will require .NET Standard Library 1.5 (#1217) as opposed to .NET Standard Library 1.0, which runs on .NET Core, Xamarin and every other .NET supported platform. There should be a single F# Core version that complies with .NET Standard Library 1.0 instead of having multiple versions for different platforms. Having a single F# Core version will make it much easier to maintain and avoid bugs like the inlining bug with F# 3.1 and PCL profile 259.

I also think that WebAssembly is going to change everything. What if WebAssembly becomes the primary execution target for F# in the future?

[forki]

Yes "my way" is always the best way. Unfortunately sometimes others disagree. Fortunately we can discuss such things like civilized people and ask if there are good reasons for some language feature or if it's only "because of historical reasons and backwards compatibility". We will probably find both cases in the F# syntax.

[sin8]

look i'm not looking for anybody to start talking me about currying or monads just to escape the simple fact that f# should be improved in term of readability.

here the f# way

int * int * string => string => int => int 

here is one more readable way to express the same complex lambda

int, (int, string > string = int) = int 

can't you see it? you need to be able to see the internal lambdas.. and the internal parameters/return type of the internal lambas clearly..

[21c-HK]

@DjSinae You are right that the F# syntax has a lot of warts, but your examples are not some of them. It seems that you are new to F#. If you get more familiar with F# or other ML-derived languages then reasons for syntax like int * int ->int will make more sense to you. Like @forki said, syntax warts are mostly because of historical reasons or backwards compatibility. I suggest that you open another issue for improving syntax since this issue (i.e. F# adoption) is too broad for little details like that.

Edit: Removed my explanations to keep the thread focused since they got lost on @DjSinea a.k.a. @sin8 anyway.

[sin8]

please don't tell me this keyword and syntax cannot be use because of this or that.. i'm talking just about the syntax and how it could be clearer.. not how it would affect the rest of the language or if the parser could find it's way to understand it.. of course, once you change one thing all the rest need to be rethinked and adjusted.. you could use [value1,value2] for 2 dimensional tuples for examples

on obj "pattern" is enough or on (obj1,obj2) "pattern". no need for with or match and if you need that match and with they should be reversed..

it should be

with (obj1,ob2) match "pattern" or on (obj1,ob2) match "pattern"

one way could be with no keyword at all beside the "on" after the matched source

(obj1,obj2) on "pattern1" : "action", "pattern2" : "action" 

= could be use instead of <- for destructive assignment even if it has different meaning elsewhere.. (it's about context)

i dont like "let" keyword.. i would prefer just var.. (they would have same meaning anyway)

greater than could be >> or |> instead of >, hence the pipe could be > or the pipe could just be "|"

I agree that f# have low signal to noise ratio but where there is noise.. it's heavy noise..

"member" and "fun" keyword are a good example

[sin8]

let TypeTesting obj = 
    match box obj with
    | :? string as s -> 
        sprintf "Obj is string with value %s" s
    | :? int as i -> 
        sprintf "Obj is int with value %i" i
    | :? Person as p -> 
        sprintf "Obj is Person with name %s %s" p.Name.First p.Name.Last
    | _ -> 
        sprintf "Obj is something else" 

could be

let TypeTesting obj = 
    on box obj
    string as s -> sprintf "Obj is string with value %s" s
    int as i -> sprintf "Obj is int with value %i" i
    Person as p ->  sprintf "Obj is Person with name %s %s" p.Name.First p.Name.Last
    _ ->  sprintf "Obj is something else" 

[sin8]

this 
let red = new SolidBrush(Color.Red) in
let green = new SolidBrush(Color.Green) in
let blue = new SolidBrush(Color.Blue) in
let rec colors =
  seq {
    yield red
    yield green
    yield blue
    yield! colors
  }
`

let pie data (g: Graphics) (r: Rectangle) =
  let vals = 0.0 :: List.map snd data
  let total = List.sum vals
  let angles = List.map (fun v -> v/total*360.0) vals
  let p = new Pen(Color.Black,1)
  Seq.pairwise vals |> Seq.zip colors |> Seq.iter (fun (c,(a1,a2)) -> g.DrawPie(p,r,a1,a2); g.FillPie(c,r,a1,a2))

could be

red = new SolidBrush(Color.Red) 
green = new SolidBrush(Color.Green) 
blue = new SolidBrush(Color.Blue)
colors = seq {
    red
    green
    blue
    !colors
  }

pie data (g: Graphics, r: Rectangle) =
  vals = 0.0 :: map snd data
  total = sum vals
  angles = map (v -> v/total*360.0) vals
  p = new Pen(Color.Black,1)
  pairwise vals | zip colors | iter (c,(a1,a2) -> g.DrawPie(p,r,a1,a2); g.FillPie(c,r,a1,a2)

"." could be use to access fields.. .red would access this.red field while red = would mean "let red ="

[baronfel]

It's great that you're so passionate about your syntax suggestions! It would help all of us follow along if you'd use triple-backticks (```) to help make your syntax clearer.

Here's an example of your latest round of suggestions formatted in this way:

this

let red = new SolidBrush(Color.Red) in
let green = new SolidBrush(Color.Green) in
let blue = new SolidBrush(Color.Blue) in
let rec colors =
  seq {
    yield red
    yield green
    yield blue 
    yield! colors
  }

let pie data (g: Graphics) (r: Rectangle) =
  let vals = 0.0 :: List.map snd data
  let total = List.sum vals
  let angles = List.map (fun v -> v/total*360.0) vals
  let p = new Pen(Color.Black,1)
  Seq.pairwise vals |> Seq.zip colors |> Seq.iter (fun (c,(a1,a2)) -> g.DrawPie(p,r,a1,a2); g.FillPie(c,r,a1,a2))

could be

red = new SolidBrush(Color.Red)
green = new SolidBrush(Color.Green)
blue = new SolidBrush(Color.Blue)
colors = seq {
  red
  green
  blue
  !colors
}

pie data (g: Graphics) (r: Rectangle) =
  vals = 0.0 :: map snd data
  total = sum vals
  angles = map (v -> v/total*360.0) vals
  p = new Pen(Color.Black,1)
  pairwise vals | zip colors | iter (c,(a1,a2) -> g.DrawPie(p,r,a1,a2); g.FillPie(c,r,a1,a2)

[cloudRoutine]

@DjSinae fslang-suggestions is the appropriate venue

[cartermp]

@DjSinae As @cloudRoutine mentioned, the fslang-suggestions repository is a great place for this. You can create an issue there suggesting syntactical changes for various things (operators, let bindings, pipes, etc) and we can evaluate their merit based on our criteria for accepting changes into the language. Thanks!

[sin8]

bah it's ok.. cya

[7sharp9]

We seem to have hit mainstream with all this trolling.

[HoraceGonzalez]

@7sharp9, mission accomplished?

[abelbraaksma]

I know you're kidding with the latest comments, but I think sin8 was trying his best with the limited means he has. I know the feeling of trying to express a certain sentiment about a "feature" or anything of a language or tool. Quite often the answer is RTFM or something similar. And correctly so, but the M is often too daunting for people to understand and today's fast-paced world "we, the people" want to have things working instantly.

For this to happen "we" often forget this means "we" need to understand things instantly, esp. w.r.t. programming in a new language. Just as with natural languages, unless you have a knack for things or a good grasp of different paradigms, this is an impossible task and simply requires time. Which, needless to say, "we" do not wish to give (swipe left, anyone?).

If sin8 would have taken the time to read through the original papers on F#, esp. pre-2007, it could have helped understand the reasons behind the designs. Or if he was well-versed in ML or in language-design in general (after I wrote my first parser back in the day I started to understand much better why languages sometimes have seemingly quirky syntax).

But the more important thing we can learn from sin8's "trolling" (which I still think wasn't meant as such) is the hurdle you have to take as a beginning programmer. I come from the C# world. I had much to learn from Petricek's excellent book which puts F# next to C# to start thinking functionally. I had some background in functional languages, that helps.

After a while, the quirky syntax becomes your world. But when you start out you can't understand the difference between fun x y -> x + y and fun (x. y) -> x + y, or why the FSI always says things like val it : x:int -> y:int -> int = <fun:clo@2-1>. Now it gives me a wealth of information, but when you just start out grasping the concept of "everything is a function" (only to find out slowly that this is almost always the case, but not really...) and to think functionally, all this new terminology is a bitch (pardon my french) and paired with abstract concepts (domains, mappings, folding) makes it only all the more steeper as a learning curve.

Since this topic is about adopting F#, I'm not suggesting we do anything about the syntax, I think it is great as it is, but there should be some way we can take people by the hand and explaining them why it is great. If I only had a tutor at the time that explained it the way I understood it, I would have had more pleasure sooner in F#.

(as an aside, I think that if you would start out as a programmer with F# as a first language, it will be comparatively easier, but unfortunately, the days universities taught only functional languages is behind us, as is the programmer with a university background).

There will always be people not liking the syntax (gosh, I hated C# syntax when I came from C++, now it is the other way around), and you won't convince everyone, but if we can desteepen the curve of learning F# that would be awesome, esp. in our fast-paced swipe-packed, thumbs-up or -down world.

[bryanedds]

There is, I think, an inherent tension between the syntax we as humans find expressive and the syntax that is most palatable for the comparatively cold machinery of semantic abstraction.

For example, semantic abstraction basically demands all of our syntaxes be homoiconic. However, it is actually difficult to create a homoiconic syntax that is fully to the liking of our human proclivities - adjusted as we have become to the succinctness of natural language.

But even putting that aside, the pragmatics involved in getting F# out to a reasonably large number of users did, in my estimation, require that it be bootstrapped on that of an existing language (in this case, Ocaml).

Unfortunately, bootstrapping the F# language off of Ocaml implies a great deal of syntactic baggage that, to this day, very highly constrains our language's syntax.

The best way to become empathetic with the designers of a language with regards to syntax is to write a language parser oneself. It is surprising just how nuanced and difficult it is to contrive a syntax that can both be extensible for new features and a priori non-broken for all possible edge cases.

[s-trooper]

missing optional lang features have no or minor influence for F# adoption. it's real error to think otherwise. lang marketing was and will be always hard topic nor i am a expert but i think MS with couple of statements can more do to F# adoption than any HKT support. I think opinions of real marketing ppl sort of coca cola, apple =) to this topic would help a lot.

[lambdakris]

Well, what I find particularly interesting about the recent discussion is that some of the suggestions/criticisms could be considered legit as they were addressed recently by ReasonML wrt Ocaml and longer ago (with many other considerations) by Haskell wrt ML.

Changing syntax is certainly a last resort for a language but I think it might be of value - even if just as a thought exercise - to separate the suggestions for change in syntax from the historical reasons for the syntax and the perceived effort in changing the syntax. Yes, there are reasons why things are the way they are, but they don't have to be that way (as shown by other ML derived or inspired languages), and there are also reasons other than lack of familiarity, to like the idea of some adjustments to the syntax.

In particular, after over a year of continuous use, I am convinced that addressing the difference in syntax between a tuple literal and a tuple signature (as done by ReasonML) would be a boon. As would addressing the usage of [] for list literals and then reusing [] in certain cases for array signatures. I understand that there are raison d'etre's for both of these things, but in my experience they get in the way of cognition even if you know what those reasons are. I intend to post these suggestions on fslang-suggestions after F# 4.1 is out the door (let things settle down a bit), but I wanted to take this opportunity to play devil's advocate on this discussion.

And let's be honest, the biggest shortcoming in the recent suggestions was the tone and style, not the ideas themselves...

[bryanedds]

I hope I didn't come across as being one-sided or discouraging suggestions for changes. I was just hoping to suggest that the most effective way to propose changes is to first empathize with the way things are - and that does take some time and study for people new to the particulars of a given language. I think, for the most part, no one here is intending to take a particular side, but rather trying to convey the very challenging pragmatics of the current situation generally.

As to tone, I agree with reservations. I'm not someone to police tone, and nor is anyone here tone-policing (thank gawd). I think it's good to keep in mind that tone, tact, etc. is something that correlates most closely with a person's age than anything else. So by overly focusing on tone, one would implicitly reject the content of suggestions made by younger people who may actually have a fresher perspective. So we definitely shouldn't do that, and I am happy to see that we aren't.

Ideally, one should never let tone outweigh the content of a message... although it can sometimes be hard to do in practice - especially when one's own perspective leans toward the opposing side of the argument.

[abelbraaksma]

I may be mistaken, but I think that for promotion or adoption of F# we should focus on what we have. Change is good, tone can be made irrelevant, but change as has been suggested here, even if accepted, will take years before it gets adopted into F#. Minor improvements may go quicker, but let's face it, implicit let bindings, implicit member access (like with in VB) and agnostic application of [..] syntax are all very minor changes (I'll refrain for an argument for or against) that are not going to persuade large groups to all of a sudden embrace F#.

If you want syntax to drive people towards a language, think again. There have been very natural and expressive languages, for instance Rebol, that have seen a certain enthusiastic use, but have never really caught on. Conversely, languages with complex syntax and rules, like C++, have become de-facto standard, even though learning C++ from scratch, or even coming from Java or C#, is very hard (I'd argue harder than switching to F#).

I don't know if there's a trend towards functional languages recently, but not so long ago it was very hard to get decent books or tutorials on Scala, OCaml, F# or Haskell. I have the feeling they're catching up, but not to replace mainstream languages. If we take a look at tag-popularity (one way of counting usages of a language: http://stackoverflow.com/tags), we see a top 15 of, in order: JavaScript, Java, C#, PHP, Python, C++, SQL, Obj-C, Ruby, C, R, Swift, VB(A), Matlab, Scala.

With the top-4 with over 1M questions, and, discounting SQL and R, the first general-purpose functional language coming at number 15 with 60K questions, it's not "just a gap", but the difference is huge (6% of the Java count). It is even bigger with F# (1M C# vs 10K F#, i.e. 1%).

If we want to drive F# forwards and want to "convert" some OO people into functional people, then we'll need a more drastic strategy than just some language features. I think improving the "out of the box" experience would be an excellent start (ever tried making an F# WPF or WCF application from scratch?), but also availabilities of utilities and integration (auto-reverse-engineer into F# is terrible (if at all possible), good unit-testing is daunting (I've spend weeks becoming productive on a large-scale project) and quick-starters with low entrance-level (I often visited fssnip.net, but the very terse explanation, if any, is hardly ever enough to understand the examples, let alone apply them to your own situation, you need a degree in science...).

Just rambling a bit, sorry for that. I'm sure many of these ideas have already been mentioned. The point is to get a good central point for users to get their information and to make certain projects available from VS directly (i.e., as templates).

[21c-HK]

But even putting that aside, the pragmatics involved in getting F# out to a reasonably large number of users did, in my estimation, require that it be bootstrapped on that of an existing language (in this case, Ocaml).

Unfortunately, bootstrapping the F# language off of Ocaml implies a great deal of syntactic baggage that, to this day, very highly constrains our language's syntax.

This is a great point made by @bryanedds. At that point in time, it was probably the right decision to support F# syntax that is backwards compatible to a limited subset of OCaml.

While I am against completely changing syntax the way DjSinae proposed, I support the idea of making the syntax more consistent to make it easier to learn and remember. I really don't want this thread to turn into a syntax discussion, but simplifying the learning of F# in any way without breaking most code would definitely help adoption.

Edit: Moved the remainder of this comment to that thread to not distract too much from this thread.

[cartermp]

@21c-HK I don't think this was an issue in vs2015 (correct me if I'm wrong), but the only "verbose syntax" I saw was when hovering over structs, and they still have that kind of syntax. This certainly won't be an issue in vs2017, though, as QuickInfo tooltips are definitely showing lightweight syntax. At the very least, our official docs use only lightweight syntax. There's one article on verbose syntax, and that's it.

I think it's an interesting exercise to see if it's possible to write the equivalent of a Roslyn Analyzer which detects any verbose syntax and offers a conversion to lightweight syntax if it can. That would definitely ease some of the pain of continuing to see older stuff in a codebase. Won't solve the internet/blog problem, but it would be a start.

Your other examples about there being not equivalent lightweight syntax seem like fine candidates for fslang-suggestions. I agree that it's definitely an "old" style that shouldn't really be used unless absolutely necessary.

[bryanedds]

F#'s #light syntax takes a lot of inspiration from Python, and I think rightfully so. And a big part of Python's credo is 'there's only one way to do it'. I like that credo because it makes it so much easier to step into new code bases when mostly everything is idiomatic-by-default.

However, the unfortunate side-effect of augmenting a language's syntax is that one often ends up creating duplicate ways to express the same things. This undermines the nice and tidy philosophy of 'there's only one way to do it', and therefore I suppose that this consequence must weigh in if we wish to uphold that credo like Python.

[21c-HK]

I don't think this was an issue in vs2015 (correct me if I'm wrong), but the only "verbose syntax" I saw was when hovering over structs, and they still have that kind of syntax. This certainly won't be an issue in vs2017, though, as QuickInfo tooltips are definitely showing lightweight syntax.

I am glad that this will be changed, but VS 2015 still displays verbose syntax in tooltips and F# interactive for interfaces and structs. The official F# language reference also shows the verbose syntax for interfaces, classes, and structs for completeness, but that may confuse beginners.

[cartermp]

@21c-HK Note that the syntax there is showing the general form of the construct, where [something] is optional. It's a bit more formal than what you might find in other places of the documentation, but that's always something which can be changed.

I see what you're referring to. In vs2017, interfaces defined in F# are still shown with verbose syntax on hover, but those defined elsewhere are not. That seems like the kind of thing which could change. Structs aren't, because prior to F# 4.1 the only way to define something as a struct is with struct...end syntax. I think it's perfectly acceptable to show a hover with that syntax of that's how you define it.

[21c-HK]

Structs aren't, because prior to F# 4.1 the only way to define something as a struct is with struct...end syntax. I think it's perfectly acceptable to show a hover with that syntax of that's how you define it.

That was probably I typo, because I've been using the (lightweight) attribute syntax for structs since F# 3.1. So that should change in VS 2017 too.

[cartermp]

Actually not a typo, a legitimate lack of knowledge (hilarious, since I knew full well about the documentation on structs which shows the attribute approach as one of two ways to define one).

This is actually an interesting point - if using [<Struct>] to omit the struct...end syntax is considered the preferred way to define those types, then do we represent it as such in type signatures on hover? Is it considered a replacement and a preferred way of doing things? What about just defining an F# record and giving it the [<Struct>] attribute? These are problems that C# faces as well, and the team has introduced new features in vs2017 which use Roslyn to recognize "old" ways of doing things and suggest replacing them with newer and more preferred syntax.

For example, code such as this:

var item = input as ItemType;
if (item != null)
{
    // do something with 'item'
}

triggers a lightbulb which suggests changing the code to this:

if (input is ItemType item)
{
    // do something with 'item'
}

This is configurable of course, but the general idea is to gradually move code "forward". This seems like a great thing for F# tooling post-vs2017, provided the replacements one should move forward to are quite clear. Do you think something like this would help newcomers to the language, and perhaps even seasoned F# developers who aren't aware of a newer, more preferred syntax?

Regardless, I think there's a great actionable item from a tooling perspective here with Interfaces, when defined in F#, looking differently on hover and in FSI than interfaces defined in C# or VB. I think that's something which could be changed.

[jeroldhaas]

I think this is an opportune moment to raise a separate issue discussing "vintage" syntax vs. modern syntax, suggestion tooling, and in which project to place it (visualfsharp vs fspt), if accepted changes occur.

[abelbraaksma]

Syntax can most certainly be improved, but shouldn't we create a new thread for that? Perhaps to collect what has been suggested over the years and try to come to some consensus? @21c-HK's points are all very valid and some can perhaps be resolved with changes to the syntax BNF, others with compiler switches (for instance to enforce light syntax).

But generally, with any somewhat mature language, serious changes to the syntax are often very hard because of backwards-compatibility issues and unambiguous syntax (there's a reason some constructs require verbose syntax still, though revisiting these reasons and finding out whether still valid is probably a good thing).

But since this thread started about promoting F#, should we really diverge into syntax details? Isn't it better to try to draw the big picture (and get us a neon sign on Times Square?).

(EDIT: oops, didn't refresh, just seeing the same being said already by @jeroldhaas).

[21c-HK]

I just created a separate issue on fslang-suggestions dedicated to making the syntax of F# more consistent and more simple. I have moved a large part of my syntax related comment from this thread to that thread.

@lambdakris, @cartermp, @bryanedds, @abelbraaksma and everyone who has talked about syntax in this thread is encouraged to move his/her comment from this thread over to the other thread like I did to keep this thread focused for later readers. I welcome your input on making syntax more consistent and more simple in that thread.

[dsyme]

Thanks, please move the language suggestions to http://github.com/fsharp/fslang-suggestions, thanks.

[21c-HK]

Done. Updated my other comments to link to the issue on fslang-suggestions.

[gulshan]

How can F# be posed as a great choice for the first programming language to learn? Learning a functional language at first will be easier for many as it is closer to mathematical concepts. For this, I think-

• There should be a single step lightweight installer available for all major platforms.
• Support for visualization aka out of the box support for basic 2D graphics, as normally used by beginners.
• Text-based, interactive and video tutorials designed for beginners. Many languages are supporting interactive tutorials in the browser. For F#, there is www.tryfsharp.org , but it is dependent on Silverlight.

[jeroldhaas]

Perhaps a bundled installer with VS Code and packages, along with fsharp, yes, however handling the .net/mono installation would be too difficult. On Dec 20, 2016 2:13 AM, "Gulshan" notifications@github.com wrote:

How can F# be posed as a great choice for the first programming language to learn? Learning a functional language at first will be easier for many as it is closer to mathematical concepts. For this, I think-

• There should be a single step lightweight installer available for all major platforms.
• Support for visualization aka out of the box support for basic 2D graphics, as normally used by beginners.
• Text-based, interactive and video tutorials designed for beginners. Many languages are supporting interactive tutorials in the browser. For F#, there is www.tryfsharp.org , but it is dependent on Silverlight.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Microsoft/visualfsharp/issues/1339#issuecomment-268171889, or mute the thread https://github.com/notifications/unsubscribe-auth/AAzBiGRt2KIaGMlX3dcPkglzZwTydfukks5rJ4AQgaJpZM4JJuVb .

[cartermp]

@gulshan I think part of the issue with having a single-step, lightweight installer is that F# doesn't have its own runtime. It's also important to note that others (Ruby, Python) are super simple on machines like macOS because it already comes with a runtime.

I'm definitely interested in what it takes to lower the bar for acquisition. I think that .NET Core makes that much simpler (tooling is still in Preview, so we can't see that come to fruition right now), but the current way you install it is pretty simple - single installer for Windows, single installer for macOS, apt-get install dotnet for Ubuntu, etc. AFAIK there's also a brew install dotnet package coming down the road. This also installs all the necessary bits + templates to get going with F#.

Once you get past this, there's Ionide (which comes with FORGE) that makes things really really easy for a beginner. For those who want VS or VS for Mac, F# is also available via a single installer.

I think much of this is just going to have to be solved via better communication and documentation. When the collective blogosphere and documentation sites start saying the same things about acquiring F# and the bits needed to run F#, it's a lot easier to increase adoption.

[GiorgioG]

As someone trying to learn F# (with .NET Core) the experience is incredibly frustrating - I've been a .NET (C#) Dev since 1.0 Beta in 2001. The tooling just isn't ready (it's not a complaint, just stating the facts.)

• Generating a .NET Core F# web project of any kind with 'yo aspnet' yields a project.json based app that can't be 'dotnet migrate'd. If you get past that hurdle, and you try using VS 2017RC, you can't add the fsproj file to a solution because "The imported project "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Sdks\FSharp.NET.Sdk\Sdk\Sdk.props" was not found."
• Attempting to work in VS Code (on a Mac this time) with Ionide yields broken Intellisense (even after all of the suggested workarounds.)

F# appears to be much much better than C# on many fronts. It's unfortunate that these types of hurdles await those who want to use F# today with .NET Core.

Thanks for all the efforts - I just wanted to share my experience.

[abelbraaksma]

"The imported project "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Sdks\FSharp.NET.Sdk\Sdk\Sdk.props" was not found."

@GiorgioG: This is clearly a bug in the 2017 RC and should be reported and addressed (that's why it is an RC). I work with F# and C# mixed projects on a daily basis using VS2015 and adding (or removing) fsproj or csproj files from solutions is painless. F# Support for .NET Core is new. ASP.NET, I didn't even know it was part of the package, but I don't think that's a target platform for F#.

Which means you addressed perhaps a big, but important shortcoming: explaining the world what F# should be used for and what it should not be used for. When I started out I tried a WinForms project with F#. It is not impossible, but it is not designed for that task, and compared with C# it is a painful undertaking.

I think we should emphasize what F# can and should be used for. It is definitely a very mature system, but it simply is not meant to be used in some scenarios and hence will cause confusion and problems for people trying to use F# in every single place where they used to use C#.

Attempting to work in VS Code (on a Mac this time) with Ionide yields broken Intellisense (even after all of the suggested workarounds.)

Same as above. VS Code support is new and there's no final release yet. This particular bug was reported and fixed (iirc). In the next RC or final version you should be able to use it.

It's unfortunate that these types of hurdles await those who want to use F# today with .NET Core.

F# is stable in VS2015, Update 3. Though I recommend using F# PowerTools to make life easier. I'd recommend to wait a bit with VS2017 until there's an official release. Or not, but then please report those bugs (just raise an issue here), it is valuable for us to know about them so we can fix them.

[GiorgioG]

ASP.NET (Core), I didn't even know it was part of the package, but I don't think that's a target platform for F#.

At this juncture, early adopters are the ones likely trying to use .NET Core primarily for ASP.NET Core (hosting in docker containers, etc.) This means it's generally greenfield development. If I'm trying to leverage/learn F#, why would I want to mix C# and F# and confuse myself in the process? F# may be stable in VS2015 for full .NET Framework, but with the new MSBuild-based format for .NET Core, that doesn't help people in my situation who would like to adopt F# (MS has stated they won't be back-porting the new project format support in VS2015.)

[smoothdeveloper]

@GiorgioG would you say ASP.NET Core with C# is a stable and full fledged product by now? I don't know here but if it is not the case, it is unlikely support for F# would be better. F# was initially not even on the table for ASP.NET when the core thing started (the same way VB.NET wasn't), it was initially a C# only.

Hopefully the whole .NET Core will mature soon with coming few releases of the full platform but it seems everyone is firefighting (tooling, runtime, platform, documentation) so F# is last of their concern which is understandable.

What is less understandable is that it also affects tooling in VS which is flagship product from MS and for decades has fostered a developer community around MS eco-system.

[GiorgioG]

@smoothdeveloper I would say ASP.NET Core with C# is quite stable and ready for production. The trouble with tooling has to do with Microsoft's decision to stop using the project.json format between RC2 and RTM of .NET Core SDK 1.0. The 'tooling' is still in preview (though it has stabilized and is usable in VS2017 enough that I would trust it for real work) for C# projects.

[smoothdeveloper]

Thanks @GiorgioG, with no tooling, I won't say something from MS is "production ready", many more people still use alternative platforms / web stacks and ASP.NET Core doesn't even register at this point.

People likely to be interested by F# and it's future on .NET Core tend to employ mono for production ready deployments.

I don't want to spread FUD about .NET Core, nor I want to believe the hype of a minority so thanks for feedback, ultimately I hope .NET Core will make inroads in prevalence of JVM for large scale deployments.

@abelbraaksma

I think we should emphasize what F# can and should be used for.

I just found out anecdotically that F# produce faster code converting imperative (and safe) numerical C# code casually, I think this should be advertised more.

Also all the aspects about correctness, expressiveness and rich type system light years ahead what is available in C#, this is really deal breaker for modeling business logic while keeping codebase size down.

Although it all come at a significant cost in learning the language, and getting away from mostly 100% OO constructs, because F# supports OO but it is not a language to implement OO frameworks.

[GiorgioG]

@smoothdeveloper

Also all the aspects about correctness, expressiveness and rich type system light years ahead what is available in C#, this is really deal breaker for modeling business logic while keeping codebase size down.

...getting away from mostly 100% OO constructs,...

These are the reasons why I'm here and desperately want F# to succeed.

[21c-HK]

@GiorgioG Thank you for sharing your experience. I find anecdotes like yours that reflect the reality of getting into F# very important. Me and other experience F# developers have likely forgotten/overcome all the hurdles. You are a very experienced .NET developer. Imagine what it must be like for a beginner?

Microsoft has vastly improved their communication (e.g. docs.microsoft.com) with regards to F#, but it still seems to be come last in terms of priority with regards to their latest efforts. .NET Core and .NET Standard have experienced a lot of unexpected last-minute changes, so they seem to focus on C# (as always) just to get something stable out of the door. This is not a valid excuse, it's just what it is right now.

Regarding your specific problem, I would say that F# does not support .NET Core until FSharp.Core.netcore is officially released, which still seems to be in the works (#1217). I would wait until VS2017/.NET Standard 2.0/F# 4.1 is officially released. .NET Core will be a lot more stable and probably more usable from F# then.

@abelbraaksma

I think we should emphasize what F# can and should be used for.

I tried to do that in the beginning of this thread (quoted below). I am convinced that F# should be used for every problem or domain. But that does not mean that you should use F# to call every .NET API/library that has ever been released. Amazing tooling in C#-land or web-land is required to cover up the fact that the underlying technology is a poorly designed mess. That's the real reason why you don't want to use WinForms, XAML or web technologies directly. Missing templates for some technologies, tooling bugs (e.g. @GiorgioG problem) and sub-optimal tooling for artificial problems (e.g. XAML) are all separate issues that are unrelated to the F# language. Those issues just show where the priorities of the tooling vendor lie. Here is what I wrote in the beginning:

We need to make clear that F# is better than C# in every aspect as a language (which it is!). And this is why F# does not need as much tooling as C#, because it is simply more expressive and you can solve problems directly without fiddling around with XML or poorly designed imperative OO APIs. This is not about not-being-nice, but about being honest.

[smoothdeveloper]

How to advertise F#? we could propose F# taglines for geeks:

did you wish python didn't had so many classes and could handle lambda that are more than a single expression? try F#

did you wish C# was not allowing you to shoot yourself in the foot so much and more functional oriented? try F#

did you wish to use OO and procedural constructs in haskell? try F#

...

[GiorgioG]

How to advertise F#?

Want to get more work done by writing less code? Use F#.

[bryanedds]

Simplify your code. Simplify your life. F#.

[21c-HK]

Make programming great again! By using F#.

[gulshan]

F# need resources like this to drive adoption- https://mva.microsoft.com/en-us/training-courses/introduction-to-programming-with-python-8360 "Introduction to programming with F#"

[rmunn]

Three projects. Zero bugs. How? F#.

Or, just slightly more verbose:

Three business critical projects released. Zero bugs reported. How? F#.

[gregoryyoung]

As a side note to the discussion. Another thing that is worth discussing is the use of F# in a side role with projects. This gets people more comfortable with using it in a less risky environment.

As example fake builds for C# code. Using F# for operational tasks. We have added to these use cases with privateeye (profiler based in F# repl).

These ancillary use cases can really help in making the top of the funnel quite a bit bigger.

[forki]

@gregoryyoung Unfortunately Microsoft removed F# from the default installation and fsx files won't trigger the F# installer. This caused many troubles for C# shops that just used a couple fo FAKE build scripts.

[gregoryyoung]

@forki yep I am aware of this and its a major issue. My comment was more on driving adoption through the use of ancillary things as opposed to trying to get people to bring over codebases etc.