3 ms·

Because "near functional" is sufficient most of the time and if there is no compelling reason to split your codebase among two different languages, you shouldn'

by V-2 13y ago

Because "near functional" is sufficient most of the time and if there is no compelling reason to split your codebase among two different languages, you shouldn't do it. Not to mention that there's probably 1000 C# developers for every F# developer Have a look at http://www.indeed.com/jobanalytics/jobtrends?q=c%23%2C+f%23&l= http://www.indeed.com/jobanalytics/jobtrends?q=c%23%2C+f%23&... And someone has to maintain your near functional or functional code

altreal 13y ago
I used to use this argument and only now I realize how flawed it was. At some point there were 1000 COBOL programmers for every <your favorite language> programmers. If you decide to go with COBOL career, you will be maintaining bad software for years.
- jaredsohn 13y ago
  The GP was speaking from the standpoint of the business rather than that of the developer.
profquail 13y ago
The easy solution -- take a few of your best C# developers and give them two weeks to learn F# and build a small project with it. You don't have to hire developers from outside to bring new technologies into a company. In fact, given the scarcity (i.e., demand > supply) of good developers these days, it's almost certainly going to be easier and faster to have your existing development staff learn those new technologies vs. trying to hire new developers with experience in those technologies.
- JackMorgan 13y ago
  This is one of the reasons I think F# is such a powerful tool. It is so simple, consistent, and safe I found it very easy to learn quickly. I think I actually spent more time learning Entity Framework than I did learning F#, and EF still catches me with weird edge cases. Meanwhile F#'s crazy smart compiler is catching all mine ;)
JackMorgan 13y ago
The compelling reason for me is F#'s compiler is far smarter, catching entire types of bugs that the C# compiler will not. For example, if you use option types, you can almost entirely eliminate null reference exceptions, as the compiler will complain about misuse of an option. The lack of default circular references on types enforces a real layered architecture, so you can open up any F# project and read it top to bottom, with the lowest layers coming first. This post has a great explanation of that feature: http://fsharpforfunandprofit.com/posts/cyclic-dependencies/ http://fsharpforfunandprofit.com/posts/cyclic-dependencies/ Also, with default immutability, type providers, and less boilerplate I feel a lot more confident with the quality of the code I write, and I am able to write it faster. Since it's possible to do full C#-style OO in F#, I personally don't see a reason to use C# at all. F# is more supporting of a multi paradigm codebase, it's safer, and requires less code to do the same things as C#. Combine that with what I would consider to be an extremely short learning curve, I am happy finding C# programmers and letting them learn F# the first week of the job.

by V-2 13y ago

altreal 13y ago

I used to use this argument and only now I realize how flawed it was. At some point there were 1000 COBOL programmers for every <your favorite language> programmers. If you decide to go with COBOL career, you will be maintaining bad software for years.

jaredsohn 13y ago
The GP was speaking from the standpoint of the business rather than that of the developer.

profquail 13y ago

The easy solution -- take a few of your best C# developers and give them two weeks to learn F# and build a small project with it. You don't have to hire developers from outside to bring new technologies into a company. In fact, given the scarcity (i.e., demand > supply) of good developers these days, it's almost certainly going to be easier and faster to have your existing development staff learn those new technologies vs. trying to hire new developers with experience in those technologies.

JackMorgan 13y ago
This is one of the reasons I think F# is such a powerful tool. It is so simple, consistent, and safe I found it very easy to learn quickly. I think I actually spent more time learning Entity Framework than I did learning F#, and EF still catches me with weird edge cases. Meanwhile F#'s crazy smart compiler is catching all mine ;)

JackMorgan 13y ago

The compelling reason for me is F#'s compiler is far smarter, catching entire types of bugs that the C# compiler will not. For example, if you use option types, you can almost entirely eliminate null reference exceptions, as the compiler will complain about misuse of an option. The lack of default circular references on types enforces a real layered architecture, so you can open up any F# project and read it top to bottom, with the lowest layers coming first. This post has a great explanation of that feature: http://fsharpforfunandprofit.com/posts/cyclic-dependencies/ http://fsharpforfunandprofit.com/posts/cyclic-dependencies/ Also, with default immutability, type providers, and less boilerplate I feel a lot more confident with the quality of the code I write, and I am able to write it faster. Since it's possible to do full C#-style OO in F#, I personally don't see a reason to use C# at all. F# is more supporting of a multi paradigm codebase, it's safer, and requires less code to do the same things as C#. Combine that with what I would consider to be an extremely short learning curve, I am happy finding C# programmers and letting them learn F# the first week of the job.