Hacker News new | past | comments | ask | show | jobs | submit login

Agreed. I recently wrote my first F# code because the boilerplate associated with emulating pattern matching/discriminated unions in C# was so unappealing. I very much like the ability to wrap a piece of pure F# code in a C# API. I actually think the resulting F# is easier to explain to another developer than a huge collection of visitor classes.

I also feel that I wouldn't want to write the whole app in F#, because I don't feel like the OO/FP approach feels as natural for some parts of the app as plain old C#.




Oh yeah, visitor would be a great example since F# has support of multiple dispatch. When I learned the Visitor pattern at the University I attended, it was one of the hardest things to wrap my head around initially until it finally clicked what it was while writing the code. It's just so counter intuitive to what most would think imperative language design is initially that it can take a bit to sink in. It seems simple enough, but trying to understand it and implement it are two different beasts. I would have gladly done it in a functional language or a Lisp variant if given the option.

Having to explain the Visitor pattern though to someone else would be much more painful than that I imagine versus just writing and explaining it in F#. The code just reads much more naturally for it, since the language supports it without a quirky design pattern.


Could you elaborate on your last sentence? Especially with F# 3, the OO features should be syntactically the same as C#. You can use F# as a light-syntax C#, really, with a few minor caveats.

For curiosity, what in particular do you find to be unnatural in F#?


I'm just not really a fan of mixing OO or imperative and FP code in the same code unit, with the exception of a few things like LINQ which might be called FP. For anything with a lot of mutation or tight loops, I'd rather stick with C#, and save myself the hassle of explaining the code to other devs later on. The idea of one language for everything is nice, but C# has carved out a place for itself, and maybe F# should try to focus on those areas where it can differentiate itself by effecting shorter, more self-describing code.


>>I actually think the resulting F# is easier to explain to another developer than a huge collection of visitor classes.

Yes. It's even possible in some cases to use F# source as some kind of pseudo-code with C#-programmers.




Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: