Brainstorm: Identification of new application possibilities

[SchlenkR]

In my work as a consultant, I have found that it is difficult to convince people of the benefits of using F#. For a long time, I have looked at the arguments in the resulting discussions and tried to understand which mechanisms in the stakeholders' deliberations actually tip the scales in favor of or against the use of F#. Valuable insights can be gained in the process - but ultimately it always comes down to the question, "Do we deploy F#: Yes or No?". The stakes are high for decision makers (who, in my experience, tend to be risk averse). Despite many arguments, the promise of becoming "better" (more efficient, more robust, etc.) by using F# is just that: a promise - which needs to be trusted a lot. Meanwhile, the risk associated with trust, of being accused of making a bad decision regarding the choice of technology if the project fails, is tangible and weighty. That is why I think that the questions should not be about using F# as a "major player" in the project at all, but only partially. There are already possibilities for partial use: One can develop single, smaller sub-projects in F#, tests or scripts can be written in F#, etc. All of this carries much less risk and gives stakeholders a chance to experience the benefits firsthand. From this experience, I suggest that we look for more such deployment opportunities or improve the existing ones with the goal of offering F# in small "bites" that then get bigger and bigger. The focus should not necessarily be on the language, but on its possible uses in everyday development.

Brainstorming:

• Fine-grained interactive: Example: In an existing C# project, which involves the optimization of transport paths, a lot of data has to be loaded into memory for test purposes - which takes a long time. The use of F# interactive brings advantages here, but this is offset by the possibility of writing C# Unittests. The argument here is "I'd rather take my C# skills as a developer and write tests instead of doing it in F#". The advantage of F# Interactive, to develop interactively, does not hold water, because there is no interactive development at all (development is done in C#). However, the problem from a developer's point of view is the long loading times that occur with every code change and the subsequent test run. This is where I see potential: if instead of the "Coding-CompileAll-LoadContext-RunTest" cycle, you could have another cycle in the form of "CompileAll-LoadContext-CycleOf(CodePartially-RunTest)", that would be a tangible benefit. Whether this is technically achievable with dotnet and what limitations apply is another matter. But maybe you will come up with other interesting ideas when thinking through this scenario.

• Inject F#: Example: Currently, I experiment with an approach for writing UIs, which might have some potential compared to current approaches available in C#. Some people think this is great, until the question comes up if you can bring the definition of the UI (and only this) into the existing C# project. The answer is a mixture of "yes" and "no": the lower UI layers can remain in C# projects and the upper ones then in an F# project, perhaps with other C# projects on top. Even though I personally think that this separation makes sense per se, the fact of suddenly having an F# projects in a Solution can be met with an intuitive rejection from people. But: Let's say you could hang a .fsx file into the existing C# project, that would be unproblematic, because that's already happening: there are Razor views, T4 templates, XAML files, WinForms files, etc. - people have no problem with that. It would not be necessary to "sell" the use of F# at all, but the advantages of a library, which would then be quite concrete and tangible. F# would then be introduced "through the back door" and project participants could be "accustomed" to it step by step. Implementing something like this is not trivial (if not impossible). But again, I think it can be worthwhile to look for pragmatic ways that may not be perfect, but open doors for such minimally invasive deployments.

For sure there are many more such ideas that are just not seen. Of course, it is important to keep an eye on the features of F# as a language and to adapt and extend them to current and modern circumstances. However, in the future I will try to focus my attention on possibilities that allow F# to be used with minimal effort - "under the radar", so to speak.

Perhaps several more ideas and interesting discussions will arise here and would be very happy to hear and them.

[WillEhrendreich]

I think it's a great idea, because I am convinced that those who would be averse to fsharp are simply unfamiliar with it, and are intimidated by the prospect of learning a whole new way to do things. If one can get it greenlit on a smaller aspect of the whole, fsharp can start being it's own apologist as people naturally get curious about how that part of things works, or they're naturally forced by necessity to learn about it because they're trying to see how it interacts with their own part.

[Lanayx]

Several examples of "tangible" cases where F# clearly wins

1. CI-time scripts. Since dotnet is usually installed on the agent for building project, it is very easy to just write some simple fsx file that does some build/deploy time manipularions and run it using dotnet fsi script.fsx
2. Serverless applications. C# solutions heavily depend on DI containers which work well in long living environments, but no so well in short living ones with requirements for minimal startup time. The implicit dependency management can be done much easier and better in F# than in C#

[Xyncgas]

It can do everything C# can, without brackets

Once you start writing functions, type inference let you type less.

Functional is a new trend, not to say function can't be objects, or objects aren't lambda configurations with innate laziness due to computations being stored as the object.

A language is a language, it's up to whether your developers are bilingual not whether the languages themselves are good or bad : is chinese better than japanese?

There is preference, I would rather type english to write f#

[Xyncgas]

Inject F#:

If people wanna change implementations they gotta know the language, if they want to be a consumer they are going to consume to nuget packages, I wonder if this serves people right