Hacker News Reader

Comment by stinos | Hacker News Reader

Strange post, or maybe I'm missing the point, or is it supposed to be sarcastic? Also what's with the generalisations ('enterprise shops don't like change & non-enterprise do', come on)?

half assed versions things of F# already had (tuples, async and tasks I’m looking at you)

yes F# has those, but afaik so do a myriad of other languages. Even before F# saw the daylight. I'm also not sure what is half assed about them, the implementation seems quite complete?

a language that is afraid to change anything

coming from a post talking about new features and 'changing into F#' that's quite a contradiction, no?

View on HN

i think you're missing the point a little bit.

> yes F# has those, but afaik so do a myriad of other languages. Even before F# saw the daylight. I'm also not sure what is half assed about them, the implementation seems quite complete?

it's true, but c# advocates in microsoft have been quite parasitic in their behavior of pushing the language(inside of microsoft). they have also been averse to competition. i remember it's not too long ago, that we weren't really sure if microsoft was about to pull the plug on f# or not.

there haven't been too many clr languages, and ironpython was suffocated fairly quickly. yes you can use clojure on the clr, but who's using that, and is a meaningful customer to microsoft?

f# has been really smart in it's behavior in my opinion, by fairly quickly targeting the microsoft enterprise stack, stuff like share point, dynamics, and other crap like that.

it's also a hybrid language that is close enough to c# that you can claim c# developers can just pick it up. you could argue that good developers can pick up any language, but we're not talking about good developers here. we're talking about something that is more akin to factory work.

this is just my opinion, but i think the biggest customers of microsoft are government, government contractors, and people that sell to government contractors.

it's not about whether f# is really revolutionary or not. f# is very close to ocaml. f# is revolutionary to the microsoft enterprise stack.

asp.net mvc wasn't revolutionary either, but it was revolutionary to the .net culture.

take a look at some posts describing alt .net http://msdn.microsoft.com/en-us/magazine/cc337902.aspx

I've been using C# for close to a decade at this point (wow, wtf) and I'm fairly familiar with functional programming techniques - I use a lot of closures, immutability, and map/reduce patterns in my code - but F# is still really awkward for me to write and use compared to C#. Even if they can express the same things, and F# is more powerful, it's a far more inconvenient language to use for someone that hasn't been living and breathing ML for years.

Furthermore, in general F# seems to generate far less efficient code than C# does, and for the kind of development I do (games/multimedia) I'm not really willing to sacrifice even more performance just because some FP fanatic thinks C# should go away. Personally, I think the C# compiler and the .NET JIT should have a lot more tuning applied, and get things like SIMD introduced, but MS doesn't seem to care about that.

Writing code in C# also makes it accessible to a much wider set of developers. The overlap and shared heritage with languages like Java is definitely a plus, even if I don't like some of the shitty design baggage that comes with it. It's already a struggle to get the community engaged with my project, JSIL - if it was written in an obscure language like F#, it'd be nearly impossible.

> I'm fairly familiar with functional programming techniques - I use a lot of closures, immutability, and map/reduce patterns in my code

i think that's the minority of c# developers though.

> I'm not really willing to sacrifice even more performance just because some FP fanatic thinks C# should go away

why should that even be question though? now think of a web application. suddenly f# reduces the amount of cruft you have to a great extent. why do people always think it's an either or? why can i not like html5, and still want it to stay outside of my desktop application?

> it's a far more inconvenient language to use for someone that hasn't been living and breathing ML for years.

yes, you may be right. but i think most programming is really copy and paste programming. when they know where they can find what they need to write their program it doesn't really matter what language it is written in.

> even if I don't like some of the shitty design baggage that comes with it

> It's already a struggle to get the community engaged with my project, JSIL - if it was written in an obscure language like F#, it'd be nearly impossible

interesting project. well, i would argue that it's because your project is not really playing to the masses. vsvim for example has more forks and stars than your project, 33% of it (the core) is written in f#. but it has also been around for much longer, and addresses a need people have.

My point re: engagement is that for anything that isn't utterly mass-market, it's a fight to get users and other developers engaged, so every quirk that makes your project harder to contribute to ultimately makes it less likely to survive.

It's not simply a matter of deciding to build software for the masses. It's essential that we have software that aims at small niches because bigger mass market software can be built on top of it.

LLVM is a great example. LLVM is only useful to the tiny subset of programmers who do compiler/JIT engineering, and it requires a lot of domain expertise. Regardless, its existence has enabled a huge set of new software to be built - clang is a great compiler, emscripten is one of the first real options for running native apps in the browser, etc. None of those would exist without LLVM. Imagine how hard it would be for people to contribute to LLVM if it were written in an obscure functional language instead of in a ubiquitous one?

As far as cruft goes, yeah, F# is less verbose, but it's also harder for me to understand and harder for me to debug. A few years of practice might solve that, but it doesn't offer me enough advantages to justify that huge investment, especially since during that time I'll be writing worse-performing software whether I like it or not. The same applies for any new language, really, and I don't think new languages are a bad thing. I just think the idea that a widely-used language should be replaced with a niche one is pretty out of touch.

If you're really just doing copy/paste programming, I don't think the language you use matters, and F# offers no particular advantage for that. It seems most useful in scenarios where you are writing code from scratch, and the more robust type system and expressiveness can let you do that faster with less mistakes.

If you're seeing significantly worse performance with F#, then that's pretty unusual (most people see very similar perf characteristics, with some things slightly faster in F# and some in C#). You might want to fire an email to fsbugs@microsoft.com explaining your scenario - the F# team is quite responsive.

The RyuJIT project shows that .NET JIT performance is still on the radar, though I haven't seen any indication that SIMD is on the roadmap.

To your final point, it's clearly true that C# is familiar to a wider variety of developers than F# is. However, I've been impressed by the uptake of some F# libraries, like FAKE. F# reads so mush like pseudocode in some cases that it's easy for people to buy in even if they're not especially familiar with the language.

Glad to hear it. The main problem I noticed the last time I used F# is that it generates more function calls, along with more heap references (vs stack-allocated structs) for things like boxed values, generators, etc to do simple tasks compared with C#. Is it the case that you can optimize all this out using parts of the language I don't know about?

F# supports value types just like C# does, so I wouldn't expect more boxing on the F# side. Some types like tuples that are used more in F# than in C# are reference types, so you might want to avoid them in your inner loops, but that generally just means writing F# that looks a bit more like C#. Likewise, as to the number of function calls, it's probably a question of style more than features, though you can do things like use the `inline` keyword to make sure that particular functions always get inlined at call sites, which can be a big win in some cases (it also allows you to write type-safe generic math code, which is an oft-lamented unsupported scenario in C#). Lots of people are making good use of F# in contexts where heavy computational requirements exist (e.g. finance or scientific computing), but I'm not too familiar with projects using it where more real-time requirements exist (though I think someone's in the midst of porting Quake III to F#, so it'll be interesting to see how that goes).

"but c# advocates in microsoft have been quite parasitic in their behavior of pushing the language(inside of microsoft)"

How could you possibly have decided that "parasitic" was the best word? Is C# hanging off the back of F#'s success?

Not really. .NET has succeeded to the degree it has because C# is a credible, robust, general purpose, accessible but powerful language.

This whole submission is a desperate, misled, confused attempt at elitism, and becomes particularly ridiculous when it's talking about what are trivial syntactical sugar changes.

Particularly bizarre is this confused notion that F# is being ripped off, as if there aren't many languages with most of the same rudiments.

Reply on news.ycombinator.com