5 ms·

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 a

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"?
    - dcdcdcdc 9y ago
      No, I meant that bringing this fact as an argument is weird: I'm not arguing that there's a productivity drop, I'm saying that it's only temporary. Furthermore, I have a few years of RAD development experience, and I know as well as you do that not everything may be coded with a couple of mouse clicks. As soon as you hit the business logic, you need to use the keyboard, you need to devise algorithms, you need to evaluate their complexities, and you need to code them down. That being said, even just getting used to a new language gives you new insights about coding practices.
- bonesss 9y ago
  You seem to have read past much of my comment :) > Try that on .NET Native apps. For a real-world workaround, here: https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-root https://docs.microsoft.com/en-us/windows/uwp/porting/desktop... To quote from the thread: [by] “.NET Native doesn’t support F#,” what’s meant is “.NET Native doesn’t support all of the IL produced by the Visual F# compiler.”, which is one of the MANY reasons MS is now allowing UWP variations. > No tooling for Blend, WPF, UWP, EF, ASP.NET, no reason to switch and suffer a productivy drop. This is a reply to a comment saying "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." That directly addresses what you're talking about. And, because I've done it myself: it's not entirely true what you're saying here. Those languages bind and analyze .Net objects. What you're talking about is entirely GUI level, and already recommended to take in C#. The domain modelling productivity advantages CRUSH any gui nonsense. That's before we look at stability and correctness. And error rates. And maintenance productivity. At the same time, to be blunt: there's no reasonable, scaled, approach to developing applications for any of those technologies that doesn't involve separating domain logic and GUI logic. Using DDD, MVVM, three-layered-app design, or any separation of concerns really and your app will already have the logical divisions required for a C#/F# split, so you can combine the high productivity on the back end with whatever button tweaking you require.

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"?
  - dcdcdcdc 9y ago
    No, I meant that bringing this fact as an argument is weird: I'm not arguing that there's a productivity drop, I'm saying that it's only temporary. Furthermore, I have a few years of RAD development experience, and I know as well as you do that not everything may be coded with a couple of mouse clicks. As soon as you hit the business logic, you need to use the keyboard, you need to devise algorithms, you need to evaluate their complexities, and you need to code them down. That being said, even just getting used to a new language gives you new insights about coding practices.
bonesss 9y ago
You seem to have read past much of my comment :) > Try that on .NET Native apps. For a real-world workaround, here: https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-root https://docs.microsoft.com/en-us/windows/uwp/porting/desktop... To quote from the thread: [by] “.NET Native doesn’t support F#,” what’s meant is “.NET Native doesn’t support all of the IL produced by the Visual F# compiler.”, which is one of the MANY reasons MS is now allowing UWP variations. > No tooling for Blend, WPF, UWP, EF, ASP.NET, no reason to switch and suffer a productivy drop. This is a reply to a comment saying "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." That directly addresses what you're talking about. And, because I've done it myself: it's not entirely true what you're saying here. Those languages bind and analyze .Net objects. What you're talking about is entirely GUI level, and already recommended to take in C#. The domain modelling productivity advantages CRUSH any gui nonsense. That's before we look at stability and correctness. And error rates. And maintenance productivity. At the same time, to be blunt: there's no reasonable, scaled, approach to developing applications for any of those technologies that doesn't involve separating domain logic and GUI logic. Using DDD, MVVM, three-layered-app design, or any separation of concerns really and your app will already have the logical divisions required for a C#/F# split, so you can combine the high productivity on the back end with whatever button tweaking you require.