7 ms·

I'd really like to know the negatives of this approach. I want to introduce F# to my workplace. I have the authority to do it but lack the experience to back i

by xupybd 5y ago

I'd really like to know the negatives of this approach. I want to introduce F# to my workplace. I have the authority to do it but lack the experience to back it up. I don't want to cost the company mega dollars down the road so I don't want to make a bad call. But to me F# leads to a more reliable solution. It's like programming with training wheels. You can setup the types to make it very hard for programming mistakes to slip in. Of course you can also have a style that lets about anything fly. With the right approach I feel more confident that my solutions will by robust and less buggy when using F#.

yen223 5y ago
The issue you will face with using a relatively niche language is development velocity, i.e. the speed at which you can deliver product features. Niche languages generally have a smaller ecosystem, less documentation, more bugs (due to fewer eyeballs looking at the bugs), and a smaller pool of developer candidates. All of which means projects in those languages will take longer to build than the same project in a mainstream language. If using F# means projects are going to take 2x longer to write because the limited ecosystem means you wind up having to build everything from scratch, or because you have to rewrite a large portion of the code to workaround a quirk in the type-checker that was never fixed, those are project-killing problems. I'm not saying you can't make it work, but those are the hurdles that you'll have to overcome just to be at the same level as a mainstream language. You have to be absolutely sure that the advantages that F# brings is more than enough to overcome that.
- nestorD 5y ago
  F# is helped by the easy interoperability with C#: you can call any C# library without problems (you might however want to write a small wraper to reduce friction with F#).
  - pjmlp 5y ago
    Not any, rather most of them. F# doesn't support all .NET features. Try to subclass and override protected members.
- xupybd 5y ago
  I guess that comes down to the real speed impact. A factor of two will kill the idea of using F#. A factor of 1.2 might be okay. It all depends on the pay off. If the bug rate is as reduced as I have seen with my own tinkering then it will be worth rebuilding somethings from scratch. But I don't know how you justify the risk when there are other mainstream languages that do the job.
- yawaramin 5y ago
  I think we should be careful about throwing around numbers when we have no idea of the actual situation. For example, if we look at the Total Cost of Ownership of the project, it may turn out that after the ramp of onboarding and initial development has been climbed, it's relatively much faster and cheaper over time to add new features and maintain an existing OCaml or F# project, because its language features highly encourage maintainability and 'clean code'. It may also be the case that because of type system features like exhaustive pattern matching and abstract types or units of measure, or compile-time code generation, F#/OCaml prevent and save the project from many bugs and incidents which might have plagued the C# project. Also it may happen that the fact of using OCaml/F# may attract tech talent who may not have otherwise considered your company. There are many variables and the answer is not really clear-cut.
- scns 5y ago
  Sadly i don't have a link, but i read somewhere about a project written in C# by 5 devs in 7 years. Same project gets rewritten F# by 3 devs without prior experience with it in 2 years. Yes it is easier to rewrite than build from scratch but still pretty impressive IMHO.
urthor 5y ago
Generally speaking the negatives come in as recruitment. How do you, say, recruit a senior Haskell developer? Or a senior Haskell developer who's good fun to have around the office? With great difficulty.
- mrslave 5y ago
  Out of curiosity, of which languages do you think programmers are the most fun to have around? This could be a really fun blog post, or descend into MBTI-style memes. I'd love to read a study about this. Perhaps tie it into probability lift for venture capital like the other article on the front page today.
  - urthor 5y ago
    I think it's so much about the crowd who gets into those languages. But there are absolutely Java developers who are about the good times as much as Ruby developers. They're just outnumbered, but they're there if you look hard enough. I find the good people are there for every language, because the best people are polyglot programmers. I only refer to F# and Haskell like this because those communities are small. You can easily meet and greet every single developer who's publicly committed more than 500 lines of Haskell to GitHub in your entire (small) country, by going to a convention.
  - ilrwbwrkhv 5y ago
    Ruby developers are usually the nicest and write the best code. Java developers are dime a dozen. Typescript developers are pragmatic and will get the job done but have no taste. Lispers are special.
    - deleted 5y ago
      [deleted]
    - mbrodersen 5y ago
      What a simple minded world view. Do you also believe that “all Americans are …” and “all non-whites are …”?
yawaramin 5y ago
I think Scott Wlaschin has you covered there: https://fsharpforfunandprofit.com/posts/low-risk-ways-to-use-fsharp-at-work/ https://fsharpforfunandprofit.com/posts/low-risk-ways-to-use...
- xupybd 5y ago
  Yes that is the sort of thing I have been doing. All the little scripts that won't last more than a year or two are in F#. None of these would take longer than a day to re-write in C#.
