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

Being able to simultaneously develop in an imperative language (C#) and also a functional language (F#) at the same time on a project can be very appealing depending on what one is doing. With .net or mono, it makes it pretty easy to switch between them.

Sometimes I like having the power to use a functional language for a certain task, but would rather not develop an entire project with one. C# does have functional abilities (Linq), but it's not quite the same.




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.


This is what I did with WcfStorm.Server and WcfStorm.Rest (http://www.wcfstorm.com). The UI layer was written in C#; all other layers in F#. Switching back and forth though between an OO and an FP language (at least from my experience) is not that easy. There were a few instances where I ended up writing a class with mutable properties in F# simply because I didnt want to break my chain of thought so that I can get a feature out quickly


Yeah! I love using as many languages as possible with my projects too, that way I can raise the "barrier to entry" to a codebase as high as possible--which comes in really handy if, for example, other folks you work with would otherwise hit you with drive-by craptacular changes that break your pristine codebase (that with any luck you have to clean up yourself afterwards). Also, lets not forget about another nice side-effect: added job security.




Applications are open for YC Winter 2020

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

Search: