3 ms·

I keep telling myself that this is the year I'm going to really learn F#; it has a lot of the nice parts of Haskell, but is a little more on the pragmatic end,

I keep telling myself that this is the year I'm going to really learn F#; it has a lot of the nice parts of Haskell, but is a little more on the pragmatic end, and has access to the whole .NET world. The problem I run into frequently on my abortive attempts is that when things get harder, it's too easy to just drop back and smash something out in C#.

Multicomp 7y ago
Once you get used to / take for granted the additional compiler features in F#, you will find yourself weaning yourself off C# code more and more. Resistance is futile! 2019 ends my year of F# focus. In 2020, I will take a look at Rust since it is C-but-not-nearly-impossible-to-correct-insecure. Between Get Programming with F# and Domain Modelling Made Functional, I am a convert for F# and will continue using it into the future. Why? Quick example: I'm currently hacking together a program for the RPG system used in Star Wars Fantasy Flight Games, so that the game master can input possible player actions during their turns and keep track of player stats, generate NPC encounters etc. and so forth. Writing the back-end in F# (stored to SQLite) really helps me keep the game rule book (business logic) straight, with compiler-based warnings if I try to, say, stick XP into a function that expects in-game cash. On the front end, I'm using plain old Windows Forms in C#. The UI is mostly for data crunching and keyboard-first usage (I'm keeping in mind my FoxPro days and gui.cs / TUI / keyboard-first functionality from that twitter thread a few weeks back), and is mostly for gluing UI controls to the back-end itself (maybe this will be a mobile app, website, etc. in the future depending on the GM's needs). For this program, I wouldn't write any game logic in C#, now that I'm used to F#. C# lets me get away with too many mistakes compared to F#, for the same reasons JavaScript lets me get away with (even more) too many mistakes compared to C#.
thelazydogsback 7y ago
F# is my most productive language - it's hard to be beat strong typing w/type-inference, modeling with DU's, pattern matching, indent syntax (by default, unless you don't want it), and the .Net(core) lib/runtime. It's especially nice now that VSCode/VStud have plug-in's that show the inferred type signatures. The tooling is pretty good now, but there are still pain points (breakpointing/stepping pipes |>, inlines, and pattern matching expressions), but even w/that said the tooling is probably above avg. now. If you want the best refactoring and debugging experience (Resharper, OzCode, etc.) the C# is still the best there.
reikonomusha 7y ago
I would say it’s more “familiar”, not that it’s more “pragmatic”. Haskell is an entirely pragmatic language and is useful for solving very wide ranges of tasks. It’s just not very familiar to most people, in part because it doesn’t plug into a familiar ecosystem, like CLR/Java languages do.
tylorr 7y ago
The problem I've run into is it feels like the language has been abandoned. It feels close to being perfect enough but I can't shake the feeling that the final push it needs will never happen.

Multicomp 7y ago

Once you get used to / take for granted the additional compiler features in F#, you will find yourself weaning yourself off C# code more and more. Resistance is futile! 2019 ends my year of F# focus. In 2020, I will take a look at Rust since it is C-but-not-nearly-impossible-to-correct-insecure. Between Get Programming with F# and Domain Modelling Made Functional, I am a convert for F# and will continue using it into the future. Why? Quick example: I'm currently hacking together a program for the RPG system used in Star Wars Fantasy Flight Games, so that the game master can input possible player actions during their turns and keep track of player stats, generate NPC encounters etc. and so forth. Writing the back-end in F# (stored to SQLite) really helps me keep the game rule book (business logic) straight, with compiler-based warnings if I try to, say, stick XP into a function that expects in-game cash. On the front end, I'm using plain old Windows Forms in C#. The UI is mostly for data crunching and keyboard-first usage (I'm keeping in mind my FoxPro days and gui.cs / TUI / keyboard-first functionality from that twitter thread a few weeks back), and is mostly for gluing UI controls to the back-end itself (maybe this will be a mobile app, website, etc. in the future depending on the GM's needs). For this program, I wouldn't write any game logic in C#, now that I'm used to F#. C# lets me get away with too many mistakes compared to F#, for the same reasons JavaScript lets me get away with (even more) too many mistakes compared to C#.

thelazydogsback 7y ago

F# is my most productive language - it's hard to be beat strong typing w/type-inference, modeling with DU's, pattern matching, indent syntax (by default, unless you don't want it), and the .Net(core) lib/runtime. It's especially nice now that VSCode/VStud have plug-in's that show the inferred type signatures. The tooling is pretty good now, but there are still pain points (breakpointing/stepping pipes |>, inlines, and pattern matching expressions), but even w/that said the tooling is probably above avg. now. If you want the best refactoring and debugging experience (Resharper, OzCode, etc.) the C# is still the best there.

reikonomusha 7y ago

I would say it’s more “familiar”, not that it’s more “pragmatic”. Haskell is an entirely pragmatic language and is useful for solving very wide ranges of tasks. It’s just not very familiar to most people, in part because it doesn’t plug into a familiar ecosystem, like CLR/Java languages do.

tylorr 7y ago

The problem I've run into is it feels like the language has been abandoned. It feels close to being perfect enough but I can't shake the feeling that the final push it needs will never happen.