LAC-Tech 5y ago
As someone who has a lot of time for OCaml - I'm honestly not so big on F# anymore. You end up having to use .NET Objects in F# because their modules are so limited compared to OCamls. And at that point I figure why not just use C# - which is a lot more expressive than it used to be - and have a lot less friction using the .NET ecosystem?
- bob1029 5y ago
  > And at that point I figure why not just use C# - which is a lot more expressive than it used to be This is what we do. LINQ and switch expressions wherever feasible. We also integrated a special dialect of SQL into our product which gives us a functional way to specify new views of business state.
  - LAC-Tech 5y ago
    Big thing I miss from F# is Option and Either types. You can make both in under 100 LOC in C# but then you have to explain to people how they work or write comprehensive docs. Also, it feels more natural to me to use dynamic dispatch instead of pattern matching with C#, but I realise the "C# is pure OO" ship sailed a long time ago
    - pjmlp 5y ago
      While not the same, you can use nullable for that, but you will get some weird look from C# devs.
      - bob1029 5y ago
        I make a really big deal about proper use of null in our C# codebase. Getting this right is not hard, just monotonous. Recent language features make enforcing this significantly easier than in the past. Any time something isn't quite right I can expect to find a green squiggle under the offending code, assuming I have declared all of my types accurately. The only type in our codebase I don't put a ? on would be string. We have very thorough utilization of string.IsNullOrWhiteSpace() throughout, as we prefer the semantics of this for how our application works.
MathMonkeyMan 5y ago
I worked on the team that used the OCaml-based product, but never wrote a line of OCaml (oh well...). Everyone who worked with the OCaml code was at first bewildered, but then wished they could write everything that way. The story was that the company bought some code that was written in OCaml, and so OCaml-in-house began. One of the cameliest devs I know is now writing some Swift, and he says that it has everything an OCaml-lover needs, so you might consider that as well.
frozenport 5y ago
We tried to write a compiler in a functional language and it went too slow, took too long to write, was hard to find developers. Then half the programers fled, and we had to switch to an adult approach. Now everything is going great. Once in a while a new hires asks whey we didn't write the compiler in a language suited for compiler development, like say Haskell.
- yawaramin 5y ago
  Given that many people have found FP languages with algebraic data types excellent for implementing compilers, I am willing to bet it was more of a team issue than a technology issue :-)
  - xupybd 5y ago
    > Then half the programers fled It does sound like something was going on that went beyond the choice of languages.
  - frozenport 5y ago
    Ends up being slow for no reason other than a fetishism for FP. Take a look at LLVM. Its C++.
pjmlp 5y ago
As someone that likes F# and seldom uses, the fact it is a third class citizen on .NET tooling makes it hard to justify its adoption in many .NET projects. If you want to be sure regardless of solutions vendors or framework, there is always tooling available, including Visual Studio plugins, then only C# offers that. VB comes second after that, due its history on Microsoft tooling, and by being developed alongside in the same Roslyn infrastructure. C++/CLI gets all the low level goodies, however since it is Windows only and probably due to Midori and Singularity efforts, C# is increasingly getting the same capabilities. Then at the end comes F#, mostly developed outside of Microsoft, with its own frameworks, doesn't support all .NET features because F# knows better (e.g. protected members) and its advocates don't get enterprise, for example, I don't want to see yet another example of using type providers with World database, show me how to use EF with WPF, Sitecore renderings, SharePoint WebParts, WinUI, ... The most recent strategy is to try to go after Python and Julia, which I wish them all the luck, but I am not convinced it will work out.
- throw868788 5y ago
  I don't think the risk is that bad. Especially if you are using .NET Core as a cross platform target most of the tooling is made for Windows anyway so is mostly unaccessible. VS Code for example works reasonably as good as any other VS extension - in my experience works better than the Java one. For a functional language it has a pretty good tooling story. For the standard Docker microservice (e.g. ASP.NET Core, GRPC, etc stack) the tooling is more than adequate. F# is mostly a superset of C# features these days with a much smaller lag in gaps than the other way around. On the protected members it isn't the biggest issue either - you can still override the method in your app code but it just changes it to public instead for the derived class. For interoperability to override C# classes it works and you wouldn't normally notice any difference; and in F# code you tend not to use the pattern anyway preferring composition to large object hierarchies. So your not blocked from overriding protected members on derived classes if you need to get a method overriden in a 3rd party C# library. You may be giving the impression that there is missing capability from F# that will cause risk and block your project. Given I've used it professionally I don't think that's actually the case - it won't block you from developing anything that you couldn't do in C#. At worse case - if you actually want to use the really edge case C# features you can always create another project just for that bit of code and call it from F# code given the good interoperability. There's usually ways around this too.

