4 ms·

I hate to be a negative guy. I have actually read some chapters of that book - thanks for links, I do appreciate. Maybe the problem is that my job is DB + GUI +

I hate to be a negative guy. I have actually read some chapters of that book - thanks for links, I do appreciate. Maybe the problem is that my job is DB + GUI + simple business logic type of projects. Which is probably similar to most other jobs these days. I would love to work for Blue Mountain Capital but I don't. I am the only one in the team who thinks F# could be useful and had to defend using Maybe monad in C#! The only strong use case I have found so far for F# is building DSLs. Even then I would personally prefer an external DSL built with ANTLR or other proper language work-bench. PS: that F# ReSharper project is actually dead, last update was months ago. I don't understand why Microsoft won't pay JetBrains to add support. I don't understand why Microsoft won't make a Roslyn for F#. No, instead poor F# team guys have to talk to community to build some basic OOS IDE.

profquail 13y ago
Do you use WPF for your GUI programming? GUI isn't one of F#'s strengths -- it doesn't have all of the fancy codegen tools C# does -- but Dmitry Morozov has built some excellent tools for working with WPF in F#: https://github.com/dmitry-a-morozov/fsharp-wpf-mvc-series/wiki https://github.com/dmitry-a-morozov/fsharp-wpf-mvc-series/wi... Database-oriented programming in F# is pretty good from F# 3.0 onwards, thanks to a few minor language improvements and the major addition of Type Providers. F# 3.0 ships with a type provider which interops with the standard classes in System.Data.SqlClient and another which interops with Entity Framework. See: http://msdn.microsoft.com/en-us/library/vstudio/hh361035.aspx http://msdn.microsoft.com/en-us/library/vstudio/hh361035.asp... Dmitry (whose WPF framework I mentioned) has also written another type provider which provides strongly-typed access to all kinds of stuff (e.g., stored procedures) if you happen to use SQL Server as your database: https://github.com/dmitry-a-morozov/FSharp.Data.SqlCommandTypeProvider https://github.com/dmitry-a-morozov/FSharp.Data.SqlCommandTy... C# and it's related tools are very solid and have much momentum and marketing muscle behind them, so it's understandable that some developers (e.g., your co-workers) might feel uncomfortable learning something new. I've found the best way to convince people is to start writing little bits and pieces of your work, like small tools or minor libraries, in F#; when it turns out they have few, if any, bugs that usually does a good job of convincing people F# is worth taking another look at.
MichaelGG 13y ago
On the contrary: Even for these boring apps, using F# means you'll have a lot less code. C# only really wins if you're using the GUI designers. I converted a C# application to F# manually, preserving the C# style. I needed 1/20th the number of type annotations. I've done ASP.NET MVC apps using F# and find it far lighter-weight to write controllers. And the neat thing is that while using F#, even as a lightweight C#, you'll start using better abstractions because they're so easy. If you can, write some projects in F#. I've found the best way to convert people is just to enjoy how little code's required to get things done, which makes them jealous and they'll switch.

profquail 13y ago

Do you use WPF for your GUI programming? GUI isn't one of F#'s strengths -- it doesn't have all of the fancy codegen tools C# does -- but Dmitry Morozov has built some excellent tools for working with WPF in F#: https://github.com/dmitry-a-morozov/fsharp-wpf-mvc-series/wiki https://github.com/dmitry-a-morozov/fsharp-wpf-mvc-series/wi... Database-oriented programming in F# is pretty good from F# 3.0 onwards, thanks to a few minor language improvements and the major addition of Type Providers. F# 3.0 ships with a type provider which interops with the standard classes in System.Data.SqlClient and another which interops with Entity Framework. See: http://msdn.microsoft.com/en-us/library/vstudio/hh361035.aspx http://msdn.microsoft.com/en-us/library/vstudio/hh361035.asp... Dmitry (whose WPF framework I mentioned) has also written another type provider which provides strongly-typed access to all kinds of stuff (e.g., stored procedures) if you happen to use SQL Server as your database: https://github.com/dmitry-a-morozov/FSharp.Data.SqlCommandTypeProvider https://github.com/dmitry-a-morozov/FSharp.Data.SqlCommandTy... C# and it's related tools are very solid and have much momentum and marketing muscle behind them, so it's understandable that some developers (e.g., your co-workers) might feel uncomfortable learning something new. I've found the best way to convince people is to start writing little bits and pieces of your work, like small tools or minor libraries, in F#; when it turns out they have few, if any, bugs that usually does a good job of convincing people F# is worth taking another look at.

MichaelGG 13y ago

On the contrary: Even for these boring apps, using F# means you'll have a lot less code. C# only really wins if you're using the GUI designers. I converted a C# application to F# manually, preserving the C# style. I needed 1/20th the number of type annotations. I've done ASP.NET MVC apps using F# and find it far lighter-weight to write controllers. And the neat thing is that while using F#, even as a lightweight C#, you'll start using better abstractions because they're so easy. If you can, write some projects in F#. I've found the best way to convert people is just to enjoy how little code's required to get things done, which makes them jealous and they'll switch.