@21c-HK I think something bad is happening to GitHub in the last few hours. Multiple historical pull requests have disappeared from https://github.com/dsyme/visualfsharp/pulls, for example

dsyme on 11 Jul 2016

@dsyme Are you sure this is GitHub's fault? I find it curious that #797 and #799 are still there and only #798 (Part 1) is missing. #804 is also still there but #803 (Part 2) is missing. #808 and #810 are still there and only #809 (Part 3) is missing. This looks to me that these issues were deliberately removed.

Edit: Part 1 - 3 are back up again. By the way, does anyone know what happened?

21c-HK on 11 Jul 2016

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.

What new and better solutions do you have in mind here? For example, Azure is an existing Microsoft product where we could have significant integration with in the form of Fluent F# APIs for new services. I think this could help F# adoption significantly.

The target audience should not be existing C# programmers.

I find myself agreeing with the premise that we shouldn't be trying to cannibalize the C# development pool. I suppose there are plenty of C# developers out there who mesh quite well with the idea of Functional-First programming (as opposed to Object-Oriented-First), but I do think that the biggest bang for our buck in terms of attracting people to F# will be in the form of developers out there who already love functional programming.

This raises a question, though - of that crowd, who is best to attract? I'm not a strong believer that existing Haskell and Scala devs will come rushing to F# the instant it's got full support on .NET Core, for example. Things like the lack of Higher-Kinded Types might feel like a downgrade to people who are used to using them. Would it be an attractor to add more "Type Theory Features" to the language?

I've always seen F# as one of the best (if not the best) "blue collar functional programming language". It's dead simple to write good, clean functional code for solving real-world problems, and that's largely because the unique language features F# has and the tooling you can use are some of the best out there for functional programming (if not the best). How could this aspect of F# be made even more awesome?

Personally, I'm a lover of ad-hoc polymorphism, find F# lacking in this area (even compared to C#!), and would love to see some proposals on how to improve it. But that's just my own opinion - I generally prefer ad-hoc polymorphism to pattern matching (even though I love pattern matching). Is this true for other people? I have no idea. I'm kind of weird in that I love multiple ways to attack a problem - ad-hoc polymorphism and pattern matching - and will use one or the other when it "feels" right.

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.

This isn't a strategic decision - it's a point-in-time technical decision. The guidance for any kind of package authoring is to pick the lowest version of the .NET Standard that you can get away with. We're certainly not putting this one in the bag as complete. I'd love to see this get lowered to the lowest .NET Standard version that we can have. This is something we'll look at again - but right now, the top priority for FSharp.Core is getting 100% of the APIs working on .NET Core and bringing it out of alpha.

cartermp on 11 Jul 2016

👍3

@cartermp

What new and better solutions do you have in mind here?

I was referring to the home-grown F# technologies mentioned earlier. For example:

Paket instead of NuGet
FAKE instead of MSBuild
Suave or WebSharper instead of ASP.NET
MBrace.Azure instead of some fluent F# wrapper around an OO-API of Azure
a new F#-only project system instead of VS project systems (which was holding back VFPT), project.json (which was dropped by Microsoft recently) and the new Common Project System (which is C# and VB only, and not open source)

I'm not a strong believer that existing Haskell and Scala devs will come rushing to F# the instant it's got full support on .NET Core, for example. Things like the lack of Higher-Kinded Types might feel like a downgrade to people who are used to using them.

You are right. This is also a worry of mine. Higher-kinded types is probably the only language feature that would have an effect on F# language adoption, because Haskell and Scala programmers think that a language without higher-kinded types cannot be taken seriously.

Personally, I'm a lover of ad-hoc polymorphism, find F# lacking in this area (even compared to C#!), and would love to see some proposals on how to improve it. But that's just my own opinion

How do you find F# lacking in this area? As far as I know, the only feature missing from F# is implementing the same interface multiple times on the same type with different type arguments. This situation was slightly (but not satisfactorily) improved in F# 4.0. I personally find ad-hoc polymorphism overrated. Operator overloading and method overloading have their uses cases, but instead of using interfaces there is usually a better type-based or functional solution (depends on the concrete problem). And member constraints in F# provide extremely powerful and flexible structural ad-hoc polymorphism, if needed, that C# does not even have.

This isn't a strategic decision - it's a point-in-time technical decision.

This is what I find confusing. F# Core today has a version for PCL profile 259. PCL profile 259 will comply with .NET Standard Library 1.0. .NET Core 1.0 will require .NET Standard Library 1.6, which means that projects compliant with .NET Standard Library 1.0 will run on .NET Core 1.0 (because .NET Standard Library 1.6 will be backwards-compatible with .NET Standard Library 1.0). So transitively, F# Core today should be able to run a .NET Core that is compliant with any version of the .NET Standard Library. Could you please elaborate why this does not work?

21c-HK on 12 Jul 2016

Paket instead of NuGet

FAKE instead of MSBuild

Suave or WebSharper instead of ASP.NET

MBrace.Azure instead of some fluent F# wrapper around an OO-API of Azure

a new F#-only project system instead of VS project systems (which was holding back VFPT), project.json (which was dropped by Microsoft recently) and the new Common Project System (which is C# and VB only, and not open source)

Why the dichotomy? I want to live in a world where I can pick between a variety of options, not just the handful of tools blessed by some members of the community. Using the web as an example, I'd probably pick Suave if I had the choice because I think combinator-based routing is brilliant for building a web API, but if I had to choose ASP.NET Core in the workplace for whatever reason, I'd be a lot happier if there was _some_ story for F# in place for that rather than having no option at all.

That's the key value proposition here - choice - not being forced down a path _away_ from Microsoft tech.

But I think there's two sides to that coin. We at Microsoft have to do a better job of acknowledging the fact that there are great OSS projects out there, and we can attract people to .NET and .NET languages by highlighting that. Microsoft has been traditionally awful at this, and it's something I'm personally pushing for internally, with some success already (such as suggesting Ionide in our official documentation). It's a matter of keeping momentum for OSS going and trying to snuff out any perpetuation of that nasty NIH syndrome.

How do you find F# lacking in this area?

Long story short, every time I write a pattern match --> dispatch function, I end up missing Clojure protocols. This is purely my own opinion and my own preferred way of doing things. I'm happy to start a discussion elsewhere so as not to bog down this thread with opinionated discussion about potential language features.

So transitively, F# Core today should be able to run a .NET Core that is compliant with any version of the .NET Standard Library. Could you please elaborate why this does not work?

Unfortunately, the interplay between the .NET Standard and various implementations isn't quite baked, so it's kind of confusing. Yes, any of the versions of netstandard1.x run on .NET Core, but we're choosing not to optimize that at this time because we don't have all of FSharp.Core in working order on .NET Core yet. The easiest way to get everything running there is to have access to the most APIs on .NET Core, thus the highest version of netstandard1.x is chosen for now. We want to lower this once we can bring FSharp.Core out of alpha.

cartermp on 12 Jul 2016

👍7

Edit: Emphasizing that defaults matter and more details why Visual Studio Code with ionide would be a good default development environment.

Why the dichotomy? I want to live in a world where I can pick between a variety of options, not just the handful of tools blessed by some members of the community.
[...]
That's the key value proposition here - choice - not being forced down a path away from Microsoft tech.

I think we have lost context here. My posts in this thread are not about OSS vs. Microsoft. My posts are about what I think would have the most impact in driving F# adoption. One factor was a frictionless out-of-the-box experience that is competitive with or better than C#. Microsoft in the past has not been willing to make this happen for F# (while it seems that F# on .NET Core might be another story). This is why @swlaschin and I suggested that the F# community needs to take full control of the out-of-box experience to achieve this goal.

As Don Syme said earlier:

It's well known that the defaults matter. They really, really matter.

Part of this would be giving new F# developers guidance on how to have the best development experience with F# by making Visual Studio Code with ionide (or Atom with ionide, but Atom is not that great) the default development environment. Here is why:

Cross-platform (removing resistance to reach more developers)
Leverage (more developers means more improvements)
Speed (less dependence on VS means faster improvements)
Integration (already integrates the best infrastructure tools available for F#: Paket, FAKE)
Familiarity (featuring a pimped up command-line probably appeals to many open source developers)

Compare this page with this one. Which one looks more appealing to open source developers or developers in general? Even Microsoft would benefit from this because Visual Studio Code is still branded with "Visual Studio" and is living proof of the "new Microsoft".

And Don Syme has pointed out how attractive home-grown F# upstack technologies have become. It's not that they compete directly with Microsoft products, but that they stand on their own as really elegant solutions to certain problems. Projects like these are what create the required attention in the open source community to pull-in developers from other functional languages to grow the F# community. The still small F# community has nothing to gain from diverting its limited resources to integrating with existing Microsoft products; unless we do have something to gain from it in which case we do integrate with them (e.g. MBrace <-> Azure, Paket <-> NuGet). On the other hand, F# does have a lot to gain from Microsoft's efforts in bringing .NET to more platforms (e.g. .NET Standard Library, .NET Core, purchase of Xamarin) and making F# run on these platforms. So this is definitely appreciated by the F# community, but at the same time we need to be focused (and selfish) while we are small.

I'm personally pushing for internally, with some success already (such as suggesting Ionide in our official documentation).

Thanks! That's awesome.

21c-HK on 12 Jul 2016

👍1

The .. .F# community has nothing to gain from diverting its limited resources to ...;

I generally recommend not taking a single point-of-view on what's worthwhile for a diverse community.

The F# contributor and user base is made up of many different perspectives and interests. For some, indeed many, integration with other .NET technologies, tools and commercial products is key and they are willing to put a lot of time into this. This helps to grow adoption and mindshare, and is part of the bread and butter of life in the software world. So there are definitely people with a lot to gain from putting time into working with standard .NET toolchains. Not everyone, but many.

There is definitely also a growing "F# centric" point of view with matching tools, which is also helping to grow F# adoption and mindshare.

dsyme on 12 Jul 2016

👍6

@cartermp

Long story short, every time I write a pattern match --> dispatch function, I end up missing Clojure protocols. This is purely my own opinion and my own preferred way of doing things. I'm happy to start a discussion elsewhere so as not to bog down this thread with opinionated discussion about potential language features.

Could you write this up in a suggestion on fslang.uservoice.com please? Or send me private email. Or a link.

thanks!

dsyme on 12 Jul 2016

👍3

I think the point on FSharp.Core targeting .Netstandard one is a really good one, F# should make arrangements to make FSharp.Core hell go away.

7sharp9 on 12 Jul 2016

👍1

Personally, I'm a lover of ad-hoc polymorphism, find F# lacking in this area (even compared to C#!), and would love to see some proposals on how to improve it. But that's just my own opinion

Row polymorphism aka duck typed record semantics? That would my my vote. (If I had any left :-) )

7sharp9 on 12 Jul 2016

VS Code with ionide seems to have overtaken Visual Studio with VFT in terms of usability and functionality

Just no.

Krzysztof-Cieslak on 12 Jul 2016

👍4

vscode is pretty good, but lacks a few things like metadata viewer but not much more. I don't use VS or XS at the moment.

7sharp9 on 12 Jul 2016

@dsyme

Could you write this up in a suggestion on fslang.uservoice.com please?

I think what @cartermp wants are interfaces that support retroactive extension of existing types since this is what is special about Clojure's protocols, which dispatch dynamically on the type of the first argument. Swift's protocols also support this through a run-time extension mechanism they call "extensions", which also dispatch dynamically on the signature of the member. Haskell's type classes are also very similar, but dispatch statically on the type of multiple parameters and the return type, which is even better.

There are already feature requests on fslang.uservoice.com very similiar to this:

pattern match --> dispatch function

I am not sure what exactly the requested feature has to do with pattern matching. Could you elaborate?

21c-HK on 12 Jul 2016

The big question everyone is thinking is who is the secret identity of @21c-HK :-)

7sharp9 on 12 Jul 2016

😄2

Clojure protocols are the best! Unfortunately, I don't think they can be statically typed :(

bryanedds on 12 Jul 2016

@21c-HK

a new F#-only project system instead of VS project systems (which was holding back VFPT),

While I would certainly love a new project configuration file format (preferably TOML based), as a maintainer of VFPT I'm not sure what you're referring to being held back.

VS Code with ionide seems to have overtaken Visual Studio with VFT in terms of usability and functionality in a very short time(!)

As one of the Ionide maintainers I'm sorry to say this really isn't the case (although it is the long term goal). Features for managing your projects and solutions is sorely lacking and a huge headache for us and our users, the startup time of completions can be fairly finicky, it requires a fair amount of perquisite installations due to upstream dependencies, the REPL support is read-only, the build integrations with FAKE require a fair amount of setup which isn't great for someone totally new to F# and .Net, we're forced to rely on regex based language parsing so the syntax highlighting is nowhere near as good, we don't have any record stub or interface method scaffolding, no scope based outlining, and the list goes on.

Quite frankly Visual Studio + VFPT or Xamarin is (at the moment) the best starting experience for a new F# developer. When Ionide reaches a better level of feature parity with them it'd be great to have a page on MSDN too about getting started with F# in vscode, but I don't think we're there yet.

And even then it won't always be the best tool for the job, there are some projects and tasks where I use vscode + ionide and others where I prefer VS + VFPT, it's about using the right tool for the job while weighing the requisite trade-offs. I think the important thing is to make it easier for new users to see what those options are and when they might use them while making the experience as frictionless as possible for ALL of them. Which isn't an easy task and there aren't a lot of people working on it, but I think about where we were a year ago in terms of F# tooling and we've definitely come a long way.

cloudRoutine on 12 Jul 2016

@cloudRoutine

as a maintainer of VFPT I'm not sure what you're referring to being held back.

The Folder Organization page of VFPT says the following:

This feature is disabled by default. Because there are known issues with F# Project System in Visual F# Tools, folder organization may not work 100% correctly in all cases.

We do not advice you to introduce complicated folder structure within F# projects.

You should keep number of folders within your project as low as possible.

I have used this feature and had me scratching my head for a while because the VS project view sometimes did not match what was being written to the F# project file. I find folder support to be an essential feature for non-trivial projects.

we're forced to rely on regex based language parsing

Is this because it needs to be compiled to JS? Does that prevent you from using FParsec for parsing?

21c-HK on 12 Jul 2016

@21c-HK those Folder organization issues are also related to dealing with internal VS APIs for solution and project management, so I wouldn't blame the msbuild xml configuration format for all of it.

Is this because it needs to be compiled to JS? Does that prevent you from using FParsec for parsing?

It's because of how the editor extension API is designed and right now we're forced to use the old textmate approach. If it let us apply CSS tags to spans in the editor pane and define a CSS style for syntax highlighting we could use the same approach as VFPT by connecting VFPT.Core to FSAC and using it's lexer, but at the moment we can't. We wouldn't use FParsec.

cloudRoutine on 12 Jul 2016

Folder support in XS is also slightly buggy on the edge cases, file ordering seems to be a sticking point on tooling.

7sharp9 on 12 Jul 2016

There are obviously different opinions on what is currently the best development environment for F#. Could we gather a few opinions on what your ideal F# development environment would need to feature? I'll start with my wish list:

