Hacker News Reader

Comment by Touche | Hacker News Reader

But why do things "near functional" when you have F# which is fully functional?

This argument of purity of ideology reminds me more than a bit of the Salon system of French art. Unless your style was absolutely to their liking, your work was deemed refusé. Sometimes doing things in an imperative style, even with state and all the baggage that comes with it, results in easier to read and debug code.

I post a few threads down why I prefer F#, and none of my reasons are for "purity", you should check it out: https://news.ycombinator.com/item?id=7048522

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&...

And someone has to maintain your near functional or functional code

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.

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 ;)

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/

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.

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.

The GP was speaking from the standpoint of the business rather than that of the developer.

Because programming languages are tools. You can take good parts of functional languages and do it in non-functional languages.

Yes. Exactly. This is like saying visual basic does classes.

Sure, it does, but why would you use it like that?

Because you're already using C# and it can?

Can't you mix C# and F# in the same project though?

Often mixing them in the same project will result is much less natural code. The above is pretty straightforward.

Yes, but that's a bit pointless since you can do the same thing in both languages, it's just F#'s syntax is cleaner.

No you can't, you can use two different projects, but it's a bad solution in most cases.

F# syntax is still a little confusing in the beginning, mostly because it does so much with so little syntax. And every time I'm using F# I seem to run into weird problems around indentation.

I like F# though. But I think it takes some getting used to, and I'm not quite there yet. :)

Keep at it, though! F# does take a bit of getting used to if you're coming from C# or Java, but it doesn't take long -- maybe a week of writing it full-time, two at most -- before you're roughly as productive in F# as you are in other languages. From there, the sky's the limit :)

1. Because my management won't let me. 2. Because nobody cares enough about F# to get the tools right (e.g. no ReSharper, no Roslyn for F# on horizon), it feels like a second class citizen even in MS land.

Reply on news.ycombinator.com