4 ms·

The problem with F# evangelism is that it doesn't exist. No one is evangelizing F#; everyone is evangelizing functional programming. F# is the Python of .NET -

The problem with F# evangelism is that it doesn't exist. No one is evangelizing F#; everyone is evangelizing functional programming. F# is the Python of .NET - it's multi-paradigmatic and you can do whatever you want. Sell it to people that way, and let them get into functional concepts later, or never. F# has a huge opportunity in the enterprise. A ton of enterprise C# code is not object oriented at all, it's big, poorly thought out clumps of imperative script wrapped in methods and classes so it can be compiled or fit into the framework that's calling it. Sometimes it'll get a quick last pass run on it to make it "more object oriented", because that's what C# code is supposed to be; this usually just makes it worse. It's written in a scripting mindset: the developer needs to get things done, and adds code and bangs on stuff until it compiles and looks right when it runs in the debugger. F# is actually well suited to this style of development, but it's hard to find anything about it, because every F# tutorial, book and blog post is actually about functional concepts, functional design, functional thinking and functional programming, including this one. If you want to sell F# to enterprise developers, show them how they can write their C# code in it without having to pretend that it's object oriented anymore, and how that's a good thing.

sickbeard 9y ago
Asking businesses to rewrite apps in a different language is a non-starter. It adds no value. The app is already there, written in c#. Why rewrite it in f#? There has to be some reason to write something in F#, usually the reason is functional programming, which excels in manipulating data. However most programs rarely manipulate data. They show a UI, get some input from a user or server, save, retrieve, re-display in a different form. These kinds of programs work very well when written in imperative languages compared to functional ones.
pjmlp 9y ago
> If you want to sell F# to enterprise developers, show them how they can write their C# code in it without having to pretend that it's object oriented anymore, and how that's a good thing. As enterprise consultant, for the types of customer projects I work with, lack of tooling support for Blend, WPF, UWP, EF, ASP.NET is a no-go to move from C# into F#.
- bonesss 9y ago
  Domain modelling in F# is lightyears beyond C#s. Parallel and concurrent development, not to mention actor systems (F#s built-in or Akka.net), are also leaps and bounds beyond the C# story. These are Enterprise issues. Identity management, default immutability, distate for null, and exhaustive pattern matching are all major Enteprise features that large, complex, and critical systems see measurable benefit from... There is no barrier to mingling F# and C# libs to focus on specific tasks or parts of the app. Having application libraries in C# and domain code in F# is a common pattern. Particularly at the GUI level, extra-particularly with anything that uses databinding so your domain types can be used directly. F# does not get the same amount of tooling love as C# for the "latest and greatest" from microsoft. If you look at the Enterprise track record of Microsofts "latest and greatest" since they started pushing ADO.net to present day... well, I would argue that's a huge benefit. Enterprise customers need tooling stability and platform stability, so letting ASPvReplacedInThreeMonths come and go without impacting projects is a big money saver.
  - pjmlp 9y ago
    > There is no barrier to mingling F# and C# libs to focus on specific tasks or parts of the app. Try that on .NET Native apps. > F# does not get the same amount of tooling love as C# for the "latest and greatest" from microsoft. No tooling for Blend, WPF, UWP, EF, ASP.NET, no reason to switch and suffer a productivy drop.
    - dcdcdcdc 9y ago
      I'm not a C# programmer, but it seems to me that the productivity drop argument is weird. Your engineers might be in a local maximum, and it might be worth the temporary productivity drop, if in the long run it would allow them to reach new (and better) heights. This, of course, is an outsider's supposition, and I understand that you're just conveying their point of view.
      - pjmlp 9y ago
        How it is weird having a productivity drop when everything that is done graphical by tools with a simple mouse click, must be done manually in plain code without any kind of visual assistance, beyond "compile and see how it looks like"?

sickbeard 9y ago

Asking businesses to rewrite apps in a different language is a non-starter. It adds no value. The app is already there, written in c#. Why rewrite it in f#? There has to be some reason to write something in F#, usually the reason is functional programming, which excels in manipulating data. However most programs rarely manipulate data. They show a UI, get some input from a user or server, save, retrieve, re-display in a different form. These kinds of programs work very well when written in imperative languages compared to functional ones.

pjmlp 9y ago

> If you want to sell F# to enterprise developers, show them how they can write their C# code in it without having to pretend that it's object oriented anymore, and how that's a good thing. As enterprise consultant, for the types of customer projects I work with, lack of tooling support for Blend, WPF, UWP, EF, ASP.NET is a no-go to move from C# into F#.

bonesss 9y ago
Domain modelling in F# is lightyears beyond C#s. Parallel and concurrent development, not to mention actor systems (F#s built-in or Akka.net), are also leaps and bounds beyond the C# story. These are Enterprise issues. Identity management, default immutability, distate for null, and exhaustive pattern matching are all major Enteprise features that large, complex, and critical systems see measurable benefit from... There is no barrier to mingling F# and C# libs to focus on specific tasks or parts of the app. Having application libraries in C# and domain code in F# is a common pattern. Particularly at the GUI level, extra-particularly with anything that uses databinding so your domain types can be used directly. F# does not get the same amount of tooling love as C# for the "latest and greatest" from microsoft. If you look at the Enterprise track record of Microsofts "latest and greatest" since they started pushing ADO.net to present day... well, I would argue that's a huge benefit. Enterprise customers need tooling stability and platform stability, so letting ASPvReplacedInThreeMonths come and go without impacting projects is a big money saver.
- pjmlp 9y ago
  > There is no barrier to mingling F# and C# libs to focus on specific tasks or parts of the app. Try that on .NET Native apps. > F# does not get the same amount of tooling love as C# for the "latest and greatest" from microsoft. No tooling for Blend, WPF, UWP, EF, ASP.NET, no reason to switch and suffer a productivy drop.
  - dcdcdcdc 9y ago
    I'm not a C# programmer, but it seems to me that the productivity drop argument is weird. Your engineers might be in a local maximum, and it might be worth the temporary productivity drop, if in the long run it would allow them to reach new (and better) heights. This, of course, is an outsider's supposition, and I understand that you're just conveying their point of view.
    - pjmlp 9y ago
      How it is weird having a productivity drop when everything that is done graphical by tools with a simple mouse click, must be done manually in plain code without any kind of visual assistance, beyond "compile and see how it looks like"?