editor with basic support for F# (auto-completion, tooltips for inferred types, solution-wide renaming, indentation guides, auto-indentation, auto-bracket-completion, syntax highlighting, real-time error highlighting, search/replace with highlighting of current matches)
navigation (tabs for open documents, find references, go to definition, go do identifier, visual map of current document)
REPL (with same features as editor and ability to generate references and opens for selected project)
integration with essential tools like future F#-project system, Paket, FAKE, Git, FsCheck, FsUnit and FSharpLint
integrated command-line to invoke external command-line tools
folder support
open source
cross-platform
code generation (snippet expansion, pattern matching stubs for unions and records, interface implementation stubs, suggesting to open modules for unqualified types)
project scaffolding
collapsable document structure
markdown preview (with support for rendering markdown in code comments)
debugging (maybe even for REPL)
support for Xamarin

So basically the best of Ionide, Visual F# Power Tools and Visual Studio ;-). And of course, all of these features need to be so fast as to not slow down my typing or train of thought ;-).

Have I forgot anything? Is something missing that you find essential?

@cloudRoutine and other IDE extension maintainers: Are there technical limitations in Visual Studio Code, Visual Studio or Atom that prevent the implementation of any of these features?

21c-HK on 13 Jul 2016

👍2

@21c-HK There are different limitations for Atom and vscode and we've already planned to implement all of your list that's possible at the moment. As the vscode and atom extension APIs evolve and expand we'll fill in the remaining gaps.

These kinds of comments/suggestions are better directed at the individual tooling project repos as that's where most of these features will be implemented.

cloudRoutine on 13 Jul 2016

The limitations are mainly people spending there time doing the work. aka oss

7sharp9 on 13 Jul 2016

I don't see Microsofts limited investment as a problem as long as community contributions are not held up due to bottlenecks in merging pull requests. I mean there hasn't been much change in the 6 or so years I have been involved, I don't see this changing anytime soon.

7sharp9 on 13 Jul 2016

Linux support is the linchpin, IMO. Porting the existing community ecosystem to .NET Core (ie. Paket, Fake, Suave, etc...) is even more critical to adoption than the language itself.

HoraceGonzalez on 18 Jul 2016

👍4

With MS dragging their feet on a full viable release of dnc and ultraslow uptake within F# I reckon come back in 2017 to check progress.

7sharp9 on 18 Jul 2016

Yes. I'm optimistic that some of the beta/ctp/rc dust will settle after the 1.1 release this fall, especially since project.json will be retired.

HoraceGonzalez on 18 Jul 2016

1 to @HoraceGonzalez

Yes. I'm optimistic that some of the beta/ctp/rc dust will settle after the 1.1 release this fall, especially since project.json will be retired.

Absolutely agree! I personally dislike JSON project model. This is one of the reason I prefer to use .NET Core in its release instead of previous always using JSON project.

I hope F# tooling support for .NET Core in Visual Studio should always depend on MSBuild project model.

eriawan on 20 Jul 2016

Some of them may already in the pipe thanks to @dsyme (eg.: fixed, struct tuple, etc), but it would be good to have the same or similar high performance language features available in F# too (at least in parity with the C# features):

https://github.com/dotnet/roslyn/issues/10378

zpodlovics on 20 Jul 2016

👍3

I hope F# tooling support for .NET Core in Visual Studio should always depend on MSBuild project model.

Ive always hoped the opposite, msbuild and proj files have always been a Charlie Foxtrot.

7sharp9 on 20 Jul 2016

👍4 ❤2 😄1

@7sharp9

Why? I know it's been quite a mess but afaik large codebases in most enterprise apps (especially in my country) depends on it. Could you elaborate more on the reason why it's the opposite?

eriawan on 21 Jul 2016

@eriawan, I think it has a lot to do with the fact that the MSBuild language/files are xml-based. Complicated build scripts can get unwieldy fairly quickly, especially when they reference custom targets.

I agree though that sticking with MSBuild and the existing project file format was a good decision for the time being. The transition from a monolithic .NET Framework to a modular .NET Core was already pretty jarring. Additional tooling adds more novelty. Keeping the foundational build tools around will soften the landing a little bit, allowing F# devs to continue to use FAKE/Paket (once ported) without much interruption. Eg. as @forki pointed out per this comment: https://github.com/fsprojects/Paket/issues/1230#issuecomment-157324351, coupling between the project system and top level dependency management in the project.json format made Paket integration practically unworkable.

As much as we'd all like for MSBuild script to go away, it's critical that MS create an hospitable environment for existing .NET projects in .NET Core.

HoraceGonzalez on 21 Jul 2016

👍2

It's not about XML, XML is not perfect but file format in the end doesn't matter.

Krzysztof-Cieslak on 21 Jul 2016

Ive always hoped the opposite, msbuild and proj files have always been a Charlie Foxtrot.
...
I think it has a lot to do with the fact that the MSBuild language/files are xml-based. Complicated build scripts can get unwieldy fairly quickly, especially when they reference custom targets.
...
It's not about XML, XML is not perfect but file format in the end doesn't matter.

Not to further derail the thread, but I think you are both right. The problem is not that XML is a crappy textual _data_ format, which it is (because it is neither human-readable nor optimized for being processed by a machine), but that developers keep misusing _data_ formats for build scripts (e.g. MSBuild, Ant, Maven), weird declarative GUI specification languages with code integration where everything is expressed with string values (e.g. XAML with data bindings, events and animations), configuration files (e.g. Spring, Android App Manifest), databases and other mad ideas that should be expressed in a sufficiently expressive statically typed programming language that supports simple declarative DSLs (e.g. F#).

"My tenth rule of programming":

Any sufficiently complicated XML-based format contains an ad hoc informally-specified bug-ridden slow implementation of half of a proper declarative DSL.

21c-HK on 22 Jul 2016

👍4

For me msbuild is the same as the WCF mess. There are far too many issues from using that format. There are just too many things trying to fit into the project file, which should just be a list of files and dependent project, which may or may not need to be built.

If you look at other languages and platforms theres no where near as much peril involved. Take cargo in rust as an example, its a joy to work with. Take hex from Elixir, again a joy.

All Im saying is there are a better ways, we don't have to bath in the same water if we don't want to.

7sharp9 on 22 Jul 2016

👍4

Project files and solution setup (a jargon descending from Visual Studio) and their file format are not the most understood from newcommers.

I'm always advising newcommers to start with scripting in .fsx because it provides great experience starting from a single file, along with the ability to use paket generate-include-scripts command to make it easy to reference nuget packages in scripts, and the ability to load other .fs files, I think this makes a great introductory setup, which is easy to explain and based on simple human editable files (paket.dependencies and .fsx script files).

I've noticed the compiler is able to compile script files, I'm wondering if we shouldn't bake an option for the compiler to also copy the referenced assemblies in the output directory (I haven't found a way to do this).

If we had this, it is not so far stretched to see how a project.fsx could solve most of issues people are encountering when they don't have the "seasoned user of Visual Studio" background.

This could evolve into fs.project file which could be a DSL describing the build of a fsharp project.

smoothdeveloper on 22 Jul 2016

👍2

@smoothdeveloper I think this is a great idea! Imagine being able to use type providers that check the validity of file paths and other dependencies before executing a faulty build script.

21c-HK on 22 Jul 2016

@21c-HK I'm doing a bit of that already with FSharp.Management and FAKE to build visualfsharp repository: https://github.com/smoothdeveloper/buildvisualfsharp/blob/master/fakebuild.fsx#L102

smoothdeveloper on 22 Jul 2016

There are just too many things trying to fit into the project file, which should just be a list of files and dependent project, which may or may not need to be built.

Indeed, that's the biggest problem. In current project file we have - project definition, dependencies, build configuration, sometimes build scripts, VS configuration. Also because we basically have embedded programming language in fsproj it's (almost) impossible to parse this file without using MsBuild (what is really annoying from tooling point of view... cough... tooling different than VS)

As I've mentioned several times on Twitter, GitHub and my blog I'd be really happy if we could get new, lightweight project system for F#. And I strongly believe that it would drive F# adoption... especially it could bring more people from communities / ecosystems different than C#.

Krzysztof-Cieslak on 22 Jul 2016

👍6

Unfortunately this repository due to it's nature is probably worse place to discuss similar ideas, anyway ;)

Krzysztof-Cieslak on 22 Jul 2016

@Krzysztof-Cieslak I do sort of agree with that, or at least I know what you're saying. The Visual F# IDE Tools are constrained in certain ways - they will tend bias towards interop and consistency with the project file formats supported for other languages in Visual Studio , and are unlikely to lead the charge to a new format. But that's not saying it can't happen.

Of course if another project file format became widely popular in the F# ecosystem then it would be natural for the Visual F# IDE Tools to support it (at least if it could be done in a way that's fully compatible with other goals of those tools, and didn't intrude too much on long term engineering concerns for those tools) :)

dsyme on 23 Jul 2016

👍5

And this is the attitude that's been so refreshing about the F# community: let emergent technologies take their place while respecting the common/existing ecosystem.

HoraceGonzalez on 23 Jul 2016

👍1

Advertising F# as a viable scripting solution to powershell users is also something which tends to yield positive feedback, got few engaging discussions with IT Admin crowd about scripting and great tooling experience with Visual Studio or VSCode/ionide when things get more involved than few lines of code.

People don't know that F# has a REPL and that it support scripting out of the box.

1284 is a bit blocking though, also #1056.

smoothdeveloper on 28 Jul 2016

One direction I would like to see is for F# to stop being held back by the limitations of the CLR. CoreCLR, at least, supports unsafe casts, and even if one needs to stick to verifiable code one can just erase the advanced type system features and insert casts where needed. In other words, use CIL as a portable assembler and insert casts where needed. I suspect that most users of F# have no need for verifiable code (sandboxing in the CLR is basically dead).

DemiMarie on 5 Aug 2016

👍1

One other feature I would like to see in the F# compiler is functional-language related optimizations, such as ones related to lambdas and closures, as well as inlining. Ideally this would be the job of the CLR, but practically the CLR doesn't have the time to do it.

DemiMarie on 5 Aug 2016

👍2

F# syntax should be rethink from the ground up.. it's clearly bad

choosing
int * int => int instead of (int,int) > int
int => int => int instead of int > (int > int)

choosing <- instead of =

choosing
match obj with
"pattern1"..
"pattern2"..
instead of
"on obj
"pattern1"
"pattern2"

some to prove my point..

this kind of weird unreadable choice of syntax is seen all over the place in f#

i don't care what any functional geek will say, f# could be 100x better by cleaning up the syntax and rethinking all the naming and parts so that they are truly easily readable and writable.

even 'String to define a type of string isnt very readable..

sin8 on 2 Dec 2016

👎8 😕3

@DjSinae thanks, but no thanks

cloudRoutine on 2 Dec 2016

cloudroutine.. so for you int => int => int is more directly readable than (int,int) > int?

this is your code in your reactive ext wrapper

  type ObservableBuilder() =
        member __.Bind(m: IObservable<_>, f: _ -> IObservable<_>) = m.SelectMany(f)
        member __.Combine(comp1, comp2) = Observable.Concat(comp1, comp2)
        member __.Delay(f: _ -> IObservable<_>) = Observable.Defer(fun _ -> f())
        member __.Zero() = Observable.Empty(Scheduler.CurrentThread :> IScheduler)
        member __.For(sequence, body) = Observable.For(sequence, Func<_,_> body)
        member __.TryWith(m: IObservable<_>, h: #exn -> IObservable<_>) = Observable.Catch(m, h)
        member __.TryFinally(m, compensation) = Observable.Finally(m, Action compensation)
        member __.Using(res: #IDisposable, body) = Observable.Using((fun () -> res), Func<_,_> body)
        member __.While(guard, m: IObservable<_>) = Observable.While(Func<_> guard, m)
        member __.Yield(x) = Observable.Return(x, Scheduler.CurrentThread)
        member __.YieldFrom m : IObservable<_> = m
        [<Obsolete("Use Yield. Return will be removed in an upcoming version of FSharp.Control.Reactive.")>]
        member inline __.Return(x) = __.Yield(x)
        [<Obsolete("Use Yield. Return will be removed in an upcoming version of FSharp.Control.Reactive.")>]
        member inline __.ReturnFrom m = __.YieldFrom m

this me why this or something of the sort wouldnt be clearer?

  type ObservableBuilder() =
        .Bind(m: IObservable<>, f: x > IObservable<>) = m.SelectMany(f)
        .Combine(comp1, comp2) = Observable.Concat(comp1, comp2)
        .Delay(f: _ > IObservable<>) = Observable.Defer(_ > f())
        .Zero() = Observable.Empty(Scheduler.CurrentThread :> IScheduler)
        .For(sequence, body) = Observable.For(sequence, Func<_,_> body)
        .TryWith(m: IObservable<>, h: #e > IObservable<>) = Observable.Catch(m, h)
        .TryFinally(m, compensation) = Observable.Finally(m, Action compensation)
        .Using(res: #IDisposable, body) = Observable.Using(_ -> res, Func<,> body)
        .While(guard, m: IObservable<>) = Observable.While(Func<> guard, m)
        .Yield(x) = Observable.Return(x, Scheduler.CurrentThread)
        .YieldFrom m : IObservable<> = m
        [Obsolete("Use Yield. Return will be removed in an upcoming version of FSharp.Control.Reactive.")]
        inline _.Return(x) = _.Yield(x)
        [Obsolete("Use Yield. Return will be removed in an upcoming version of FSharp.Control.Reactive.")]
        inline _.ReturnFrom m = _.YieldFrom m

sin8 on 2 Dec 2016

in my opinion if they are use every 2 lines.. the "member", "let" and "fun" keyword are "noise" in the syntax..

the parser should be more intelligent and understand the context..

let dataString = 
        data 
        |> List.map (box>>string)
        |> List.toArray 
        |> String.concat ","

could be cleaner like

dataString = data  > map (box>>string) > toArray > concat ","

sin8 on 2 Dec 2016

@DjSinae computation expression builders have a specific syntax that they need to follow so this is a bad example (also it's not code that I wrote, try using git blame in the future 😜)

int -> int -> int means something fundamentally different from int * int -> int, you might want to familiarize yourself with currying/partial application and other foundational concepts of functional programming before deciding whether particular syntactic decisions in the language are good or not.

ML has been around just about as long as C, just because something is new to you doesn't mean that it's actually new.

btw - put code in your comments between " ``` " so it renders properly, proper markdown makes it nicer for everyone to read

cloudRoutine on 2 Dec 2016

look you clearly don't want to understand my point.. stay in you're f# bubble then..
i don't have time to loose

and sorry i fixed what i was saying so why choosing

int * int => int instead of (int, int) > int
int => int => int instead of int > (int > int)

all the doc is crippled with this ...
it would be 10x more understandable and readable the way i'm proposing.

sin8 on 2 Dec 2016

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.

forki on 2 Dec 2016

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..

sin8 on 2 Dec 2016

@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.

21c-HK on 2 Dec 2016

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 on 2 Dec 2016

😕1

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 on 2 Dec 2016

👎3 😕1

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 ="

sin8 on 2 Dec 2016

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)

baronfel on 2 Dec 2016

@DjSinae fslang-suggestions is the appropriate venue

cloudRoutine on 2 Dec 2016

👍3

@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!

cartermp on 2 Dec 2016

👍2

bah it's ok.. cya

sin8 on 2 Dec 2016

We seem to have hit mainstream with all this trolling.

7sharp9 on 3 Dec 2016

😄2 👍1

@7sharp9, mission accomplished?

HoraceGonzalez on 3 Dec 2016

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.

abelbraaksma on 4 Dec 2016

👍1

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.

bryanedds on 4 Dec 2016

👍2

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.

s-trooper on 4 Dec 2016

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...

lambdakris on 4 Dec 2016

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.

bryanedds on 4 Dec 2016

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).

abelbraaksma on 4 Dec 2016

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.

21c-HK on 4 Dec 2016

@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.

cartermp on 4 Dec 2016

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.

bryanedds on 4 Dec 2016

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.

21c-HK on 4 Dec 2016

@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.

cartermp on 4 Dec 2016

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.

21c-HK on 4 Dec 2016

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.

cartermp on 5 Dec 2016

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.

jeroldhaas on 5 Dec 2016

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)_.

abelbraaksma on 5 Dec 2016

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.

21c-HK on 6 Dec 2016

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

dsyme on 6 Dec 2016

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

21c-HK on 6 Dec 2016

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.

gulshan on 20 Dec 2016

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
.

jeroldhaas on 20 Dec 2016

@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.

cartermp on 20 Dec 2016

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.

GiorgioG on 16 Jan 2017

👍3

"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.

abelbraaksma on 17 Jan 2017

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.)

GiorgioG on 17 Jan 2017

@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.

smoothdeveloper on 17 Jan 2017

@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.

GiorgioG on 17 Jan 2017

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.

smoothdeveloper on 17 Jan 2017

@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.

GiorgioG on 17 Jan 2017

@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.

21c-HK on 17 Jan 2017

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#

...

smoothdeveloper on 17 Jan 2017

How to advertise F#?

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

GiorgioG on 17 Jan 2017

👍2

Simplify your code. Simplify your life. F#.

bryanedds on 17 Jan 2017

❤1 👍1

Make programming great again! By using F#.

21c-HK on 17 Jan 2017

😄3 ❤1

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#"

gulshan on 10 Feb 2017

Three projects. Zero bugs. How? F#.

Or, just slightly more verbose:

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

rmunn on 20 Feb 2017

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.

gregoryyoung on 20 Feb 2017

👍1

@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.

forki on 20 Feb 2017

@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.

gregoryyoung on 20 Feb 2017

@gregoryyoung We use FAKE scripts in almost all builds but it results that from 20 devs it is only me who changes something there. Max what the others want to do is to comment out the Test target. SAD!

alexeyzimarev on 22 Feb 2017

@alexeyzimarev that is also happening if you use a different technology. People often tend to say "it's not my responsibility to get that working" and just leave it. I think it's more a problem with how the people in a team organize than with technology.

forki on 22 Feb 2017

Regarding F# project files, would it be possible to create an F# project format which gets translated to .fsproj using FAKE which then gets built using MSBuild?

bklaric on 25 Mar 2017

👍1

Yes it is possible ;]