by xupybd 5y ago

yen223 5y ago

The issue you will face with using a relatively niche language is development velocity, i.e. the speed at which you can deliver product features. Niche languages generally have a smaller ecosystem, less documentation, more bugs (due to fewer eyeballs looking at the bugs), and a smaller pool of developer candidates. All of which means projects in those languages will take longer to build than the same project in a mainstream language. If using F# means projects are going to take 2x longer to write because the limited ecosystem means you wind up having to build everything from scratch, or because you have to rewrite a large portion of the code to workaround a quirk in the type-checker that was never fixed, those are project-killing problems. I'm not saying you can't make it work, but those are the hurdles that you'll have to overcome just to be at the same level as a mainstream language. You have to be absolutely sure that the advantages that F# brings is more than enough to overcome that.

nestorD 5y ago
F# is helped by the easy interoperability with C#: you can call any C# library without problems (you might however want to write a small wraper to reduce friction with F#).
- pjmlp 5y ago
  Not any, rather most of them. F# doesn't support all .NET features. Try to subclass and override protected members.
xupybd 5y ago
I guess that comes down to the real speed impact. A factor of two will kill the idea of using F#. A factor of 1.2 might be okay. It all depends on the pay off. If the bug rate is as reduced as I have seen with my own tinkering then it will be worth rebuilding somethings from scratch. But I don't know how you justify the risk when there are other mainstream languages that do the job.
yawaramin 5y ago
I think we should be careful about throwing around numbers when we have no idea of the actual situation. For example, if we look at the Total Cost of Ownership of the project, it may turn out that after the ramp of onboarding and initial development has been climbed, it's relatively much faster and cheaper over time to add new features and maintain an existing OCaml or F# project, because its language features highly encourage maintainability and 'clean code'. It may also be the case that because of type system features like exhaustive pattern matching and abstract types or units of measure, or compile-time code generation, F#/OCaml prevent and save the project from many bugs and incidents which might have plagued the C# project. Also it may happen that the fact of using OCaml/F# may attract tech talent who may not have otherwise considered your company. There are many variables and the answer is not really clear-cut.
scns 5y ago
Sadly i don't have a link, but i read somewhere about a project written in C# by 5 devs in 7 years. Same project gets rewritten F# by 3 devs without prior experience with it in 2 years. Yes it is easier to rewrite than build from scratch but still pretty impressive IMHO.

urthor 5y ago

Generally speaking the negatives come in as recruitment. How do you, say, recruit a senior Haskell developer? Or a senior Haskell developer who's good fun to have around the office? With great difficulty.

mrslave 5y ago
Out of curiosity, of which languages do you think programmers are the most fun to have around? This could be a really fun blog post, or descend into MBTI-style memes. I'd love to read a study about this. Perhaps tie it into probability lift for venture capital like the other article on the front page today.
- urthor 5y ago
  I think it's so much about the crowd who gets into those languages. But there are absolutely Java developers who are about the good times as much as Ruby developers. They're just outnumbered, but they're there if you look hard enough. I find the good people are there for every language, because the best people are polyglot programmers. I only refer to F# and Haskell like this because those communities are small. You can easily meet and greet every single developer who's publicly committed more than 500 lines of Haskell to GitHub in your entire (small) country, by going to a convention.
- ilrwbwrkhv 5y ago
  Ruby developers are usually the nicest and write the best code. Java developers are dime a dozen. Typescript developers are pragmatic and will get the job done but have no taste. Lispers are special.
  - deleted 5y ago
    [deleted]
  - mbrodersen 5y ago
    What a simple minded world view. Do you also believe that “all Americans are …” and “all non-whites are …”?

yawaramin 5y ago

I think Scott Wlaschin has you covered there: https://fsharpforfunandprofit.com/posts/low-risk-ways-to-use-fsharp-at-work/ https://fsharpforfunandprofit.com/posts/low-risk-ways-to-use...

xupybd 5y ago
Yes that is the sort of thing I have been doing. All the little scripts that won't last more than a year or two are in F#. None of these would take longer than a day to re-write in C#.

LAC-Tech 5y ago

