Live data from Hacker News

What is the case against F#? (2009)

stackoverflow.com

61–70 of 107 posts

Re: What is the case against F#? (2009)

#61

The case against for most people is the chicken-and-egg problem of the mainstream adoption of the language. It should be relatively obvious at this point that the outright merits of a language have little or nothing to do with its popularity, at least when compared to things like the corporate backing and will behind a language (see: Objective-C / Swift), and other factors such as positioning and luck (e.g. Javascrip…

> It should be relatively obvious at this point that the outright merits of a language have little or nothing to do with its popularity

I beg to differ. People had 25 years to abandon Java but since then, the usage has only grown. I remember when Groovy and Ruby had their hyped periods sometime in the 00s, but what happened to that wave in the end? Grails and Rails became history, FAANG nowadays runs on Spring, the same for the rest of the world. Every practical feature that a JVM language had at a moment in time was later adopted by Java in some way. (maybe with the exception of Clojure which is the only language that didn't try to be a better Java).

Re: What is the case against F#? (2009)

#62
post #16

Earlier quoted context omitted.

Didn't they add lambdas to C?

There is a non-standard compiler extension supporting them for GCC, but that's all. Also, I seriously hope they won't. The whole point of C in this day and age is extreme simplicity and portability. The latest standard, C17, has only corrections. C11 has really all that's needed for "modern" applications, aka a threading library which is not pthreads and decent unicode support.

[deleted]

Re: What is the case against F#? (2009)

#63
post #41
post #31

F# is only functional language supported by big corporation. It is not Go level but still it is safe to say that Microsoft has some serious commitment to this language.

They see it as a better Python for Data Analytics/ML/etc. After playing around with it and porting some of my python work to F#....they may be right.

I've been coming to the opinion that I'll just never be happy with nominal static typing for data science or engineering. I'm curious about structural typing, but, of the languages I've tried so far, only dynamic typing has kept me happy for the long run.

I say that as someone who, prior to getting into the data space, was a fanatical partisan of static typing.

For actually implementing the core bits of analytics and ML tooling, I have a hard time seeing past languages that can match the performance of Fortran/C/etc and are able to expose a C ABI. Because those languages let you write one central, highly-optimized implementation that everyone can access from their favorite higher-level language.

Re: What is the case against F#? (2009)

#64
post #22

Earlier quoted context omitted.

C/C++ have not fallen to the wayside but most major programming languages have now inherited quite a few functional paradigms. I haven't kept up to date, but don't both C++ and Java have lambdas now? Don't they also feature currying? C++ is of course not Haskell, but that's not the point. Functional programming has become commonplace by procedural languages adopting the simpler/most-useful aspects.

If it's not null-safe I will avoid it for new projects. Lambda's: great! But real null-safety, strong type safety, proper sum types, pattern matching/ type destructuring, are now my requirements. I'd say Kotlin is the language with the most adoption that ticks the boxes. And it is (not surprisingly) an OO lang.

Kotlin pattern matching and destructuring/unapply support are pretty weak, no?

Re: What is the case against F#? (2009)

#65
post #11

F# is a lot like OCaml. But OCaml still struggles with multiprocessing, while F# can run on the .NET infrastructure which has this solved.

I really don't see F# as being a lot like OCaml in any practical way.

It's like, if you're sitting in a hardware store having a hard time choosing between buying a Ryobi brand miter saw and a Ryobi brand power drill for your current project, maybe it's time to take a step back to better define what you're planning to do, and then come back to the store. Sure, since they're both Ryobis they do have a lot of things in common, but that doesn't mean you'd ever substitute one for the other.

I won't list every difference, because there's a lot, but, to an approximation, the intersection of their two feature lists looks more-or-less like SML's feature list.

Re: What is the case against F#? (2009)

#66
post #48
post #41

Earlier quoted context omitted.

They see it as a better Python for Data Analytics/ML/etc. After playing around with it and porting some of my python work to F#....they may be right.

This is exactly what I'd like to use F# for. However, I don't know if there's a good ecosystem for F# that gives me anything over Julias, for example.

ML.NET might do it, if that is a domain you care about.

Re: What is the case against F#? (2009)

#67

The case against for most people is the chicken-and-egg problem of the mainstream adoption of the language. It should be relatively obvious at this point that the outright merits of a language have little or nothing to do with its popularity, at least when compared to things like the corporate backing and will behind a language (see: Objective-C / Swift), and other factors such as positioning and luck (e.g. Javascrip…

I don't like to shy away from languages just because they won't ever become one of the top 5 languages. Moderate success for a language can often be more than enough to keep the things built on it afloat for a long time. I also suspect that the relationship between how many people are successfully using a language, and how often you hear about it on the Internet, is non-linear. And most the popular rankings (TIOBE, S…

I totally agree with you, when it comes to my own personal projects. (In fact, the number of languages I have relatively seriously dabbled in is getting to the point that it's best to leave off a CV, lest one comes off as a jack-of-all-trades or something.)

But for companies, it's pretty hard to put together 3-4 teams of developers in some esoteric language. And to find developers for it many years down the line for maintenance. So, they understandably stick to mainstream stuff, even if there are significant inherent advantages to something off the beaten bush.

Re: What is the case against F#? (2009)

#68

The case against for most people is the chicken-and-egg problem of the mainstream adoption of the language. It should be relatively obvious at this point that the outright merits of a language have little or nothing to do with its popularity, at least when compared to things like the corporate backing and will behind a language (see: Objective-C / Swift), and other factors such as positioning and luck (e.g. Javascrip…

> It should be relatively obvious at this point that the outright merits of a language have little or nothing to do with its popularity I beg to differ. People had 25 years to abandon Java but since then, the usage has only grown. I remember when Groovy and Ruby had their hyped periods sometime in the 00s, but what happened to that wave in the end? Grails and Rails became history, FAANG nowadays runs on Spring, the s…

You didn't describe anything meritorious about Java.

You described the network effect of large companies converging on one language.

Re: What is the case against F#? (2009)

#69

I find the whole concept of the case to be off. The author is concerned that applications can’t take advantage of the increasing parallelism of computers because of the difficulty in writing fine grained parallel tasks, but misses that 1) the paucity of programs that end up CPU bound and 2) Http requests already provide an excellent threading container within which imperative code runs, meaning that the system takes…

> Http requests already provide an excellent threading container

Yes, modelling code around receiving requests and returning responses was a good idea.

> It’s harder to walk a BA or non technical manager through functional code and stand a chance of them tracking what’s going on.

Jane Street adopted OCaml as its main programming language early on because the language's functional programming style and clear expressiveness made it possible for code reviews to be performed by traders who were not programmers, to verify that high-performance code would do what it was intended to do.

Re: What is the case against F#? (2009)

#70

Earlier quoted context omitted.

I don't like to shy away from languages just because they won't ever become one of the top 5 languages. Moderate success for a language can often be more than enough to keep the things built on it afloat for a long time. I also suspect that the relationship between how many people are successfully using a language, and how often you hear about it on the Internet, is non-linear. And most the popular rankings (TIOBE, S…

I totally agree with you, when it comes to my own personal projects. (In fact, the number of languages I have relatively seriously dabbled in is getting to the point that it's best to leave off a CV, lest one comes off as a jack-of-all-trades or something.) But for companies, it's pretty hard to put together 3-4 teams of developers in some esoteric language. And to find developers for it many years down the line for…

My sense is that that is unnecessarily self-inflicted. Companies' focus on hiring people who already know the language they use is penny wise and pound foolish.

Even if a new developer is a complete novice at a language, I would still expect that to be less effort than learning the business domain, getting to know the codebase, and socially integrating oneself with the team.

Post reply on HN