VS support is a problem.... as always

Krzysztof-Cieslak on 25 Mar 2017

I like the idea of having a F# DSL (or data structure) to describe the project structure of an F# project.
Clojure (leiningen) for example uses a project file written in Clojure (S-expressions) for defining the project structure.

We can even do better by incorporating F# type providers into the project definition process, for example to use a file type provider to get IntelliSense for file paths.

@Krzysztof-Cieslak has a blog post with some ideas of how a custom project file could look like "Creating custom project file for F#" in case someone missed it.

toburger on 27 Mar 2017

The problem with custom project system is always tooling. We can't even get
the MSBuild ones working properly...

Am 27.03.2017 10:39 vorm. schrieb "Tobias Burger" <[email protected]

:

I like the idea of having a F# DSL (or data structure) to describe the
project structure of an F# project.
Clojure (leiningen) for example uses a project file written in Clojure
(S-expressions) for defining the project structure
https://github.com/technomancy/leiningen/blob/stable/sample.project.clj.

We can even do better by incorporating F# type providers into the project
definition process, for example to use a file type provider to get
IntelliSense for file paths.

@Krzysztof-Cieslak https://github.com/Krzysztof-Cieslak has a blog post
with some ideas of how a custom project file could look like "Creating
custom project file for F#"
http://kcieslak.io/Creating-custom-project-file-for-F in case someone
missed it.

—
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-289389506,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNADYi-JIiorH4Y8miHVTnaaDwYJOks5rp3W0gaJpZM4JJuVb
.

forki on 27 Mar 2017

Yes tooling is a big concern! But I think it depends from where the project gets created.

If someone creates a project from Visual Studio then he expects good tooling for project files from the VS side.
When creating a project from the command line msbuild is a hassle. Even with the new .NET Core .fsproj file.

Creating a (dynamic) .fsproj file from the DSL should be possible (so any msbuild-compatible system is able to compile the code). Updating the DSL file from the msbuild world is the hard part.

PS: this is my 10000 (or better 10_000 ;) ) foot view from an outsider not knowing very much of all the work behind getting F# to work with msbuild. I admire the work everyone from the F# community did to get F# to where it is today!

toburger on 27 Mar 2017

I think current project and build system is really huge problem for anyone trying out F# who was not C# dev before (https://www.reddit.com/r/programming/comments/61kt36/functional_programming_design_patterns_by_scott/dffbida/) - personally, I don't know anyone who was non .Net dev and understood MsBuild right away, and felt it was user friendly, easy to use etc.

The problem with custom project system is always tooling.

I'd argue about it. Most tooling shouldn't be problematic, anything that depends on FCS would support new project without any problem. I had proof of concept with Paket integrated into project system so dependencies management wouldn't be a problem. The only problem are XS and VS since they depend on understanding project files... and last time I've checked XS project system extension point was decent enough.

Also, I believe that it would be possible to add VS support too - R tools for VS, and Python tools for VS supports own project files by providing micro MsBuild-like file and resolving all information in memory. AFAIK, TypeScript does something similar but VS integration is not OSS.

Example rxproj:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="14.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup Label="Globals">
    <ProjectGuid>8128d848-4b00-4036-8547-7344e5148a7d</ProjectGuid>
  </PropertyGroup>
  <PropertyGroup>
    <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">14.0</VisualStudioVersion>
    <Configuration Condition="'$(Configuration)' == ''">Debug</Configuration>
    <Platform Condition="'$(Platform)' == ''">AnyCPU</Platform>
  </PropertyGroup>
  <ProjectExtensions>
    <VisualStudio>
      <UserProperties />
    </VisualStudio>
  </ProjectExtensions>
  <Import Project="$(MSBuildUserExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\RTVS\Rules\rtvs.rules.props" Condition="Exists('$(MSBuildUserExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\RTVS\Rules\rtvs.rules.props')" />
  <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\RTVS\Rules\rtvs.rules.props" Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\RTVS\Rules\rtvs.rules.props') And !Exists('$(MSBuildUserExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\RTVS\Rules\rtvs.rules.props')" />
  <Import Project="Examples.InMemory.Targets" Condition="Exists('Examples.InMemory.Targets')" />
</Project>

Example rproj:

Version: 1.0

RestoreWorkspace: Default
SaveWorkspace: Default
AlwaysSaveHistory: Default

EnableCodeIndexing: Yes
UseSpacesForTab: Yes
NumSpacesForTab: 2
Encoding: UTF-8

RnwWeave: Sweave
LaTeX: pdfLaTeX