As someone who has a lot of time for OCaml - I'm honestly not so big on F# anymore. You end up having to use .NET Objects in F# because their modules are so limited compared to OCamls. And at that point I figure why not just use C# - which is a lot more expressive than it used to be - and have a lot less friction using the .NET ecosystem?

bob1029 5y ago
> And at that point I figure why not just use C# - which is a lot more expressive than it used to be This is what we do. LINQ and switch expressions wherever feasible. We also integrated a special dialect of SQL into our product which gives us a functional way to specify new views of business state.
- LAC-Tech 5y ago
  Big thing I miss from F# is Option and Either types. You can make both in under 100 LOC in C# but then you have to explain to people how they work or write comprehensive docs. Also, it feels more natural to me to use dynamic dispatch instead of pattern matching with C#, but I realise the "C# is pure OO" ship sailed a long time ago
  - pjmlp 5y ago
    While not the same, you can use nullable for that, but you will get some weird look from C# devs.
    - bob1029 5y ago
      I make a really big deal about proper use of null in our C# codebase. Getting this right is not hard, just monotonous. Recent language features make enforcing this significantly easier than in the past. Any time something isn't quite right I can expect to find a green squiggle under the offending code, assuming I have declared all of my types accurately. The only type in our codebase I don't put a ? on would be string. We have very thorough utilization of string.IsNullOrWhiteSpace() throughout, as we prefer the semantics of this for how our application works.

MathMonkeyMan 5y ago

I worked on the team that used the OCaml-based product, but never wrote a line of OCaml (oh well...). Everyone who worked with the OCaml code was at first bewildered, but then wished they could write everything that way. The story was that the company bought some code that was written in OCaml, and so OCaml-in-house began. One of the cameliest devs I know is now writing some Swift, and he says that it has everything an OCaml-lover needs, so you might consider that as well.

frozenport 5y ago

We tried to write a compiler in a functional language and it went too slow, took too long to write, was hard to find developers. Then half the programers fled, and we had to switch to an adult approach. Now everything is going great. Once in a while a new hires asks whey we didn't write the compiler in a language suited for compiler development, like say Haskell.

yawaramin 5y ago
Given that many people have found FP languages with algebraic data types excellent for implementing compilers, I am willing to bet it was more of a team issue than a technology issue :-)
- xupybd 5y ago
  > Then half the programers fled It does sound like something was going on that went beyond the choice of languages.
- frozenport 5y ago
  Ends up being slow for no reason other than a fetishism for FP. Take a look at LLVM. Its C++.

pjmlp 5y ago

As someone that likes F# and seldom uses, the fact it is a third class citizen on .NET tooling makes it hard to justify its adoption in many .NET projects. If you want to be sure regardless of solutions vendors or framework, there is always tooling available, including Visual Studio plugins, then only C# offers that. VB comes second after that, due its history on Microsoft tooling, and by being developed alongside in the same Roslyn infrastructure. C++/CLI gets all the low level goodies, however since it is Windows only and probably due to Midori and Singularity efforts, C# is increasingly getting the same capabilities. Then at the end comes F#, mostly developed outside of Microsoft, with its own frameworks, doesn't support all .NET features because F# knows better (e.g. protected members) and its advocates don't get enterprise, for example, I don't want to see yet another example of using type providers with World database, show me how to use EF with WPF, Sitecore renderings, SharePoint WebParts, WinUI, ... The most recent strategy is to try to go after Python and Julia, which I wish them all the luck, but I am not convinced it will work out.

throw868788 5y ago
I don't think the risk is that bad. Especially if you are using .NET Core as a cross platform target most of the tooling is made for Windows anyway so is mostly unaccessible. VS Code for example works reasonably as good as any other VS extension - in my experience works better than the Java one. For a functional language it has a pretty good tooling story. For the standard Docker microservice (e.g. ASP.NET Core, GRPC, etc stack) the tooling is more than adequate. F# is mostly a superset of C# features these days with a much smaller lag in gaps than the other way around. On the protected members it isn't the biggest issue either - you can still override the method in your app code but it just changes it to public instead for the derived class. For interoperability to override C# classes it works and you wouldn't normally notice any difference; and in F# code you tend not to use the pattern anyway preferring composition to large object hierarchies. So your not blocked from overriding protected members on derived classes if you need to get a method overriden in a 3rd party C# library. You may be giving the impression that there is missing capability from F# that will cause risk and block your project. Given I've used it professionally I don't think that's actually the case - it won't block you from developing anything that you couldn't do in C#. At worse case - if you actually want to use the really edge case C# features you can always create another project just for that bit of code and call it from F# code given the good interoperability. There's usually ways around this too.