How to drive F# Adoption Part 2 #803
Comments
|
My prioritisation: 3, 2, 5, 7, 4 |
|
Prioritization: 1, 2, 3, 5, 9, 7 Minimum discussion: without MS support F# simply has no future. |
|
Prioritization: 1, 2, 3, 8, 9, 7 I think 3, 5, 9 and to some extent 2 (when it deals with VS) needs a major shift from MS and are hitting the bottleneck of 1 (F# team is small, other product groups don't have F#ers), internal adoption at MS (hire more F#ers) might help to advance/optimize the core product at a greater pace. I wish MS would increasingly and consistently allocate resources to reach the same order as resources put on Roslyn/C#/VB/VS. I'm satisfied with F# but I can't push it at my workplace on major products mostly due to tooling (R# and vanilla VS) and the fact that my colleagues don't want to learn it ("C# good enough/very good", "F# code is hard to read"). |
|
My prioritisation: 1, 2, 7, 4, 8, 5 |
|
|
|
For uptake: 1, 9, 7 From experience bring F# into several .net using companies, the gotchas of "missing methods" and implicit FSharp.Core dependencies bit hard Community: 2, 4 ,6 |
|
My prioritization: 2, 7, 1, 3, 8, 9 |
|
My prioritization: 1, 3, 5, 9, 7 |
|
@KevinRansom As you know I'm absolutely for better tooling. I also maintain projects that provide some tooling and that have been effective in bringing in lots of new F# users from the enterprise. But I don't think all tooling needs to be done here. VS code, atom and many other projects use the plugin model. And even VS 2015 doesn't install F# by default anymore. @vasily-kirichenko always says better tooling means we need a much faster compiler. |
|
@KevinRansom .9. UWA support for creating truly universal apps .... for Windows.8. |
|
Here's my ordering based on their effectiveness to drive adoption of the Visual F# : 1, 3, 2, 5, 4, 9, 7, 6 Caveat: This list is from the perspective of driving adoption of Visual F# on Microsoft platforms and the Visual Studio toolchain. For Microsoft Corp that's all that really counts, which is fine. The list is different for Xamarin, or for driving adoption of F# on Linux, or F# as an open source language independent of Microsoft. Missing is "Better F# documentation for use on Microsoft platforms", especially the booming platforms like Azure, though perhaps it comes under point 1. Missing also is "better F# support in other editors" including VSCode, Atom, Emacs, .... Not everyone used VS. But I think this area is pretty well covered by the community. Again, there are other things to add for driving adoption on other platforms and toolchains. But they can be discussed elsewhere. |
|
I propose to amend item number 9 to: Because Windows 10 has more broad support for device under Universal apps, including iOT, HoloLens, Xbox, tablet, Windows 10 (mobile). And we shall focus on .NET "Generators" instead of using portable PCL model. |
|
i think these points are a nice but really difficult to execute.
This repo is really entangled ( ide, compiler, compiler service, fsi, fsharp core library ), it's not needed to have like that. Roslyn is not in the same repo as corefx for a reason. Duplicated effort:
I think it's better to try to develop with community instead of accept contribution ( patch, features ) only. My dream list 😄 |
|
1, 2, 3, 9 (Improved F# => C# interop bit), 5, 6, 8, 7, 4 |
|
I'm not a C# programmer anymore and I've not communicated with true C# programmers for a while (~3 years), so I have somewhat blurred ideas what they want these days, but still: Better adoption (among C# programmers, to be clear): 2, 5, 1 (I don't know what CoreCLR and UWA really are, so maybe C# people want them, too) Community: 2 (to some extent). Yes, I don't think other items from the list could be done by the community. About tooling. I think the idea of pulling code from VFPT to VFT isn't good, it'd be just a waste of time. Yes, it'd be nice to have single instance of compiler service running in VS process (less memory usage, less CPU load), but this is the only (and minor) benefit. BTW, this whole adoption problem could be viewed in a different perspective. Let's imagine that:
Now the question: would C# programmers switch to F#? I doubt. Because why? And because F# is unreadable for a typical "curly-braced" developer. I clearly remember what F# looks like for me several years ago: crazy condensed, unstructured mess (BTW, it's a general opinion that the famous pipe operator is extremely intuitive. No, it is not. I remember how I stared at a pipe chain for the first time and thinking: "what it is? another kind of match or what?"). So, I think the problem is that C-family languages rules the world and any ML language is not welcome. |
|
3, 2, 4, 7, 9, 6 |
|
f# core ( language, compiler, core library ) evolution should be separated from visualfsharp ( vside/tooling/msbuild/wpf/next big thing ). visualfsharp tooling (ide, msbuild) should build on top of f# core. Like xamarin studio, vs code and all other ide. Like that we can all benefit from features. Msbuild can die ( it will soon ) but compiler will not. An example is roslyn/corefx/coreclr, it's easier to add ide extensions because there is a clean cut. About c# dev, but lot dont want to use f#, is not c style, it's complicated. I like fsharp foundation approach to market f# as a standalone language (it is, but openfsharp repo is not), ms is marketing f# as class library for special case, there is no market for that, just use c# and resharper, integration is not worth it |
|
I completely agree with @vasily-kirichenko. The main "problem" with F# is that it is an ML language: things like expression-based code, indentation semantics, currying and implied parentheses are simply too alien for your average C family developer. Even if some might try to learn the language basics, getting to the stage where you are fully convinced that F# is equivalent to C# in expressive power might take some time and commitment. In other words, I'm not sure that much more can be done to improve F# adoption rates from the C# crowd. My hopes lie with CoreCLR: if it truly succeeds as a cross-platform framework, I anticipate that F# will have an influx of users with non-C# backgrounds (FP users, academics, pythonistas) who have so far been put off by the ugly cross-platform story of .NET (particularly in linux). |
+500 on every word |
|
For the curious, right now, I think 3, 2, 1, 7, 9 I'm also on the "for devs using VS on Windows" track, because IMO if you're developing on Linux to write Linux-hosted web applications (for example) you might as well just write in Haskell. F#'s primary value to me is bringing ML-family ideas into the .NET ecosystem, so I see its relevance as where .NET is already established. I work in a C# shop, we all have Visual Studio and ReSharper and we write ASP.NET MVC applications and we have to continuously write a load of bloated nonsense boilerplate that F# largely eliminates. I've never succeeded in convincing anybody else to be enthusiastic about F# at my current job, because actually we don't do anything complex enough. The classic niche for F#, as I was told by an interviewer for a job which supposedly involved F# development, was for heavy maths, and they didn't even consider using it for any other part of their application. Since my current job don't do that, I've got no way in through that route, and never could get authorisation to build a prototype pure-F# web application to demonstrate the benefits. After Christmas I start at another C# shop, this time a Microsoft gold partner. I asked about why they use C#, and the answer boiled down to "because Microsoft say so". So: evangelism. It needs the tooling to back it up, it needs the project templates, it needs the VS experience to be something impressive, but it needs Microsoft to tell gold partners that F# is here, F# is good, F# can get you this and that and the other. F# can save you typing ridiculous boilerplate. F# will save you money on replacement { keys. F# can help you produce software that has fewer bugs in it. F# can eliminate the unexpected NullReferenceException. C# developers can learn F# in X days. Whatever it takes. And, actually, mixed-language projects. Because you can't have circular project dependencies, you can't freely mix F# and C# code within a layer of your application architecture. Everything has to be carefully aligned so that no circular dependencies are required. If I could drop an F# module into the middle of a C# project and have VS just cope with it... that'd be awesome. I appreciate that's probably a massive change to the entire build system, but it's terrible anyway so I wouldn't mind! Of course the F# community can't do that themselves. Community-wise, it's about tooling provision. If Microsoft aren't willing to commit the resources internally then Microsoft-supported open source F# tools are going to have to be the way to go. Eliminate the distinction between the Power Tools and the core tools, bring them all into the open and make regular releases with improvements, including the latest version with VS updates as they come along but primarily relying on out of band updates for active F# developers to get better features as they're ready. And having said all that, I really should put some time where my mouth is and get involved - but I don't have a suitable environment for this work at home and my employer certainly isn't going to pay me for it if I can't convince them that F# itself is worthwhile, so I'm stuck in a cycle of C# dominance again. But I'll try, when I get to the new place, because the evangelism can't just come from Microsoft. |
|
1 and maybe 3. |
|
My opinion is that successful platforms and Killer apps/libs drive the adoption of languages (Unix/C, Web/javascript, IOS/Objective C, Rails/Ruby). So F# needs a successful platform and a killer app/lib for that platform. |
|
@palladin Windows is more than successful platform with ~85% of desktop computers running it. But better support of WPF applications (missing in initial list) would greatly increase F# adoption rate on Windows (esp. in enterprise software) because so far WPF apps are what 99.9% of Windows users deal with. |
|
@plepilov You also need breathing space, C# has great tooling for WPF and is already the de facto choice for client Windows/WPF development. |
|
@palladin Agree. But C# is also de-facto choice for .NET development. Functional full-featured and well supported library for building WPF apps (something like XAML type provider with VS tooling) would be in my opinion the killer library. |
|
@eiriktsarpalis @vasily-kirichenko interesting points. both of you either (a) do not come from C# background, or (b) don't actively work in C# for a number of years. You're right that the ML-style syntax is alien for a C# developer. But then again I sat in a C# talk recently about proposed features in C# 7 like pattern matching and tuple syntax and there were a lot of confused faces there anyway. I understood this thread to be really about Visual F# adoption, not F# adoption overall - surely the easiest target (and largest market) in that context is C# developers rather than e.g. Haskell / Scala / Java / Python devs? |
|
⒋FSI: Something like the Android C#Shell app or PowerShell's ISE |
|
Did you guys consider the point that maybe the issue is with the platform (.NET)? First, you have some existing long-running project which is already written in C#, so switching to another language does not make much sense for the business (you can argue about potential benefits, but I don't think that the majority of businesses are ready to switch). Second, you are starting a new project. That's where the things start getting interesting. Of course, it may be different from your perspective, but what I see around here is that the thought "let's start our new product with .NET" is considered more and more crazy every day. You've got Scala, Go, Node, Clojure, etc. for the back-end, you are also probably doing you front-end with some JS flavor, and some projects don't even need a dedicated back-end these days. Of course the platform is not dead yet, but the trend is quite pessimistic IMO, backed by the unclear platform future and all those vNext stories. So maybe it's not a not increasing adoption rate of F#, it's a decreasing adoption rate of .NET? |
That's what I meant in that other thread. People are leaving the platform and that are the people MS should try to win. Not someone who is happy with asp.net, WPF, EF, ... in C#. |
|
@forki interesting point indeed. |
It's well known that the defaults matter. They really, really matter. Let's assume 20,000 C# developers try F# every month. I'd estimate only 1% of those install the Visual F# Power Tools. It's reasonable to assume that for most of the C# developers who reject F# the paucity of the tooling is a factor in the decision (and has been for many years). Another reference point is that at every training @tpetricek does he makes everyone install VFPT. Otherwise they wouldn't, and they would think F# has no tooling. Putting the VFPT feature set into VFT by default would increase Visual F# adoption, I'm 100% sure of that. It would be a major benefit to the F# community as a whole. The efficiency angle is also important, allowing VFT/VFPT to scale to approx 2x the solution size. |
|
Very interesting discussion, @khmylov's & @forki's are touching on an important point, context. For C# devs coming to F#, fewer IDE features may be an issue (I think go to definition between C# and F# is probably the must have thing people crave in mixed solutions nowadays). For Data Scientists coming to F# with experience of Python or R, looking to add a new tool to their box, perhaps the IDE story is less of a problem, and good documentation, examples, easy data extraction, compute story, etc. may be more important. For web developers coming from Ruby, PHP or Go, perhaps easy set up on Mac and Linux with good documentation and examples and a simple opinionated web library (I think Suave fits here) could be important. Overall I think there's a bunch of different contexts where there's different requirements, and perhaps we might also want to ask the question - how can we make F# more attractive for: 2,3 & 7 |
|
I think nobody is against putting VFPT functionality into VS, but
|
|
Maybe the fastest way is to depend on the VFPT nuget package. I mean maybe we can find a way to include it without moving all the code and the build process. |
|
#1 is by far the biggest issue, period. If #1 happens, everything else basically sorts itself out. Unwanted discussion: Compare to MS's pages on C# [3] and F# [4]. C# is "general-purpose...for building apps" and allows "rapid application development". But F# is "to solve complex problems" and is suggested for "calculation engines and data-rich analytical services". This has always been MS's main public stance. F#'s for smart people doing complicated science-y things. Adding to it, anyone remotely familiar with VS or other MS APIs will see F# is left out all over the place. From lack of ASP.NET support, to MS APIs that rely on C#-specific features via reflection instead of proper designs (looking at you MVC). All this tells companies one thing: "beware". One startup I know of told me point-blank "We're afraid using F# will lower our valuation since it's not really supported." (Perhaps unfounded, but it's that kind of attitude I tend to see, a nervousness.) Until Microsoft sorts out its internal priorities/politics/whatever and truly makes a stand on F#, adoption is gonna continue to be slow, at least with traditionally .NET/MS users. No opinion on those coming from e.g. Ruby. 1: http://www.apple.com/swift/ (Ignore that Apple put effort into design, just focus on messaging) |
|
Just to confirm the suspicion regarding Suave mentioned in Part 3 - I didn't post any comment about it because I think Suave is doing very well and doesn't need any F# core changes that need to be discussed here :). The fact that it exists and works great made me stop worrying about ASP.NET support. |
|
@tpetricek I like suave too, I think that so far it is an enthusiasts tool, and making it more discoverable would be beneficial. So I would think templates, and samples discoverable from within VS might help out: VS has the new project dialog, not a suave template in sight: We could ship templates in the box that grab suave from nugget and scaffold a simple web service, a web service that talks to a sql database etc... I think we agree that people who want to try out F# should be guided to the right solutions, why not use the VS templates to make that happen? or perhaps you disagree ... and it should be obvious to someone who is just trying out the language to go and get Suave! I am interested in your thoughts on this ? |
|
My prioritisation: 7, 1, 2, 3, 5 |
|
@KevinRansom I think Suave templates is a great way to make more people interested in F#. When I started using Suave it was not due to being an enthusiast, but rather because I was trying to solve a problem. Besides that, from running a functional programming group, working as architect and CEO who interview prospective F# devs I would say 4 and then 3. |
|
1, 3, 4. Don't bother with 5, at least for the next year. My doubts have exponentially increased as work on ASP.NET vNext has progressed. Community best for (unlisted) documentation and samples. Community could be useful for templates, too, so long as we consider xplat templates. With respect to templates, I think @Krzysztof-Cieslak's Yeoman template generator is a better solution for us going forward b/c it provides an xplat template solution. Build a Yeoman tooling into the New Project dialog, and you will score major points. |
|
Prioritization: 1, 2, 4, 3, 9 |
|
Prioritisation: 3,9,5 |
|
The 10 items in the order I think will be the most effective in increasing adoption. The 10 items in the order I think the community can best deal with. |
|
I agree with @eiriktsarpalis, that the best way to drive adoption of F# is primarily though xplat support where you can bring in users with non-C# backgrounds. Related to what @enricosada was saying about organization, I think the F# Core Engineering Group should create a process like Rust RFCs process and then be given ownership of the compiler. You can see Scala is doing this and Swift has defined a Swift Evolution Process. The XPlat success depends on CoreCLR and VisualStudio Code. Type Providers need to work on CoreCLR. Improvements to Type Providers would also really help. I think Ionide is a great start to the XPlat F# story and we should look at ways to improve it (I have been). |
|
Roslyn infrastructure integration. Refactorings and analyzers must be available in F#. |
|
My priority: 2 1 3 |
|
Would love right-click -> Publish... for Visual Studio 2015. It seems silly to get hung up on this, but creating a new F# project it takes me all of ten seconds to realize I don't have it and consider going back to C#. |
|
Closing as we have a Part 3 and Part 4 to this discussion. |
and others
In "How to drive adoption part 1" #798
We collected some data here is the summary. Please review the summary and let me know if I missed something you intended to be added.
Please try to rank the 10 items in the order you think will be the most effective in converting curious F# investigators into consistent developers.
Please try to rank the 10 items in the order you think are the ones the community can best deal with.
When ranking, if you feel some items are not significant just leave them out of the ranking.
I know this seems school maam'ish of me, I apologise, but in order to get to actionable items, we need to figure out what we need to do. Your input is valued, but digressions limit the value of this exercise.
To summarize:
9.. UWA support for creating truly universal apps .... for Windows.8. Improved F# => C# interop ( enables F# libraries to be better consumed from C#)
The text was updated successfully, but these errors were encountered: