4 ms·
Newbie here. Somebody can point to useful other resources for F#?
by marvel_boy 9y ago
Newbie here. Somebody can point to useful other resources for F#?
- voqk 9y agohttps://fsharpforfunandprofit.com/ https://fsharpforfunandprofit.com/
- oxryly1 9y agohttps://fsharpforfunandprofit.com https://fsharpforfunandprofit.com is great. I'm enjoying Don Syme's book "Expert F# 4.0" as well.
- JamesBarney 9y agoThis website if one of the best I've read, and I recommend it even if you have no interest in F#. I learned more about how to write OOP and think about types than years of reading other blogs.
- kzisme 9y agoIs there a really good reason to choose to use F# over C#? Or does it really just come down to preference?
- mookid11 9y agoIt depends if you enjoy NullPointerExceptions.
- sremani 9y agoThe returns on choosing F# are very much reliant of level of proficiency attained. Once you are proficient, you will write - less code for similar functionality - have lot less dependency cycles - using Option types over null helps in the long run - improvement in productivity The only problem is that you have attain a level of proficiency and flip the "train" of thought from OOP to Functional, and that can take some good time.
- kzisme 9y agoGotcha - thanks! I haven't touched functional languages other than for fun lately, so I may take a look sooner or later. I've always been interested.
- jackmott 9y agopros: less typing less null pointer exceptions cons: performance (doesn't have to be bad but if you do things idiomatically will tend to be) tooling and other externalities (better that most niche languages but not as good as c#)
- wyoung2 9y agoJust to add to what the others have said: 1. Immutable values by default avoids whole categories of problems. Just for one example, you can't have a data race between two threads if all the public values accessible from each thread are guaranteed immutable. 2. F# forces all cases to be handled. You've doubtless run into C# code that has a switch statement that doesn't have cases for all possible inputs, and no default case. F# doesn't have a direct equivalent of "switch" at all, but it does enforce completeness in the equivalents it does have. For example, it's illegal in F# to say something like "if foo > 1 then ... elif foo < 1 ..." since that leaves the 0 case unhandled. This is not just about better compiler warnings: it's required by the very fact that "if/else" is an expression, not a statement, so all branches must produce a value for all inputs. 3. F# has units of measure data types. Ever had an application bug because you've incorrectly passed a bare "int" value holding milliseconds to a function expecting seconds? I have. F# lets you define your units as part of the data type, so that it's a compiler error to pass milliseconds to a function expecting seconds. I could go on, but as you can see, there really are substantial differences in practice between F# and C# code.
- eddof13 9y agoSeconding the f# for fun and profit suggestions, especially the railway oriented programming section, I've also heard the following is good, but I have yet to try them: http://www.fsharpworkshop.com/ http://www.fsharpworkshop.com/ http://products.tamizhvendan.in/fsharp-applied/ http://products.tamizhvendan.in/fsharp-applied/
- rspeele 9y agoIf you are a C# developer you may appreciate these translations I've put together: https://github.com/rspeele/CSharpFSharpPhrasebook https://github.com/rspeele/CSharpFSharpPhrasebook This does not sell the language -- it doesn't show off anything interesting you can do in F# that you can't in C#. There are other resources for "why F#". This is for C# developers who are convinced that they want to learn, but are annoyed by not being able to quickly look up how to do the things that they're familiar with from C#.