Not only properties are resolved in-memory based on other project file, but also files which are displayed in project explorer are found automatically (which couldn't happen in case of F#, but at least shows that there are ways to hack into VS project system to support something better).

I had pretty decent proof-of-concept doing:

transformation of new project file into fsproj (old) [TBF, it would be much simpler if it was targeting new fsproj]
calculating fsc arguments (which is enough to directly compile project and provide any tooling using FCS)

but since I'm not brave enough to annoy MSFT even more it's kinda stale.

On the other hand there are some drawbacks - MsBuild is SUPER complex. I mean, even MSFT failed to replace it with lot of resources put into it (project.json fiasco). So it's pretty unrealistic to expect that any new project file will provide same functionalities natievly as MsBuild.
The assumption behind my proof of concept was to support most commonly used things (which covers majority of users) and then provide really good transformation into fsproj - if someone wants more advanced features (let's say custom tasks, Xamarin magic etc) would have ability to move to full blown fsproj without any problem.

I like the idea of having a F# DSL (or data structure) to describe the project structure of an F# project.

Personally I don't like this idea - we change something that it's hard to parse, that only one tool is able to interpret well (MsBuild) into something that would be hard to parse and only one tool is able to interpret well (F# compiler). Also using TPs etc would mean that tooling is required to make changes in project file, which is not something I'd like to see. Paket proves how well simple, notepad-editable file formats work.

Instead I'd prefer highly declarative project file removing all "moving" parts (custom tasks, custom conditional syntax and variable assignment we have in MsBuild) in TOML or YAML that can be easily parsed using any TOML/YAML parser in any language.

FsToml sample:

FsTomlVersion   = '0.0.1'
Name            = 'FantasticApp'
Guid            = 'bb0c6f01-5e57-4575-a498-5de850d9fa6c'
OutputType      = 'Exe'
FSharpCore      = '4.4.0.0'


Files = [
    { Compile = "src/file.fs" },
    { Compile = "src/file2.fs", Link = "src/uselessLink.fs" },
    { Compile = "src/file3.fs", Sig = "src/file3.fsi" },
    { None    = "src/script.fsx", Private = true },
]

References = [
    { Framework = "System" },
    { Framework = "FSharp.Core" },
    { Project   = "Deppy.fstoml" },
    { Library   = "lib/Fable.Core.dll", Private = true },
    { Package   = "Nett" }
]

DebugSymbols = true
DebugType = 'full'
Optimize = false
NoWarn = [52, 40]
OtherFlags = [ '--warnon:1182' ]

[ net ]
   DebugSymbols = false

[ net.Release ]
    Constants = [ 'RELEASE', 'FABLE' ]
    DebugType = 'pdbonly'
    Optimize = true

[ net."4_5".Release.x86 ]
    OutputPath = "bin/Release/x86"

[ net."4_5".Release.x64 ]
    OutputPath = "bin/Release/x64"

This is probably still too verbose and could be shrinked using good defaults.

Custom project, custom CLI tool, good migration path both ways and our live would be much better. Unfortunately looks like there is not enough interest in something like that to make it happen...

Also, to quote myself from this thread, couple of months ago: "Unfortunately this repository due to it's nature is probably worse place to discuss similar ideas, anyway ;)"

Krzysztof-Cieslak on 27 Mar 2017

👍9

Edit: corrected typos.

We had a similar discussion earlier in this thread. I will repost a few relevant quotes at the end of this comment for convenience.

@Krzysztof-Cieslak

Indeed, that's the biggest problem. In current project file we have - project definition, dependencies, build configuration, sometimes build scripts, VS configuration. Also because we basically have embedded programming language in fsproj it's (almost) impossible to parse this file without using MsBuild (what is really annoying from tooling point of view... cough... tooling different than VS)

You hit it on the nail! I think it's always best to separate things that can be separated. Each of these concerns should be a separate file - each possibly consumed/produced by separate tools - and not all files necessarily have to - but could - share the same format. In any case, there should be at _most_ 2 different languages: Static/simple/machine independent/configuration-like information _should_/_could_ be in a dedicated _configuration_ format like TOML (as opposed to textual _data_ formats like XML, JSON, YAML, etc.) and dynamic/complex/machine dependent/reusable/moving parts _must_ be in a statically typed DSL like F# (as opposed to the insane idea of misusing data formats for that like MSBuild, Ant, Maven).

The popular build scripts (MSBuild, Ant, Maven) are like CSS: It sucks so much that it makes me feel ashamed that it is still being used today by people who share the same profession. Then some people put an abstraction on top of it like LESS or SASS to make it suck less (comparable to tools that make MSBuild or C# suck less). The simplicity, restrictiveness and independence of dedicated _configuration_ formats like TOML has obvious advantages, but a DSL - always being able to represent configuration information - can represent everything that a configuration format can. I am still undecided what would be the best exactly, but the following could be the basis for a separate discussion (@all: which repository would be the best place for that discussion, so that I or some one else could create an issue there for further discussion?):

| concern | format | language|
|----------|---------|-----------|
| project definition | configuration format | TOML |
| dependencies | configuration format | Paket "language" or TOML |
| build configuration | configuration format | TOML |
| IDE configuration | configuration format | TOML or whatever that IDE is using|
| build script | simple declarative DSL | F# |

The information in all of these files could then be merged into MSBuild or other legacy formats for backwards-compatibility.

@toburger

I like the idea of having a F# DSL (or data structure) to describe the project structure of an F# project.
Clojure (leiningen) for example uses a project file written in Clojure (S-expressions) for defining the project structure.

We can even do better by incorporating F# type providers into the project definition process, for example to use a file type provider to get IntelliSense for file paths.

This is why I am on the fence on this issue since I also like the idea of using F# type providers for checking the validity of files and dependencies before the build can even be run. I just don't know if the added complexity is worth it compared to a simple configuration format and checks performed by external tooling though. We need to weigh the pros/cons.

@Krzysztof-Cieslak

Personally I don't like this idea - we change something that it's hard to parse, that only one tool is able to interpret well (MsBuild) into something that would be hard to parse and only one tool is able to interpret well (F# compiler). Also using TPs etc would mean that tooling is required to make changes in project file, which is not something I'd like to see. Paket proves how well simple, notepad-editable file formats work.

Agreeing with you in principle, I just want to point out that requiring tooling like basic F# tools - that you use anyway - is not necessarily a bad thing. It's like using Notepad as your editor: While Notepad might be okay for simple dynamic languages (i.e. still not a good idea), you give up most of the benefits of having a (proper) statically typed language like F#.

Quotes from earlier discussion:

@7sharp9

For me msbuild is the same as the WCF mess. There are far too many issues from using that format. There are just too many things trying to fit into the project file, which should just be a list of files and dependent project, which may or may not need to be built.

If you look at other languages and platforms theres no where near as much peril involved. Take cargo in rust as an example, its a joy to work with. Take hex from Elixir, again a joy.

@21c-HK (me)

Imagine being able to use type providers that check the validity of file paths and other dependencies before executing a faulty build script.

@21c-HK (me)

The problem is not that XML is a crappy textual _data_ format, which it is (because it is neither human-readable nor optimized for being processed by a machine), but that developers keep misusing _data_ formats for build scripts (e.g. MSBuild, Ant, Maven), weird declarative GUI specification languages with code integration where everything is expressed with string values (e.g. XAML with data bindings, events and animations), configuration files (e.g. Spring, Android App Manifest), databases and other mad ideas that should be expressed in a sufficiently expressive statically typed programming language that supports simple declarative DSLs (e.g. F#).

21c-HK on 27 Mar 2017

👍1

@Krzysztof-Cieslak

Custom project, custom CLI tool, good migration path both ways and our live would be much better. Unfortunately looks like there is not enough interest in something like that to make it happen...

Also, to quote myself from this thread, couple of months ago: "Unfortunately this repository due to it's nature is probably worse place to discuss similar ideas, anyway ;)"

I think there is a lot of interest for core issues like these even if it is not necessarily visible. Feedback/involvement like yours is much appreciated by passionate F# developers like me and raise awareness for issues that hold back F# adoption. And this is ultimately why I wanted to continue the discussion of F# adoption in this thread. I don't know if I can take even a little bit of credit for raising awareness, but since making the statement in the beginning of this thread that I thought that VS Code with ionide was better than Visual Studio with VFT for most projects, then some people disagreeing with my statement, and me then posting my wish list for an ideal F# IDE, VS Code with ionide has improved so much that it even supports most of my wish list, so that I am even more confident today to repeat that statement. The same might happen with the project/configuration/build system of F# if we keep raising awareness.

P.S.: Every F# developer should really check out VS Code with ionide again today! I can really recommend it for most F# projects. I would also like to give a huge thanks to Ionide maintainers like @cloudRoutine. Your effort is much appreciated and adds tremendous value to the F# community!

21c-HK on 27 Mar 2017

👍1

Each of these concerns should be a separate file - each possibly consumed/produced by separate tools - and not all files necessarily have to - but could - share the same format.
....

I think going to so many separate files is moving to another extreme. I think having project definition, and package definition in one file is OK... maybe even build configurations as long as it's static (i.e. doesn't contain custom programming language to manage like MsBuild with its conditionals and variable assignments). The biggest issue for me are dynamic parts of MsBuild - conditionals, variables, tasks. Conditionals and variables can be replaced with static declarative syntax (as vast majority of people always use same conditions, same targets etc). And for build script / tasks we have FAKE which is really good at what it does.

Anyway... we could just copy Rust's Cargo without thinking at all and situation would be better than what we have right now.

Feedback/involvement like yours is much appreciated by passionate F# developers like me and raise awareness for issues that hold back F# adoption.

Great that my feedback helps just a bit ;]
Glad this discussion is moving forward and helping F# community!

Something something VSCode something

Nah, Ionide is not better than VS... One could argue about VS2015 without VFPT, but definitely not with VFPT, nor VS2017 Nightly build.
But yeah, huge thanks to @cloudRoutine and other Ionide maintainers ;]

Krzysztof-Cieslak on 27 Mar 2017

😄1 👍1

I don't really think that the .NET approach for projects and builds are hampering adoption much. It's an easy whipping boy which isn't the root of various issues with F#. The link @Krzysztof-Cieslak pulled up:

(a) Lacks the detail to be actionable
(b) At face value, demonstrates a lack of comfort with compiled languages in general

If there's any truth to the latter, F# won't be picking up programmers from that camp.

I think that under the umbrella of getting started, F# has these problems:

It's a functional programming language. People learn Java, Python, C, and JS in school. The Java takeover of universities has been probably the most successful thing in the history of Java. We're still dealing with that today. Although universities are slowly standardizing their curricula to include compilers and functional programming, CS is still a young field in education and standards aren't widespread. This is the biggest hamper on adoption for F# moving forward.
No standardized CLI toolset for F# yet. Related problem: there's also no agreement on what "standardized CLI toolset for F#" means among the F# community. Multiple competing interests. The .NET CLI may eventually be the answer, but it's too young and hasn't even been pushed by Microsoft all that hard yet. I think it's better than anything which depends on Mono because Mono is too large.
No agreed-upon best library or framework for building a dead-easy web API or web page. Suave looks like it's the closest here, though. I think we're actually pretty close to having mindshare around Suave, and I've certainly been a part of that by suggesting it officially on Microsoft videos. I plan on doing more here.
Analogous to (3), No dead-simple way to start with iOS, Android, or Web frontend development. I think Xamarin tooling has come a long way and we're a few templates away from having roughly the same story as C#. VS for Mac is actually a great experience. FABLE looks to be the community-approved answer for web apps. I'm excited to see this flesh out more when 1.0 is stable.
No easy way to compile into a single, native binary. Though this isn't really about getting started, it's important. In the case of a language like Golang, it definitively answers the question of "what happens with I build a real application"? We're not really alone here. Any competing functional language on the JVM shares a similar problem.
In-box VS IDE experience lacks templates and is still catching up to C# in terms of IDE features. We're actually much further along now than ever, and the pace of IDE features in VS has been astounding. Don't be surprised if we're seen as leading in the IDE space pretty soon. We tend to underestimate the number of developers using Windows and Visual Studio. Let's not lose sight of the fact that this is a gargantuan population of people. Templates also matter a lot here, because wiring things up when a designer doesn't "natively" understand F# is not that nice. This isn't a very difficult problem to solve, which is good!
In-box VSCode experience is still complex. It pushes multiple F# OSS concepts on someone at once: FAKE and Paket. Though these are tools people should probably use, they're not ideal for someone who is just dipping their toes into F# and .NET. Paket will inevitably confuse people with the need to track stuff in multiple files, and it's easy to end up restoring packages without actually having the package installed so you can reference it. This isn't an Ionide problem, but it's one that Ionide inherits by virtue of using Paket.

Let's not let my above list discourage us, though.

The VS IDE experience is absolutely kickass with the nightlies and when we insert into a forthcoming update it will be impressive. I'm super excited about this.
VSCode is absolutely kickass. Nearly everyone, after they get over a bit of a concept hump, loves it. I demo it to people all the time.
.NET CLI "just works" for F#. FSI support here will complete the picture.
VS for Mac is fantastic. Some issues with completion, and I've run into a bug building an iOS app, but overall it's really amazing getting such a powerful IDE on the mac. This will attract people.
Suave is kickass. It has a very good "cool" factor that's nearly impossible to quantify, but somehow materializes.
FABLE is the kind of thing that makes peoples' eyes open wide. Really excited for 1.0 here.
The language is great. It looks good, people love using it, and it's stable (modulo bugs, which every compiler on earth has).
F# as a whole has a demonstrated "cool" factor that we've seen in user studies. Similar to Suave, we're not sure how, but it passes the "cool" test. ¯_(ツ)_/¯
F# is a natural attractor to people who use C#, love LINQ, and want more. Cannibalizing C# isn't the only way for F# to grow, but it's a natural one which attaches itself to growth vehicle. There's room for growing awareness in C# developers, keeping them happy on .NET because they _get_ to use a cool language like F# on it. We shouldn't ignore this.
Almost every objective measure of growth we have shows F# as growing _at least_ proportionally to that of C#. It's also getting good press through Redmonk, Infoworld, StackOverflow Surveys (yes, it dropped in some places from last year), and Microsoft itself. I just finished a video showing off VS IDE tools and building a dead simple suave app.

A lot of what I consider to be problem areas can't be fixed immediately. I think templates for VS and VS for Mac are an easy win, though. We lose out on C# developers trying out F# because all they see are Console Application and Class Library. I also think we should try to get a Suave template in there. I'll certainly approve the pull request and merge it into the repo.

cartermp on 27 Mar 2017

I don't really think that the .NET approach for projects and builds are hampering adoption much. It's an easy whipping boy which isn't the root of various issues with F#.

I don't think I agree, given projects I'm working on I'm often contacted by people struggling with MsBuild. From my anecdotal experience getting started UX is pretty bad [unless someone is committed to MSFT tooling - VS / XS which for various reason is often a problem for people who don't have .Net background]). I've seen same reactions on various non-.Net conferences, or in my consulting work. Maybe I'm just unlucky and meet / talk / work with "wrong" people.

And yes, maybe dotnet cli will make it better... maybe.

It's a functional programming language. People learn Java, Python, C, and JS in school. The Java takeover of universities has been probably the most successful thing in the history of Java. We're still dealing with that today. Although universities are slowly standardizing their curricula to include compilers and functional programming, CS is still a young field in education and standards aren't widespread. This is the biggest hamper on adoption for F# moving forward.

Yeah, in comparison to C#, JS, TS... doesn't explain why languages like Elixir are getting more popular / more hype faster than we're getting (obviously such comparison would be easier if you released those super secret usage numbers ;) ). And blaming something that we can't change is not productive anyway.

No standardized CLI toolset for F# yet. Related problem: there's also no agreement on what "standardized CLI toolset for F#" means among the F# community. Multiple competing interests. The .NET CLI may eventually be the answer, but it's too young and hasn't even been pushed by Microsoft all that hard yet. I think it's better than anything which depends on Mono because Mono is too large.

I don't think it will be solved with dotnet cli... But anyway... again, due to the nature of this repository, dotnet cli is official response for the problem ;)

3/4

I think we won't ever has one-go-to-choice for those problems due to Community vs MSFT dichotomy... and yes, You're doing great job promoting community based solutions, but Suave will never get as much marketing as ASP.Net, Fable will never get as much marketing as TypeScript and Xamarin... and I think at this point it's pretty clear which solutions are preferred by community ;)

In-box VSCode experience is still complex. It pushes multiple F# OSS concepts on someone at once: FAKE and Paket. Though these are tools people should probably use, they're not ideal for someone who is just dipping their toes into F# and .NET. Paket will inevitably confuse people with the need to track stuff in multiple files, and it's easy to end up restoring packages without actually having the package installed so you can reference it. This isn't an Ionide problem, but it's one that Ionide inherits by virtue of using Paket.

Wouldn't agree with FAKE - it's totally optional, one can use either VSCode tasks or set of MsBuild commands that Ionide provides out of the box.

Paket on the other hand - Ionide goes with it because out of the box .Net alternative is so bad that suggesting it to anyone should be felony. And which could be solved with better project file, that Paket can either be part of (merging paket.references and project file) or provide much easier integration path... Also, again, from my anecdotal experience Paket is not a problem, and is pretty easy for new people.

Templates

Obviously, more templates have no drawback.... other than

pushing people into MSFT technologies (as no one will convince me that we will get official Suave template out-of-the-box, and we will get ASP.Net one)
Is solving a problem only for C# developers coming to F# through VS ... while what I'm talking is focusing mostly on non .Net people (so orthogonal problem... but yeah, not this repo ;) )

Almost every objective measure of growth we have shows F# as growing at least proportionally to that of C#.

Growth of absolute numbers of developers is nothing surprising given how crazy is growing number of developers jobs in general.... even super stagnant C# community is starting to notice that something is wrong (new "alt-.Net" etc)

Summing up, I think we have 2 different problems - adoption from C# -> F#, and adoption from outside of .Net world. And if most users of F# are VS, Windows, ex-C# devs that actually indicates huge problem that should be solved and (almost) no one is trying to solve. Which is super weird as I'd think that developers outside of .Net should be more important target for MSFT F# marketing (as those are new users for .Net platform, MSFT gains nothing when someone moves from C# to F#)

Fable kickass, Ionide kickass, Suave kickass....

I wonder how sustainable it is given that all those projects have 1-2 overproducing maintainers doing all work on their free time. Doesn't sound like a best strategy for developing ecosystem.

Krzysztof-Cieslak on 27 Mar 2017

👍1

This is a minimal F# wrapper over asp.net core-
https://github.com/dustinmoris/Giraffe

gulshan on 27 Mar 2017

Not to beat a dead horse (again,) but F# being a second class citizen in VS releases definitely makes driving adoption much harder. Right now many people want to start using .NET Core (and the latest VS release of course.) That usually means folks will be creating new projects given that .NET Core and legacy .NET Framework projects don't play nice...and what better excuse to give people a reason to start using F# than greenfield projects?

VS Code is nice and all, but it's not Visual Studio.

GiorgioG on 27 Mar 2017

Thankfully its not Visual Studio.
We have a whole cornucopia of option, vscode, sublime, emacs, visual studio, and xamarin studio. Lets not get sidetracked by a development environment choice, F# is not a windows only product.

7sharp9 on 27 Mar 2017

@7sharp9 I absolutely agree that F# is not a Windows-only product and for non-Windows users, they can absolutely use VS for Mac/VSCode/etc and if part of the goal is to drive adoption significantly higher, targeting the large number of existing developers who already invested in VS / .NET might be give us the biggest bang for our buck.

GiorgioG on 27 Mar 2017

People are complaining about .fsproj files/msbuild on conferences: https://youtu.be/JgWQPPnKWZU?t=10m23s. I don't think it is that bad of a situation to decide against F#, but I can understand his complaints.

toburger on 27 Mar 2017

@cartermp I'm probably in the minority, but the old .fsproj file was a big impediment to me. I'm on Linux, and I'm not using VS or VSCode, so I have to hand-edit the .fsproj file.

I don't like clicking buttons in fancy IDEs either, I prefer to actually understand how the files work. And the documentation I found for .fsproj is atrociously bad, probably because it's assumed that everybody is using VS/VSCode.

Popular and hip languages (such as JavaScript, Ruby, and Python) have nice, simple, easy-to-understand, and easy-to-edit configuration files. Even static languages like Rust and Haskell have better configuration than F#. This is a big win for people who are new to your language.

The new .fsproj file is great though, and I think it will help with adoption.

I'm sure the rest of your points are also big problems (which should definitely be dealt with), I just disagree that the old .fsproj wasn't a problem.

Pauan on 28 Mar 2017

@toburger @Pauan To be clear: I'm not saying that .fsproj isn't an issue. I'm saying that in terms of adoption, I don't think that it's a big factor. That's a downlevel concern. I'm not particularly concerned about that, especially since there's already a clear path forward with MSBuild 15-based project files. I'm interested in the answers to questions which come before someone is concerned with day-to-day work in project configuration.

There isn't what I would consider to be very strong mindshare around things like building a simple web service, for example, which is increasingly becoming the "hello world" in many circles. I think we're making huge improvements, here, though. F# Software Foundation is also growing, as is activity in the FSSF slack, where things like Ionide + Suave are recommended for folks not interested in an IDE. This is something to build off of.

@Krzysztof-Cieslak

Yeah, in comparison to C#, JS, TS... doesn't explain why languages like Elixir are getting more popular / more hype faster than we're getting (obviously such comparison would be easier if you released those super secret usage numbers ;) ). And blaming something that we can't change is not productive anyway.

Hype doesn't necessarily translate to active developers. Neither does Google trends. Languages with an affinity to one set of systems may be completely irrelevant in other markets where another language has affinity. This doesn't mean some other language is doing better or worse, for some definition of better or worse, than F#. I think we're all competing over roughly the same (small) order of magnitude of developers, save for Scala, which has been successful largely because Java became absolutely stagnant for half a decade.

I'm not blaming education. I'm simply stating a reality: the biggest problem with adoption for F# is that it's a functional programming language, and functional programming languages are not taught in school. I say this because perspective matters here. School is where the largest group of soon-to-be paid professionals, open source developers, and thought leaders come from. The funnel for F# adoption, as with other FP languages, does not have a high amount of students in it. That's the largest hamper on adoption bar-none. Perhaps the greater FP community ought to take this more seriously. We're tied to it.

Also, again, from my anecdotal experience Paket is not a problem, and is pretty easy for new people.

I've also seen precisely the opposite experience: people doing just fine with dotnet restore in the C# extension, but struggling with Paket. But this isn't a conversation about package managers. Package managers seem to come with strong opinions. ¯\_(ツ)_/¯. My point is that there's extra conceptual stuff which comes with a basic Ionide project. This may not be actionable, especially since you can ignore most files and just write some code.

I'd think that developers outside of .Net should be more important target for MSFT F# marketing (as those are new users for .Net platform, MSFT gains nothing when someone moves from C# to F#)

This is actually not true at all. Microsoft has _a lot_ to gain when someone moves from C# to F#. It's usually a strong sign of satisfaction and happiness, and is associated that way. Keeping people happy (or stopping the bleeding, depending on your point of view) is crucial to Microsoft business interests.

This is both a blessing and a curse for F#. Appealing to existing .NET developers and non-.NET developers necessitates a breadth of tools and a simple grow-up story across the spectrum of tooling people prefer. That's a bunch of words which means: quantity and quality matter. We're very much on our way there, especially as .NET Core and its associated tooling is materializing into something stable which runs everywhere. Unsurprisingly, much of what the existing .NET community had been asking for (compat with existing code, better project files, larger API set with no breaking changes) aligns with what non-.NET developers care about as well.

cartermp on 28 Mar 2017

👍3

I've also seen precisely the opposite experience: people doing just fine with dotnet restore in the C# extension, but struggling with Paket.

Probably Microsoft employees. It's 2017 and they still use "restore" for a resolution call ;-)
(and it's really weird since you use exactly the same dotnet restore to do a actual "restore" in paket.)

forki on 28 Mar 2017

@cartermp honestly. Look at cargo. Look how really good project file + package manager integration works. "paket will confuse people that just come to .NET " - that's really really bad thinking especially since most other platforms have a package manager that works similarly. Nuget is the odd thing. It really is. Having still no lock file is what people let themselves shoot in the foot.
I never claimed paket should be the package manager that comes ootb, but I really really hoped ms would finally understand the danger it brings with nuget. But instead it's switching product managers every year and so noone can make an impact. I admit that the PackageReferences stuff made things much easier to get started but boy that stuff will make builds break A LOT. If you don't believe me than work a while with npm and after many many tears you will understand why yarn was made.
Tbf one advantage of yarn is that it is a drop in replacement. We couldn't do that with packages.config for very good reasons - we might converge now.

forki on 28 Mar 2017

👍5

@forki I enjoyed FAKE and understood the value of Paket, but overall VS packaging solution became easier (less boilerplate and additional dependencies and mental overhead) since project.json, and since VS2017 it is kind of joy (relative to all the pain before with .NET Core, now references to/from Core and NET45 projects "just work"). And NuGet started to work as it always should have been - fast and without version resolution problems. This all applies to F# as well - I could create a .NET45 F# project in VS2017 and have all the tooling, but a separate .fsproj file in .NET Core format and a build script that builds & packs projects using dotnet cli. Support for .NET Core F# projects from VS2017 is the last step to have a truly awesome tooling/build/packaging infrastructure out of the box.

buybackoff on 28 Mar 2017

Coming back to the original topic. MSBuild (even 15 and PackageReferences) is a real problem for adoption. If discuss this away then you obviously never spend time in the fable gitter chat. A lot of the people come from Javascript ecosystem. They are not scared by F# or functional programming because we mainly show super simple + super effective elmish architecture. But they are indeed scared by our project files. That's a real problem compared to let's say elm itself. We also don't hear much complaints about package managers, that are not npm.

forki on 28 Mar 2017

👍4

without version resolution problems.

No it doesn't. You just not noticed it yet.

forki on 28 Mar 2017

👍4

People going from Ruby to Elixir are not scared of FP, people going from JS to Elm are not scared of FP. Personally I believe that "blaming FP" is just excuse... and what's more important, many other communities stopped using it, and instead they are doing right things to make developers live easier.

For last 5 years it was "Nuget is OK because it's better than old dll hell" . Now it is "dotnet restore is OK because it's better then old NuGet" and "new fsproj is better than old fsproj". All those statements are true... they're just missing part where you mention that we compare terrible thing with slightly less terrible thing. While (most) other ecosystems already solved this problem much better.

IF we agree with this dominating here "Yeah F# is xplat, people can use those wierd hippy things like VSCode but Windows and VS are what really matters" view of the F# world than yes, be happy with new fsproj, Nuget and dotnet cli. And telling that stats show vast majority of F# devs are Windows, VS, ex-C# devs is not proving this world view. It's just another symptom showing what's wrong with our ecosystem. But I guess we should be happy with being MSFT dependent poor cousin of C#.

Anyway, I guess due to different experinaces and point of views on the issues we should agree to disagree ¯\(ツ)/¯

Krzysztof-Cieslak on 28 Mar 2017

👍2

The last few posts (especially by @forki and @Krzysztof-Cieslak) is exactly why this thread/discussion is so important. Microsoft employees may have a certain view of the state of things - and while the participants in this thread may not be representative of the F# community at large - the disagreement in the last few posts shows that the F# OSS may have a different view of the state of things. Neither is necessarily right or wrong, but it's valuable to find out where the issues/truth may lie.

@cartermp

I don't really think that the .NET approach for projects and builds are hampering adoption much. It's an easy whipping boy which isn't the root of various issues with F#.

I also have to disagree with that statement. Maybe "adoption" means something else to you, but for me adoption means that people try a technology and then decide to stick with it. I was literally forced to switch from NuGet to Paket, because the "stable" NuGet was so incredibly buggy and no amount of updates over a time span of a year did improve it. From the second that I learned Paket and switched to Paket, I had no problems ever again! Microsoft's problem has always been "Check out this 5 min demo video. Isn't cool how quickly you can solve this particular (staged) problem with our solution (that is only really good for that particular problem)?" And then you try something else, more complex, or more general with that technology and you start pulling your hairs out. C# async, ASP.NET, WCF, WPF, XAML, WinRT, MSBuild and NuGet are just a few examples from the top of my head.

@cartermp

In-box VSCode experience is still complex. It pushes multiple F# OSS concepts on someone at once: FAKE and Paket.

I really don't understand this statement. These are not F# OSS concepts, but fundamental concepts of software development called "build tool" and "dependency manager" that any professional developer should be familiar with before even starting a project. The only difference between FAKE and MSBuild, or Paket and NuGet, is that FAKE and Paket actually work every time that I used it (so that I can focus on programming) and MSBuild and NuGet make me lose respect for Microsoft every time I use it. It's actually just bad marketing for Microsoft, because a lot of other things that Microsoft does are really great (e.g. F#, .NET, VS editions, etc.).

21c-HK on 28 Mar 2017

👍2

@Krzysztof-Cieslak I agree with that we seem to content ourselves with incremental improvements to a crappy set of existing conditions (let's not sugar-coat it, csproj/fsproj/NuGet suck.) Incremental improvements will not move the adoption needle.

"Yeah F# is xplat, people can use those wierd hippy things like VSCode but Windows and VS are what really matters"

I don't think that's meant to slight non-Windows / VS users (or potential users.) Existing VS users simply provide a lower barrier to adoption than say your typical non-Windows developer who at minimum is suspicious of using anything from the "evil Microsoft empire." Furthermore, the impression is (like it or not) that F# is not a first-class citizen in the VS/.NET world. Unless Microsoft corrects that idea, they won't even get existing .NET developers onboard with F#. I can't even create an ASP.NET Core F# project in VS2017 (even with the full .NET Framework.) How pathetic is that?

GiorgioG on 28 Mar 2017

❤1

Regarding the project/build system, I need to quote myself to re-establish the context:

@21c-HK (me)

Each of these concerns should be a separate file - each possibly consumed/produced by separate tools - and not all files necessarily have to - but could - share the same format.
....

I am still undecided what would be the best exactly, but the following could be the basis for a separate discussion
...

| concern | format | language|
|----------|---------|-----------|
| project definition | configuration format | TOML |
| dependencies | configuration format | Paket "language" or TOML |
| build configuration | configuration format | TOML |
| IDE configuration | configuration format | TOML or whatever that IDE is using|
| build script | simple declarative DSL | F# |

@Krzysztof-Cieslak

I think going to so many separate files is moving to another extreme. I think having project definition, and package definition in one file is OK... maybe even build configurations as long as it's static (i.e. doesn't contain custom programming language to manage like MsBuild with its conditionals and variable assignments). The biggest issue for me are dynamic parts of MsBuild - conditionals, variables, tasks. Conditionals and variables can be replaced with static declarative syntax (as vast majority of people always use same conditions, same targets etc). And for build script / tasks we have FAKE which is really good at what it does.

As I said, I was still undecided and I agree with you in principle. I just wanted to list the concerns and map each concern to the preferred format/language as a basis for discussion. We can see that project definition, dependencies and build configuration could use the same format (= TOML), so it might make sense to put them in a single file for convenience. But I don't think the number of files is the real issue here, but rather different formats/concepts. I don't really care if these 3 concerns are in the same file or in 3 files in the same folder as long as they are using a single easy-to-understand format. The only difference is that I don't have to hunt for the section in a single file that represents a concern compared to separate files and that different tools don't run into each other when working on the same file with different concerns.

I also tried to keep the table as general as possible. I was implicitly referring to FAKE when I said "simple declarative DLS in F#" and we already have it. We also have a great dependency manager (= Paket). While it does not use TOML (support could be added though), we already have it and it works really well. So we have everything except a a good open source cross-platform project system for F#.

I would like to continue the discussion on the project/build system in a separate dedicated thread. Do you have suggestions which repository would be the best for that?

21c-HK on 28 Mar 2017

@Krzysztof-Cieslak

I wonder how sustainable it is given that all those projects have 1-2 overproducing maintainers ...

I'm coming around to that the best approach to this is to encourage the maintainers to recruit at least 1-4 other maintainers. And to encourage all users to become contributors. There are many structural things we can do as a community to help each other achieve this. Sharing best practice around CI, docs, API key management, simplifying base tooling, avoiding churn in base tooling and so on.

Open source is very, very productive. All great open source tooling has 1-5 key developers at its core. Having 1 key maintainer is indeed tricky. Having 3-5 is much more solid. It's hard though, I know, and even with 3-5 people come and go. (Commercial projects suffer from the same phenomenon, just worse, because you have to recruit both significant $$ and managerial support for the entire lifetime of the tool.)

In any case it's something we should definitely talk about regularly, and be open and honest about. I like to think of "health assessments" for OSS projects - one aspect of which would be "how many maintainers do you have?"

dsyme on 28 Mar 2017

👍4 ❤1

@Krzysztof-Cieslak wrote:

For last 5 years it was "Nuget is OK because it's better than old dll hell" ...

There is at least one senior developer among my colleagues who would disagree. We have a lot of internal libraries that several of our software products use -- and our build scripts are currently set up so that if product A uses library B, it downloads libB.dll from the relevant build artifacts on our TeamCity server. I am NOT making this up. I recently brought up "Why aren't we creating NuGet packages for this?" and one of our senior developers said, "We tried that earlier, but it gave us no benefit, so we went back to downloading the DLL build artifacts from TeamCity."

In other words, he found DLL hell to be easier to deal with than NuGet. Let that one sink in for a while.

I had been planning to introduce Paket and say "Hey, this is better than NuGet, we should switch to it." But because my colleagues have an anti-NuGet prejudice based on previous bad experience, I'm going to have an uphill battle even getting them to try Paket.

Having good tooling really, REALLY matters.

rmunn on 28 Mar 2017

👍1

@rmunn manual dependency management is a very sane approach. Especially for smaller solutions (with not too many external deps and only a handful of projects) it's basically ideal. I'm not joking here.
For bigger solutions it can become really hard to keep track of everything, so a package manager usually helps. If you are in situation with hundreds of projects and many many deps then it's basically the only way to stay sane. Unfortunately nuget does not maintain anything across projects, so many people just don't think package managers are any good.

forki on 28 Mar 2017

@Krzysztof-Cieslak

Anyway, I guess due to different experinaces and point of views on the issues we should agree to disagree ¯(ツ)/¯

Why? Having different anecdotal experiences shouldn't discourage you from engaging further. This just means that _both_ of us have more to learn.

@forki

Probably Microsoft employees.

Nope.

We couldn't do that with packages.config for very good reasons - we might converge now.

It sounds like you're saying that you could be a drop-in replacement for NuGet w.r.t. PackageReference? If so, that's great. Precisely the sort of thing that ought to happen.

@21c-HK

I would like to continue the discussion on the project/build system in a separate dedicated thread. Do you have suggestions which repository would be the best for that?

Good idea. Not sure where, TBH. dotnet/sdk and dotnet/roslyn-project-system are the most actionable places. The former is defining what the .NET Core SDK looks like and how that surfaces in projects. The latter is where the future F# project system will live (yes, we're replacing the current one with CPS and making MSBuild 15.0-based .fsprojs the default for all things F# 😄). There may be good feedback to contribute about keeping project files as small as possible. @enricosada has also created the .NET CLI templates for F# using the new templating engine. It's very easy to create new templates now.

In terms of having an outright _replacement_ for MSBuild and its associated file format, I don't think such a thing will be possible. There are so many little things it does that people rely on. Project.json was a two-year effort to rewrite this and they still fell well short of their goal. There were absolutely flaws in their approach, but I'm willing to bet my life savings that any effort to create a new project format and project system for F# which can talk to existing F# code will go down the same path project.json did.

I think the most productive thing we can do in this area is to champion a build DSL as the default tooling experience all-up. I've made the case for this internally before, but in the midst of trying to ship _something_ for .NET Core it wasn't really considered. Once .NET Core gets to a usable state for most .NET developers alongside matured tooling, folks in those areas may be more open to this idea. CAKE and FAKE are the two obvious choices. Perhaps there are others, but creating an extensibility point within VS to allow you to use your build DSL of choice likely isn't much work. And the non-VS use case is already solved.

cartermp on 28 Mar 2017

It sounds like you're saying that you could be a drop-in replacement for NuGet w.r.t. PackageReference

There is a subset of paket.references features that would work with PackageReferences in fsproj. Yes. But I'm not 100% sure it's a good idea.

forki on 28 Mar 2017

my feedback, doing a lot of fsprj stuff.

the dotnet restore (who is just nuget as msbuild task, in fact is dotnet msbuild /t:Restore) and PackageReference doesnt fix the old issues of nuget (lock file for app, deps version ranges for libraries), neither does the transitive dependencies.
these just hide the problem, with a less verbose and easy to use sintax.
A PackageReference is just the old package.config, just inside fsproj, so can also be read later by dotnet pack (that's nice)

the new fsproj.
If people continue to treat fsproj/csproj as project file definition, that's the first and big error.
msbuild project are not project definitions (compile items, references, fsc arguments, etc).
msbuild project are MAKEFILE.
What ide does, is to evaluate that makefile, to gather the compiler args and other properties (common arguments, the files like Content who are not needed for compilation, but included in project, etc)
That said, the msbuild project can be implemented with:

msbuild xml sintax (is a dsl language, to manipulate props (= string) or items (=object with props)), and add methods (Target)
tasks who are just methods implemented as .net classes (so props for input/output and an Execute method to do stuff), instead of the msbuild xml sintax
msbuild also give some ootb useful things like dependency ordering, and incremental (if my input is A, and i say i will produce B, i need to run transformation? yes/no), and a way to sintax to manipulate strings and items list

new fsproj/csproj is a big makefile, pluggable from new target/props from nuget packages. that's the real deal ihmo of new fsproj.

Now, using makefiles instead of (dumb project definition + runner) has props and cons. Is a choice.

cons: harder sintax to get/set common info, understand things
props: easier to extend with new actions, without changing the runner

that said, if you prefer a dumb project definition, and want to write your files list/props/deps as .json/toml , just generated a .props file in obj/myproj.fsproj.example.props, with all the info.
because exists this extension point, you can (that's what nuget does btw).

Or you can reimplement your makefile logic as F# script, is the same, is just a different language, with different sintax/rules/extensbility. I like xml? nope, but neither makefile sintax. f# is better as dsl for makefiles? maybe, but you need to implement some features as lib (incremental/deps order) and can be ok too.

Issue of VS and msbuild ihmo is it does try to cleanly separate and abstract the (msbuild makefile -> useful info) and command, but like that is easier to implement (for VS, because zero abstraction)

About paket, everything it does can be integrated cleanly in the new sdk (github files? -> Compile items auto included), etc.
And is not a matter of xml vs F#, is just a matter of how and where extend an existing codebase (restore/pack). If that is written in xml+c#, or f# doesnt matter, these are just a flow of methods invocation, like every program.

Obv as F# and C# dev i prefer that sintax for set variabile, string manipulation, object creation, method invocation. but msbuild format is just another language.
should we need to learn two language (F# and msbuild) to really change a build orchestration? that;s another question

enricosada on 28 Mar 2017

👍1

If that is written in xml+c#, or f# doesnt matter

but msbuild format is just another language.

Well, everything is _just_ a language. But languages _do_ matter! Otherwise we would still be programming in assembly, which is also "just a language". MSBuild sucks. It has always sucked. Granted, it's old and back in the day when every one ~~was insane~~ thought XML was the solution for everything, lots of dumb things were developed that were based on XML. But it's 2017, we should learn from past mistakes. Anyone working for Microsoft or another company that suggests _today_ to create a build DSL in XML should be fired instantly due to (obvious) mental illness. And if you wouldn't recreate it, then why would you keep maintaining it?

It may be the case that VS just needs to use MSBuild because VS is so complex that it cannot be replaced in a reasonable amount of time, but that should not prevent other IDEs and build tools from using a shared project system for F# that does not suck. May be the most reasonable solution is to have 2 project systems. MSBuild/CPS used by VS (because of backwards-compatibility and Microsoft's love of artificial complexity) and one used by all other tools (where its developers and users respect themselves). The intersection of the sets of users using both MSBuild/VS and another build tool for the same project is probably pretty small anyway.

21c-HK on 28 Mar 2017

Unfortunately nowadays, we build these things in json - which is about as bad as XML.

S-expressions are the way to go. Fortunately, there is an F# library that uses s-exprs for serialization, DSLs, and even a pluggable dynamic scripting language - https://www.nuget.org/packages/Prime/

😀

bryanedds on 28 Mar 2017

👍1

Unfortunately nowadays, we build these things in json - which is about as bad as XML.

Completely agree.

S-expressions are the way to go.

S-expression are even worse than JSON or XML, because it has less structure and even less type information than either. Structured data types like record types and union types in F# that can be checked statically is the best you could possibly hope for with regards to typed data, but TOML is fine for simple configuration information.

21c-HK on 28 Mar 2017

@21c-HK Just to offer a bit more historical context:

project.json was an ultimately failed effort to replace MSBuild. This was driven fundamentally by the fact that it could not talk to existing code in VS. That's a problem when the corpus of code is written in VS. That said, it brought certain capabilities to the table which have since been adopted by MSBuild, including:

Transitive project references
Obvious multitargeting behavior
Cross-platform

The focus in the recent past has been to bring those capabilities (and more) to MSBuild, without sacrificing the ability to talk to existing code or tools. That work isn't 100% finished yet, as it also depends on platform changes for .NET Core. I should underscore this, though:

This doesn't mean MSBuild and MSBuild XML is the only thing people at Microsoft care about.

Right now the top-of-mind concern is how to get the gargantuan population of existing developers able to write code on .NET Core, .NET Standard, and Xamarin without having those projects live in silos. This affects F# as well. Once this is achieved, other ideas will be explored. I come back to the idea of championing a build DSL like FAKE or CAKE. This is a solution other platforms have done as well, and it's _far_ more realistic than creating one's own build and project system.

I should be clear about my opinions regarding a new build and/or project system. Such an effort will be:

Titantic in scope if you wish to support even a fraction of the capabilities F# developers require for their professional work in larger codebases
Absolutely thankless

As with any inherently difficult domain, it's easy enough to get a basic proof-of-concept working. But when someone has a requirement such as generating satellite assemblies based on locale, it becomes a different story altogether.

cartermp on 28 Mar 2017

👍1

It is factually incorrect to say that s-exprs have less type information
than XML. Json may have additional literal types, but s-expressions have
quotations - so that too is mostly false. The advantages of s-expressions
are structural - try writing a scripting language with json syntax - you
really can't hope to. You can sort of do it in XML (ugh), but then you lose
the types offered by Json and s-exprs.

On Tue, Mar 28, 2017 at 1:17 PM, 21c-HK notifications@github.com wrote:

Unfortunately nowadays, we build these things in json - which is about as
bad as XML.

Completely agree.

S-expressions are the way to go.

S-expression are even worse than JSON or XML, because it has less
structure and even less type information than either. Structured data types
like record types and union types in F# that can be checked statically is
the best you could possibly hope for with regards to typed data, but TOML
is fine for simple configuration information.

—
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-289841022,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABjN2Oa8JhRHSH_AYewmOMXSvUoU0jxnks5rqUC9gaJpZM4JJuVb
.

bryanedds on 28 Mar 2017

It is factually incorrect to say that s-exprs have less type information
the XML.

I meant type information as in product types (record or tuple in F#) and sum types (i.e. union in F#). XML has both even if I don't remember from the top of my head whether XML supports full blown unions or just enums as in C#. S-expressions by themselves have no explicit type information other than the basic type literals and the list structure. All structured type information is implicit.

Don't get me wrong, I would actually prefer S-expressions over JSON and XML, but not because the latter can encode a little bit of type information.

21c-HK on 28 Mar 2017

I see barriers to adoption as resistance on multiple levels. Every developer has an individual resistance threshold (or "pain"-threshold). If the technology directly or indirectly puts up enough resistance to overcome the threshold of that particular developer, then you have lost the interest of that developer - often times for good. This happened to me with Haskell's tooling on Windows when I tried it a few years ago. I've seen non-Windows developers optimistically try Mono to finally develop with .NET only to find out that it was too buggy (this was also a few years back).

Experienced developers have gotten used to so much bullshit over time (read "bullshit" as: stuff not working due to really silly reasons, or fighting unnecessary complexity) that they have developed a very large threshold for resistance they can put up with out of necessity. These experienced developers are willing to do almost anything to get something to work whereas beginning developers simply switch to a technology with less resistance ("where the grass seems greener"). As they get more experienced, they also tolerate more bullshit. This is why Javascript, Java and C# have become so popular. They have a low _perceived_ resistance - whether superficial or not does not matter - because the barriers to entry are so low, i.e. very few simple concepts - like assignment and loops (and ignoring classes, initially) - is all you need to get started while amazing tooling hides most of the artificial complexity that will bite you in the ass when the code base grows. Just download VS, create new project, copy/paste code off the internet, run. Congratulations, you are a programmer 💪. Bang your head on the keyboard, install Resharper, let Resharper do its thing, and congratulations, you are an above-average programmer.

I am not necessarily saying that it should be like this, but Microsoft has always appealed to these developers. You don't need to know much, but still get something done. And then you can grow from there. This is why I got started with Microsoft technologies. They made VB 6 with VS 6.0 so easy that even a kid could get started and have stuff moving on the screen within a few minutes. VB 6 was so far ahead of C++ in terms of productivity and easy-of-use that it was proudly marketed as "rapid application development (RAD)" when that was a thing 😄. VB.NET and C# with VS.NET was actually a step back in that regard and I remember how people complained how difficult it was to switch from VB to VB.NET. There was already so much resistance that most VB developers switched straight to C#. I did too. The syntax was the smallest problem, but after switching to C# you could at least call yourself a "real" developer (VB developers were looked down upon) 😄.

A long time passed and since learning and using F# (and learning about other reasonable languages and technologies), my personal threshold for resistance has actually decreased significantly. I expect things to be simple and work out of the box, because I am not longer willing to waste my time on crappy technologies. In a sense, the F# language is the first technology that I tried that feels "RAD" again for developing large programs. I am looking forward for F# tooling to be "RAD" as well.

I've re-read the entire thread to see if there are common themes with regards to resistance. It seems to there are three levels:

Ideological resistance: "F# was made by Microsoft. I believe that Microsoft is evil. Therefore, I use an independent language". I think that is a very small (and very loud) set of developers that may never consider F# as a viable choice, or it's just a matter of time until these people realize that this is not true and that F# is actually in an ideal position: great open source community and steering and support from a company with immense resources that work together to create the best possible development experience.

Theoretical resistance: "F# does not have higher-kinded types. Therefore, it must be a toy language. I'll check out Haskell or Scala instead." - This is also a small (but loud) set of developers that may never consider F# as an alternative _unless_ some really cool F# libraries get their attention and may convince them to at least try F# in practice.

Practical resistance:

"I want to use F#, but IDE support is not as great as I am used to with other languages (e.g. C#)."
"I want to build a web site. How can I do this in F#? Why are there so many web libraries and how are they different?"
"NuGet/MSBuild is messing up my F# build again. NuGet/MSBuild has already wasted so much of my time." Frustratingly looks for alternatives...

The is the largest (and mostly silent) set of developers, which may get turned off by too much practical resistance. These developers usually just try to solve the problem and you may never hear from them ever again (whether they stick with F# or not). Removing practical resistance has the most impact on adoption (as Elm proves). And this is why I believe that a simple shared open source F# project system is so important. Combine that with VSCode, ionide, Paket, FAKE and a bit more sugar for a hopefully frictionless out-of-box experience in the future and we may have removed a lot of practical resistance.

21c-HK on 30 Mar 2017

👍7 ❤1

A long time passed and since learning and using F# (and learning about other reasonable languages and technologies), my personal threshold for resistance has actually decreased significantly. I expect things to be simple and work out of the box, because I am not longer willing to waste my time on crappy technologies.

The core reason I'm interesting in learning and using F# is the promise of simplicity and increased productivity. I've been a .NET developer since v1.0 beta (when I had just graduated from university.) As much as I prefer C# over other C-family languages, I'm sick of all the boilerplate I have to write, and I've become weary of OOP - it's too complex to design a flexible, well-thought out system for line of business applications (for proof, go read Bertrand Mayer's Object-Oriented Construction (1296 pages!) I've been influenced by Rich Hickey's "Simple Made Easy" presentation (I'm sure most will be familiar with it.) After taking some time to learn React & Angular 2, I think I've reached my bullshit threshold and I'm not willing to take it anymore. I feel that application development (the process and tooling) has become overly complex without yielding substantive gains for the end users (that's why we're here right?)

What's holding me up personally with F# is practical resistance. I can't use F# with ASP.NET Core (well I can but are the project templates even up to date?) I can't use Visual Studio because of the missing msbuild 15 support, etc. Can I use VS Code? Of course, but I'm not a big fan of its UI/UX and ever little bit of practical resistance builds up and makes me doubt whether I'm making the right choice. I could fire up IntelliJ and start being productive in a number of languages where there's little practical resistance compared to these issues. The main downside for me would be leaving the .NET ecosystem. To be clear I'm not one of those developers who only knows a single stack (I've done Java, NodeJS, some Golang, Swift.), but for me, .NET is "home."

I hope folks don't take the above as just idle complaining - I'm optimistic about F#. I suppose I'm just being impatient ;)

GiorgioG on 30 Mar 2017

👍1

@21c-HK Thank you for such an excellent and well-thought out summary post.

I'd add at least one other kind of resistance: loosely cultural resistance or network resistance: "I want to use F#, and there are no ideological, theoretical or practical reasons not to do it, and lots of reasons why it's a good idea, but the weight of my social/work/professional/economic/... network around me makes that difficult (for all sorts of reasons)"

You can just view this as the sum of the other three kinds of resistances across the social situation (work etc) you happen to find yourself writing code in. If you're writing code by yourself, that sum is zero. If you're in a massive corporation that only allows Java, then the sum is basically infinite :)

This kind of resistance is faced by nearly all technologies and is fundamentally different to the other categories. It is particularly strong when developers are faced by fierce managers who demand that a team stick to some particular language (and have probably already seen off numerous "young turks" who want to change things). It is also a factor when faced with teams that churn, or a corporate culture that only allows particular languages to be used, or a corporate culture that sees developers as interchangeable, or a corporate culture that basically wants to stop developers actually writing code (yes, it happens).

F# faces plenty of this kind resistance (though n some other ways less than other languages, e.g. it is at .NET language which can reduce overall cultural/network resistance compared to a native language)

This kind of resistance is odd: decreasing resistance along some other dimensions (e.g. adding lots of cool new technical features to decrease technical resistance) can increase resistance along this dimension (e.g. your boss is not deeply technical and hates you talking about these language features he/she doesn't understand). This is one reason why piling on new technical features is not necessarily a solution to decreasing resistance.

dsyme on 30 Mar 2017

❤1 👍1

In the US, and likely other Western countries, we have a serious problem of capital allocation. For example, the way that capital is allocated in the US tends to be way overly conservative. Nowadays, capital only tends to flow from a vanishingly small set of overly risk-averse actors, acting either purely for the motive of lottery-level profit, or straight up politics. Give how locked up the US economy has been for the last decade or so, capital tends to flow only on a 'viral' basis - that is, unless your start-up has a one-in-a-million appeal, you won't hope to see a dime. In too many cases, the only way in which investors see themselves making money is by getting OTHER investors to put money into a start-up until valuations explode and the whole thing gets sold to a greater fool (EG - the investing public). I guess you could call this a 'hot-potato start-up phenomenon,' and it is a truly suffocating environment for small businesses that actually want to produce something of value for the consuming public.

Don mentions - with 100% accuracy - that what much accounts for our present technological inertia is cultural resistance. Ideally, functioning market have a great way to overcome this. In a functioning market, new businesses pop up all the time due to capital flows that arrive as an outcome of reasonable risk appetite. With new businesses come new ways of thinking, and adoptions of new technology exactly like ours. Unfortunately, as I explained above, we do not have a functioning market like in the US, nor in much of the West. And this is a huge problem for meritorious technologies like F#.

Now, as a conservative / libertarian I have some opinions as what can be done to unlock the US economy. But I don't have any reason to state them here because, frankly, I don't think anyone here has sufficient influence to affect any of the changes that are needed. This is macro-level stuff.

So let's instead talk about what we, as individual contributors and open source engineers, can do.

We have to understand that, in all but the most pathological cases, even locked up markets do eventually resolve issues. While an unlocked market might adopt new technology in a year or two, our locked up market often takes 5-10. That's just how it is in this type of economy - everything is in slow motion - including technology adoption.

For us, then, it must all be about keeping a stubborn long view and continuing to invest ourselves in to what we know is the right thing. It takes a lot of faith and grit to work for a future that is years away - but that's the nature of our economy's timeline, AFAIK.

bryanedds on 30 Mar 2017

BTW - I turned the above comment into a full-blown article here - https://medium.com/@bryanedds/how-locked-up-economies-put-the-adoption-of-programming-technologies-into-slow-motion-b8c2da89b93e

bryanedds on 30 Mar 2017

@dsyme Thank you for the (most) important addition with regards to kinds of resistance. You explained it better than I could have anyway. Of course, cultural resistance is the resistance with the most impact and it is also the most difficult to tackle due to its complexity and (sometimes unintuitive) interactions. Changing culture is always very hard (if not impossible).

One (for me at least) unexpected cultural factor was what Eric Sink refers to as "pragmatists in pain", which are a subset of mainstream programmers with enough pain to be willing to leave the safety of the herd (great article, btw)

Sometimes a pragmatist can be convinced to break with the herd. The key is to find what Moore calls a "pragmatist in pain".

A pragmatist in pain is someone whose needs are not being well met by whatever technology is current popular among pragmatists. The current technology is not merely annoying them. It is failing them.

A pragmatist in pain actually does care about how F# is better, even though this goes against their nature. They really hate the idea of listening to some F# nerd prattle on about immutability and type inference. But they have reached their last resort. Their pain has forced them to look for hope from somebody outside the herd.

This is how a new product gets across the chasm. Find a pragmatist in pain. Do whatever-it-takes to make them happy with your product. Then go back and do it again. Repeat until you have enough customers that they can go to PragmatiCon without being shunned and ridiculed.
[...]
I also understand that F#'s awesomeness is basically irrelevant to the question of whether it will go mainstream or not. If the pragmatists are not in pain, they are not interested. C# doesn't cause very much pain.

In other words, the chance of a new programming language becoming mainstream seems to be proportional to how much pain the old language is causing in the same ecosystem.

Scala was made to replace Java.
Swift was made to replace Objective-C.
Elm was made to replace Javascript (and other client-side technologies).
C# was made to replace C++ (at least on Windows).

All these new languages improve upon (old) painful languages in the same ecosystem. The old languages were causing so much pain that switching to the new language seems to be worth it. But F# competes with C# on .NET - and C# is one of the best imperative OO languages that kept picking up all the features that were hyped over the years. Scala is basically C# with the addition of case classes, higher-kinded types, traits, implicits and different but kind-of-familiar syntax (Note: please don't derail this thread into a discussion on which programming language is better, this is not about that). Ignoring particular language features, Scala, C# and F# are all competing in the big league and even compete outside of their respective ecosystems. The _perceived_ difference between C# and F# in terms of features is not that large. The first time I heard about F# I thought "F# is like C# with just a bit more emphasis on FP and weird syntax. Microsoft is still using C# to write all of its APIs. I can do everything in C#. All .NET tools are optimized for C#. Almost all .NET jobs are for C# developers. Why should I even consider trying F# if it's out-of-box experience is not like that of C#?"

Later I realized that C# is still causing way too much pain (of course, less than older languages, but comparable to the difference between the old language and new the language, and C# and F#, respectively). It's just not easy to see how much pain C# (and languages with similar problems) are causing when your bullshit threshold is approaching infinity. The beauty of F# as a programming language though is that its sum is greater than its parts. F# makes so many (unnecessary) problems go away that programming is simply a lot more fun and productive. It's not an individual feature that makes it so great, but how they all fit together and how some (bad) programming ideas have been purposefully discouraged (e.g. null, mutability/assignment, arbitrary file ordering, mutually recursive types, implicit interface implementations, etc.)

I guess the most impactful cultural push for F# within the .NET ecosystem would be if Microsoft would say "Listen folks, we decided to drop support for C# and VB.NET. We are very sorry, but we realized that F# is so much better. So, please use F# from now on. Here is a new base library and all our tools are now optimized for F# only. What is that backwards-compatibility you speak of? We have build everything from scratch. You just need to re-learn everything." but I understand that this is wishful thinking since that would simply hurt the .NET ecosystem overall and Microsoft's image/customers.

e.g. your boss is not deeply technical and hates you talking about these language features he/she doesn't understand

I've actually experienced this personally with a technical decision maker 😄. The boss (responsible for business decisions) was actually really impressed with F#, but he had to trust the technical decision maker.

@GiorgioG

I hope folks don't take the above as just idle complaining - I'm optimistic about F#. I suppose I'm just being impatient ;)

Same here. I would not be spending so much time in this discussion if I wasn't already in love with F# and its potential. I think "impatience" is the right word. F# 4.1 is really awesome and I know that we will get the tooling eventually right, but I want it sooner than later 😉.

Edit: Improved wording including title and description of contents of referenced article. Also included quotes from article.

21c-HK on 30 Mar 2017

On a slightly different but still tooling-related note, one of the reasons I'm still holding back from introducing F# to my coworkers is documentation. Specifically, the documentation of FAKE, which is quite hard to find things in even when you know what you're looking for. Since FAKE is pretty much the de facto standard build tool for F# projects (unless they were written by @haf, who prefers Rake), that's the tool that I'll be recommending. I don't expect to have much trouble getting them to use Paket (if I can persuade them to use NuGet packages at all — see my earlier comment), but FAKE is another story. The documentation that has been written for FAKE so far is great, but it's a little inconsistent (e.g., the Getting Started tutorial recommends Paket, but the first non-tutorial link underneath it is "NuGet package restore", which doesn't mention Paket at all. Huh?), and it has serious discoverability problems. That is, if I was a newbie to FAKE, I would have no idea where to go to find the function I needed.

The easiest solution I can see to that particular problem would be to build a function index, so I've opened https://github.com/tpetricek/FSharp.Formatting/issues/431 to discuss that idea. But I'm also mentioning it here, because I think this may be one of the barriers to adoption. Take a look at this series of Stack Overflow questions, all from the same user, and consider how many other users would have given up after the second or third roadblock:

If we want to see F# and its excellent tools being adopted, we need to make it easy for people to figure out how to use those tools, which means documentation that isn't just good, or even great, but just as excellent as the tools themselves are.

rmunn on 30 Mar 2017

@rmunn That's true. I'd reckon @forki would appreciate a few people becoming co-maintainers on FAKE with a view to documentation and issue management. It's basically very stable and its a good time for people to come in and work on those perspectives.

dsyme on 31 Mar 2017

👍1

I'm already planning on doing some work on the FAKE documentation, but currently since I haven't yet persuaded my coworkers (and more importantly, my boss) to use F#, I can only justify working on F# stuff in my limited evenings-and-weekends time. But there's also the RFC I need to write for my "simple arithmetic in numeric literals" suggestion, and then I need to start reading the F# compiler code to figure out how to implement it...

There are lots of places I want to contribute, and I'll be able to get to all of them eventually. The key is figuring out which one is the highest priority at this moment. :-)

rmunn on 31 Mar 2017

@21c-HK - Sorry this is getting too far afield, but I wrote an article demonstrating why s-exprs are better than XML and Json. You can apply its arguments against TOML, too (one example TOML is a poor data representation is because it doesn't represent data well when that data happens to be code) -

https://medium.com/@bryanedds/a-powerful-f-library-shows-how-s-expressions-can-beat-xml-and-json-20c34ba1db4b

Sorry for veering further off the topic of discussion. Please post further argumentation in the above article's comment section.

bryanedds on 31 Mar 2017

F# needs a database built in F#. I know that sounds like a shot in the dark, but honestly most large projects that brought recognition to the Clojure and Scala communities are alternative databases (or similar projects).

I think a decent, columnar, in-memory database, with strong type provider integration, aimed at analytics, would be a really nice addition to the F# community. Then start tuning libraries like Deedle and FSharp.Data to analyze and load data into it. Maybe implement concurrency with Hopac. Management interface through Suave and Fable? What's more, many of the existing users of F# are in the financials industry where such databases are very popular (think kdb, JD, Kerf, et cetera). Incidentally, I'm not trying to trivialize this as a weekend project or even a few month project. But I do think this would be something that would allow a soup to nuts ability to solve business problems using F#. I find it very unlikely that the F# community will overtake 'Web Dev' on the .net platform because so much of that inertia relies on asp.net and F# will always be second class there. C# is not trying to take on analytics much, and most C# dev's won't feel bad about F# taking over part of that domain since they already mentally put it there and things like R/pandas are even more foreign.

Call it 'F-Store'

I would do this, but I absolutely guarantee you don't want a database written by me. I sometimes struggle with writing folds. ;)

nicholas-peterson on 31 Mar 2017

@nicholas-peterson

I sometimes struggle with writing folds. ;)

Me too! I embarrassingly forgot the first parameter to Array.fold while livecoding on a video and talking at the same time. I guess my brain can only do two things at once 😄.

Interesting point about having a database technology written in F#. There are certainly examples of other languages being successful because of this. I think that you could also say the same about distributed computing libraries or frameworks. I think we have some special with MBrace. I knot that MBrace is having issues with getting on .NET Core due to changes to reflection (and likely other things). I think that .NET Core 2.0 presents a good opportunity here for us to make F# unique for cloud development here.

cartermp on 31 Mar 2017

My 2 cents of tasks that would help:

Make it easy to use F# in part, like webpack-fable does /cc @alfonsogarciacaro 👍
I just checked the MSDN docs and saw they were editable 👍
Consider creating a compile-to-native story for F# that works on Linux to capture devops-community mind-share
Consider that public presentations by Don should be geared towards the zen of F# programming and less towards introspection of the community – primarily at least – Clojure got a large usage uptick due to how Rich Hickey managed to verbalise many contemporary concerns in software development
The problem with build tools on .Net is that they focus too much on this-or-that tool that can be invoked from the command line. This failure to focus on the core; building the code efficiently and conveniently – especially when you have multiple projects, multiple nugets across different repositories makes for a worse development experience. Consider what Webpack does that makes it so completely pluggable and still easy to use – IMO they focus on building the code and provide a way people can plug into that with Plugins and Loaders. That I use albacore is just band-aid – we're still losing many hours as a F# team working around the bad software build story and slow, eventually consistent nuget servers like nuget.org and myget.
Move the F# compiler to its repository at fsharp/fsharp and set up CI on three or four OS-es; a BSD, a linux, OS X/macOS and Windows. Also separate the compiler from the rest. Make it compile on all operating systems (it's strange that I have to say this). I recently tried to fix a UTF8 bug that had lingered for years – which was introduced due to the previously very broken state of the Windows terminal – but the repo doesn't build on OS X (that I use) nor are there instructions on how to test things in the README. Make the contribution to the compiler easy by automating as much as possible, stopping the 'factory' when there are bugs in it and providing prospective hackers with a repeatable processes, clearly documented for how to make changes and test.
Consider fanning out or outsourcing the creation of bindings for popular frameworks with mindshare and keep them up to date with continuous integration, like Tensorflow, OpenCV, Keras.io, Consul.io/Vault (like I did with Fakta). I'd be happy to project lead such an outsourcing effort since I need these projects myself if I get some budget to do it. Once the binding/client/connector has been written, point to its documentation from the MSDN docs. This would remove the friction to create and test out F# for spikes/prototypes – and we all know prototypes end up in production.
Consider hiring a technical writer for the corresponding clients/connectors above on a full-time basis, to create documentation for popular frameworks.
Make it easy for people to use the above docs + clients/connectors to create presentations at developer events.
Consider hiring a developer advocate.
Show the end-to-end story to people, right from the get-go at MSDN; like I'm trying to do with Fable + Suave + Logary + Expecto + Fakta + Kubernetes + ... .
In the long run it's not about "overtaking" C#. It's about carving out a nice niche for F# as a language and a community and recruiting people from all over the language space.

haf on 31 Mar 2017

👍1

We might also consider building tools for existing large open source projects in F# - especially popular projects such as Kubernetes so as to piggyback off their popularity and indirectly boost F#'s audience. Contributors would likely want to add additional functionally, fix bugs, etc and they would have to learn/use F# to do so.

GiorgioG on 31 Mar 2017

Lots of issues being discussed here. I think there should be separate issues for discussion. And this or a new issue tracking them.

gulshan on 1 Apr 2017

👍1

I've been influenced by Rich Hickey's "Simple Made Easy" presentation (I'm sure most will be familiar with it.) After taking some time to learn React & Angular 2, I think I've reached my bullshit threshold and I'm not willing to take it anymore.

Clojure got a large usage uptick due to how Rich Hickey managed to verbalise many contemporary concerns in software development.

Since he was mentioned here twice and since he also had a huge influence on me:
Rich Hickey's talks should be required watching if your bullshit threshold is (too) high. Even though he is clearly a strong advocate of dynamic typing - which is a source of lots of bullshit - (ironically) his views/ideas are even more true/valuable in the context of the kind of static typing and type inference that F#, Haskell and ML-derived languages offer. Rich Hickey's greatest talent is telling mainstream developers what they don't necessarily want to hear without offending them - unlike me 😉.

I disagree with his opinions on dynamic vs. static typing, but he is clearly a genius and an amazing communicator, whose influence on developers in pain is invaluable - only surpassed by @dsyme since we still need a language that implements all those great ideas 😁.

21c-HK on 1 Apr 2017

After reading tons of comments in this thread, probably I can contribute to the discussion highlighting my first steps into F#.

I am not a .NET developer, but I code in C# often in Unity3D and I am very into functional programming. Therefore, as you can imagine F# is a natural attraction. However, my main point of conflict with F# is in the build system. I find it confusing and "unnecessarily" complex. I can feel Visual Studio leaking everywhere in my command line experience and I not comfortable with this.

I know that this is mostly because of my inexperience and the need for Visual Studio compatibility (and, probably, because of my OCD), but I'd really like to have a more straightforward build tool, such as cargo from Rust, or hex from Elixir, or the Go one, or... well you got the point.

THeK3nger on 5 Apr 2017

👍4

@THeK3nger Thank you for sharing your first-hand experience of getting started with F# as a non-.NET developer and confirming that the build-system is one of the first major issues encountered.

21c-HK on 5 Apr 2017

@cartermp How do we convince/persuade Microsoft to put more resources on the F# team? As a C# .NET dev, I'm giving up (yet again) on learning/using F# because the developer story is non-existant for .NET Core / MSBuild 15 / VS2017...at least through Q3 of this year realistically and by then C# 8.0 will probably be in alpha/beta ;)

Moving the adoption needle is a pipe-dream at this pace of development. Despite the fact that Microsoft has committed to open source, the open source community has not embraced the F# projects in meaningful numbers to support the level of effort required to keep F# development at anything beyond a snail's pace. This is not a dig at the herculean efforts that are being made by those in the community and at Microsoft. The team is obviously understaffed.

What kind of confidence will potential adopters have considering Microsoft treats F# like a red-headed stepchild?

Let's consider the number of contributors on various open source language projects on github:

F# (this repo): 87
Scala: 314
Elixir: 535
Haskell Compiler (ghc/ghc): 350
Erlang: 394
Roslyn: 209
Clojure: 125
golang: 779

The momentum is not in F#'s favor and the actions that Microsoft have taken seems to indicate it has little interest in F# being anything more than a niche language, and a playground for future C# features.

GiorgioG on 5 Apr 2017

👍1

because the developer story is non-existant for .NET Core / MSBuild 15

I know pretty good way of developing F# using those.

Krzysztof-Cieslak on 6 Apr 2017

@Krzysztof-Cieslak VS Code is a nice lightweight editor, but it's not Visual Studio.

"Visual Studio Code is a streamlined code editor with support for development operations like debugging, task running and version control. It aims to provide just the tools a developer needs for a quick code-build-debug cycle and leaves more complex workflows to fuller featured IDEs."

GiorgioG on 6 Apr 2017

but it's not Visual Studio

That's the biggest advantage.

Krzysztof-Cieslak on 6 Apr 2017

😄3 👍3 ❤2 🎉2 👎1

but it's not Visual Studio

That's the biggest advantage.

You're obviously entitled to your opinion...even if you're wrong ;)

GiorgioG on 6 Apr 2017

👎1

Disclosure: I haven't actually used F# 4.1 yet. I also haven't tried VS 2017 (yet, or may never).

This comment is not supposed to be fuel for one side in the discussion on F# with VS 2017 vs. VS code and other IDEs, but the information presented in #2400 (“2017 Status and Roadmap for F# and the Visual F# Tools”), #1096 (“F# Support in .NET Native and UWP”) and Announcing F# 4.1 and the Visual F# Tools for Visual Studio 2017 with regards to missing MSBuild 15 support for F# in VS 2017, limited support for .NET's cross-platform efforts (.NET Core, .NET Standard) with F# in VS 2017 and no native support for Microsoft's future platform (Windows Store / UWP via .NET Native) with F# is a “little” (read as: very) discouraging. Especially since AOT compilation via .NET Native and .NET CoreRT could make F# even more attractive since you could (in theory) target iOS and other native-only platforms without having to use Xamarin.

Here are a few comments from #2400 that summarize my concern pretty well:

This roadmap makes it appear that, for my purposes, VS 2017 RTM is really more of an alpha release for F# support, at least wrt .NET Core.

PackageReferences work with command line tools and ionide - just not in VS
yet.

F# will be using CPS in Visual Studio and adopt the new MSBuild PackageReference and other goodies. I highly recommend using the CLI and VSCode to experiment with it today.

So, F# ended up being a second-class citizen in VS 2017 / .NET Core again (in addition to not being installed by default in VS 2017). I guess the real issue is the following, which has already been mentioned:

How do we convince/persuade Microsoft to put more resources on the F# team? As a C# .NET dev, I'm giving up (yet again) on learning/using F# because the developer story is non-existant for .NET Core / MSBuild 15 / VS2017...at least through Q3 of this year realistically [...]. This is not a dig at the herculean efforts that are being made by those in the community and at Microsoft. The team is obviously understaffed.

It's pretty insane how much work the little F# team is doing (and supposed to be doing). The F# team is definitely understaffed (in relative and especially in absolute terms). I don't who would be the right person to address this (@dsyme?, @cartermp?), but please consider hiring some/most/all of the people mentioned at the end of Announcing F# 4.1 and the Visual F# Tools for Visual Studio 2017 to expand the F# team. These could even be remote positions since this is how they made their contributions so far anyway. I know that at least one of them works full-time for a company that does not appear to even use F# to develop their products, yet this person somehow manages to make huge contributions here and to other major open source F# projects. Imagine how much these people could accomplish for the F# ecosystem if they were paid to work full-time on it (including VS and open-source projects).

And as long as the F# team is understaffed, F# releases should not be tied to release cycles of VS and other Microsoft efforts, otherwise the F# releases may be rushed and put off developers for good who were genuinely interested in using F#, but disappointed in the current support in VS. Incidentally, this is the way it was done before and it seems to have worked better.

I know pretty good way of developing F# using [.NET Core / MSBuild 15].

@Krzysztof-Cieslak Please do share.

21c-HK on 11 Apr 2017

👍5

...limited support for .NET's cross-platform efforts (.NET Core, .NET Standard) with F# in VS 2017 and no native support for Microsoft's future platform (Windows Store / UWP via .NET Native) with F# is a “little” (read as: very) discouraging.

This.

These could even be remote positions since this is how they made their contributions so far anyway.

I don't think it's a matter of finding people who are capable of working on the platform so much as it is Microsoft's unwillingness to spend additional resources ($, time, etc) because it sees F# as second-class citizen (or just a niche language.)

There seems to be little point in trying to discuss improving the adoption rate until Microsoft takes F# seriously. "Microsoft does take F# very seriously" someone will say. If MS's budget F# can't handle adding enough staff to keep up with the rest of the .NET stack/toolchain, then it doesn't take F# very seriously - despite lip service to the contrary.

GiorgioG on 11 Apr 2017

👍1

Something to note about .NET Core:

It's changing. Tremendously. .NET Core 1.0/1.1 and .NET Standard 1.x is unsuitable for the vast majority of code in the world, and the number one feedback the .NET team was given was to revert the breaking API changes they did and add as many APIs back as possible to .NET Core. What this means in practical terms is that there will likely be a split in .NET Core much like the initial split in .NET Framework: 1.0 vs 2.0.

F# was fundamentally crippled by .NET Core 1.0 due to these breaking API changes. We're stakeholders, in addition to the millions of .NET developers who _cannot_ adopt .NET Core, in making sure that .NET Core 2.0+ accomplishes the goals of cross-platform without sacrificing existing code. I suppose adding 10 new developers to rewrite the F# compiler, Type Providers, and FSharp.Core to account for this would be one way to make it all work fully on .NET Core 1.0, but no reasonable business would do this when it's clear that the platform in the current state has too many problems for people to adopt. Hence, .NET Core 2.0 is where it's all at. It's the clear future platform for .NET.

From a tooling standpoint, one thing to point out is that the C#-only tools for .NET Core in Visual Studio also suffer from numerous bugs and issues due to the (some may say rushed) switch from project.json to the new MSBuild. We had MSBuild, .NET Core SDK, .NET CLI, and Visual Studio work all still in-progress and starting to come together right at the last minute. We could have either taken part in that, or directed our efforts to rebuilding our crippled infrastructure to allow our prolific open source contributors to add value and get their bits into VS. We chose the latter, which has resulted in a ~24 hour turnaround time from when a feature is checked in to when it is available in Visual Studio. This nightly process makes our cadence for pushing features out faster than any other component in Visual Studio, and more importantly, it allows us to rapidly and easily just do some more validation on a build and ship it in an official update to VS. We're already scheduled for on such update in roughly a month's time. The work to get into that was very minimal on our end because we (and so many people in the F# community) have effectively been running on those bits for the past 1.5 months.

In terms of VS support for .NET Core projects, it's already been underway for a while, and you can see the progress right now. The initial support has already been checked in. This work is scheduled for the 3rd update for VS 2017, which timing-wise is equivalent to the old "Update 1" timeframe. Considering that this and .NET Core 2.0 support for the tools (yup, .NET Core 2.0 is different from .NET Core 1.0 and requires quite a few tooling changes again) are the two big areas for that team, I think it's safe to say that F# is not a second-class citizen here.

cartermp on 11 Apr 2017

👍3

@cartermp if F# is no second class citizen, where are the ASP.NET Core project templates in Vs2017? ASP.NET Core is supported by the full .NET framework. So Microsoft's official position on this is that .NET Core isn't ready for prime time in general, so there was no point in trying to support 1.0 with F# in the short term? Adding 10 developers to the team would be a drop in the bucket for Microsoft in their dev tools division, reinforcing the notion (right or wrong) that Microsoft has zero sense of urgency around F#.

GiorgioG on 11 Apr 2017

@GiorgioG All I can say is this: if you go hunting for reasons why something isn't what you wish it to be, you'll always find something.

Meanwhile, many F# developers are quite happy with first-class Azure Functions support (recently announced GA), being the _only_ .NET language which works on Azure Notebooks, revamped F# tooling in VS which is ~1 month away from a major update which unblocks loads of people, nearly first-class support in Xamarin, support for building all sorts of great things with Fable, the ability to use every major Azure service for all kinds of apps, and an OSS ecosystem which is bigger and more active than ever before. Not to mention cross-platform tools in VSCode and the .NET CLI and first-class support in Visual Studio for Mac.

Most of what I mentioned is built entirely by Microsoft and is representative of investments from Microsoft, but what I personally love is that it also involves heavy open source activity. It's becoming increasingly vital for development platforms to have a healthy open source ecosystem, and F# is a leader in the .NET world in that regard. Such an example is MBrace, which to my knowledge is the only innovative big data + cloud framework _unique to .NET_ and not just some binding to an existing JVM thing. The open source community can create more things and, in general, move more rapidly than Microsoft can. That's why it's so important and why I'm so positive that F# is moving in the right direction.

Now if you look at all of that and think, "I just don't care. I want .NET Core support on VS right now for F#, and the fact that it's not here right now is bad", then I'm sorry, but there's nothing that can be done about that. The support is coming, it's scheduled, and it's a priority for more than just the F# team. It's just not available _right now_.

cartermp on 11 Apr 2017

❤2 👍1

@GiorgioG F# and .NET Core doesnt work in VS. That's it atm. it's logged in the roadmap. it's WIP, with expected release date too. What's vf# can do more? That's just a normal feature/scenario missing.
Let's wait a bit.

that .NET Core isn't ready for prime time in general

no, he just said, to convert existing libraries and use case, take some time using .netstandard1.0 (because some breaking changes). netstandard2.0 will help about that.
for example for F# the 1.6 mean no Type provider. if you need that, you cannot. for other things is really good.

where are the ASP.NET Core project templates in Vs2017?

Why add .NET core or .NET Standard templates, if these will not work after creation? that will annoy dev more.

@GiorgioG if you want asp.net core mvc template, just do dotnet new mvc -lang f#.
Or wait until VF# support .net core sdk.

enricosada on 11 Apr 2017

❤1

@cartermp:

if you go hunting for reasons why something isn't what you wish it to be, you'll always find something.

I'm not hunting for anything, getting F# to parity with the rest of the .NET stack is not a high priority for Microsoft. I don't understand why it's such a big deal to say that. What matters is not your (or Microsoft's words,) but Microsoft's actions. If the C# team had missed a Visual Studio RC cutoff date, the RC would have been delayed. With F#, they basically said "meh, not important, let them release it out of band as an extension/package." Releasing VS2017 RTM without proper F# support for web dev, .NET Core, also not that important.

@enricosada

no, he just said, to convert existing libraries and use case, take time. .netstandard 2.0 will help about that.

I'm pretty sure that's exactly what he meant when he said:

.NET Core 1.0/1.1 and .NET Standard 1.x is unsuitable for the vast majority of code in the world.

.NET Core is plenty suitable for new projects, which by the way is where F# would fit in nicely. But guess what? Most of them aren't going to even consider F# because it has no VS support.

You guys can continue to spin it how you want to, but the fact remains: F# is treated as a second-class citizen by Microsoft. No shame in that, just own it.

GiorgioG on 11 Apr 2017

@GiorgioG I'm not sure what you're referring to here:

With F#, they basically said "meh, not important, let them release it out of band as an extension/package."

F# isn't an out of band extension/package. This doesn't underscore the massive issues in RC1, which we own (not some lofty entity), but it is shipped in-band with good adoption already. I'm not allowed to show adoption numbers, but it's proportional to all-up VS adoption at release compared with total usage (which shouldn't surprise people). And as a counterpoint, F# is getting an update in VS 2017 Update 2. C# and .NET all-up aren't (modulo super critical issues, like crashing VS), even thought I'm quite positive that those teams would love to get changes in there.

To address this:

You guys can continue to spin it how you want to, but the fact remains: F# is treated as a second-class citizen by Microsoft. No shame in that, just own it.

I don't think this isn't helpful. There are multiple, demonstrated cases where F# is first-class in Microsoft products and clearly moving towards first-class in the near-term. This also does not mention the incredible efforts of the open source community, who are pushing F# into new areas that it's never been before. I'm sorry if you cannot do precisely what you would like to do with F# today with Microsoft-authored tools and templates, and please don't think that we're not taking this seriously. But statements like this are not helpful towards anyone's goals. I won't comment any further on the position of whether or not F# is "first-class".

cartermp on 11 Apr 2017

@GiorgioG I'm not sure what you're referring to here:

With F#, they basically said "meh, not important, let them release it out of band as an extension/package."

https://github.com/Microsoft/visualfsharp/issues/2276 - "The latest VS2017 RC3 will not include updates to the F# tools over RC2. This is due to a mistake on our part, causing us to miss the update window for the new bits."

This also does not mention the incredible efforts of the open source community, who are pushing F# into new areas that it's never been before.

The issue is not the incredible efforts of the open source community, the issue is Microsoft's continued understaffing of the F# team. Looking at the github pulse graph it's hard to tell how many Microsoft devs are working in the visualfsharp project, but it looks like it's a handful of developers at best.

GiorgioG on 11 Apr 2017

@21c-HK >since you could (in theory) target iOS and other native-only platforms without having to use Xamarin.

Whats the problem using Xamarin and F# for that?

7sharp9 on 11 Apr 2017

Xamarin.

21c-HK on 11 Apr 2017

@21c-HK Thanks for that. I guess you here for the troll factor rather than adding anything meaningful.

7sharp9 on 11 Apr 2017

😄1

@7sharp9 how is @21c-HK 's comment any more/less constructive than Krzysztof-Cieslak's comment about VS Code which was cheered & up-voted earlier in this thread?:

but it's not Visual Studio

That's the biggest advantage.

GiorgioG on 11 Apr 2017

Yeah.... i totally wonder what's the difference.

Krzysztof-Cieslak on 11 Apr 2017

Yeah.... i totally wonder what's the difference.

Another non-trolling, constructive response.

So I'll follow up and finish with my own: F# is doomed to remain a footnote in the functional programming world due to Microsoft's half-hearted interest - which is sad because it's so much better than the more popular languages. Take care folks.

GiorgioG on 11 Apr 2017

See you!

Krzysztof-Cieslak on 11 Apr 2017

I'll summarize what happened since my last (serious) post:

@GiorgioG made a few examples to explain why F# is treated as a second-class citizen by Microsoft.
@cartermp made a few examples to illustrate how much Microsoft has invested into F# and that it is therefore not a second-class citizen.
@GiorgioG emphasized that this does not disprove the fact that the F# team is still understaffed (regardless of the impressive results due to the incredible productivity of the F# team and open source community).
I couldn't resist commenting with "Xamarin." to the question why Xamarin and F# could not be used to target iOS and other native-only platforms 😄. I was (rightfully) called a troll. I apologize. I was only half-trolling: It was meant half-jokingly and I was hoping that it would not be taken seriously. Half-jokingly because I do hope to target iOS and other native-only platforms without lots of additional tooling in the future. But it was not meant to criticize Xamarin. Xamarin is definitely the best mobile platform for .NET and F# right now and what the Xamarin team is doing is really amazing. Xamarin are actually really F#-friendly (i.e. in terms of spirit and actual F# support in their tools) and seem to have a lot more resources. Example: They have AOT compilation of F# code already working.

And that leads me to my other (actually serious) suggestion: @dsyme, @cartermp or who ever can manage to pull it off should go to @migueldeicaza and borrow a few (read as: 10 or more) of his developers in his team while the F# team is understaffed. Then also hire the open source developers that were partly responsible for making F# 4.1 happen and put them on @migueldeicaza's pay roll. I don't think Xamarin would notice 😄 .

21c-HK on 11 Apr 2017

I think this thread has run it's useful course.

Thanks for all of the contributions, suggestions and Ideas.

Kevin

KevinRansom on 11 Apr 2017

Fsharp: How to drive F# Adoption - Part 4

Awareness

Out-of-box-experience

Guidance

Target Audience

Portability

Most helpful comment

All 182 comments

1284 is a bit blocking though, also #1056.

Quotes from earlier discussion:

Related issues