Live data from Hacker News

What is the case against F#? (2009)

stackoverflow.com

71–80 of 107 posts

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

#71
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.

It's not _quite_ meant specifically as a better Python, but it can play that role and there is every intention of making that something that has "product truth" to it. You can look forward to some concrete improvements along those lines this year, specifically in the notebooks tooling space and some library support!

In terms of my current use, the new scripting feature with "r# nuget:.." is game changing because now we can freely share .fsx files and they...just work. Compared to praying to the pip/virtualenv gods in the python space.

Really excited to see what ya'll have planned for 2021

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

#72
post #30

Earlier quoted context omitted.

What's wrong with that attitude and what do you think should be better by now?

I can't speak for melling but as for me, that attitude struck me as dismissive not only of the capacity of the average developer to understand fp, but a bit of fp itself as too hard. 11 years later, fp concepts are more generally understood, accepted, and used; and the attitude has shown to be incorrect. fp is not that hard. It is, in fact, easier than OO

> that attitude struck me as dismissive not only of the capacity of the average developer to understand fp, but a bit of fp itself as too hard.

It's a self-inflicted criticism. It's non-fpers saying that fp is too hard, not fpers.

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

#73
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.

Check out the new features for making feature full scripting files (.fsx)

https://devblogs.microsoft.com/dotnet/announcing-f-5/#packag...

I am starting to use this to port some of python data munging scripts. Especially those that have to call external apis because Fsharp data providers are voodoo magic.

https://fsprojects.github.io/FSharp.Data/library/JsonProvide...

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

#74
post #10

Most of the time my C# code uses most of the functional paradigms. I write pure functions when i can and use LINQ almost everywhere. Recently i created a F# API with the dotnet CLI, but the syntax is not even close. I get the concepts, but syntax is a little bit to much to just try it when i have to write a new microservice. Am i the only one?

F# syntax is so much better than C# for functional programming - and arguably for object programming too. However, it is sufficiently different that you really need to jump in with both feet. Don't assume it will be easy because you know C#. However, once you start to grok the syntax, you begin to see how the language features elegantly tie together, and the language design decisions make perfect sense. Unfortunately…

This different is a big thing. People learn C#, Java, JavaScript, Basic, PHP or C/C++ early on their carrier. Hoping between these is hard but not because of syntax. Hoping from this OO gang to a modern functional syntax is brutal.

I think key to proper functional adoption is wide range entry level adoption (and not only university).

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

#75

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…

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

Not really. Check out fsharp code and you use domain words to actually model the business case.

This is really old code, but it communicates Fsharp's effectiveness quite well. https://github.com/swlaschin/NDC_London_2013/blob/master/ddd...

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

#76

I have frequently come across 'multi-core' code using fancy features of fancy languages (e.g. Scala) that get a 205% speedup on a 8 core machine when I should be getting more of a 750% speedup, not get the same answers every time, etc. The choice in that situation is to risk spending a few days debugging (50% at best success rate) or spend 20 minutes and use a ThreadPoolExecutor and you're done. Java was the first pr…

> correct concurency primitives

wait? synchronized? notify? notifyall? Fat threads and CompletableFutures that won't cancel? No thank you!

I'll take green threads and transactions over them any day!

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

#77
I would be very worried using any language developed and marketed by a single large corporation. It’s not only that they or the language might go away suddenly (hello Google!), it’s mostly that this corporation have a de-facto iron grip on the future development of the language and the developer culture.

I simply don’t use any such languages.

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

#78
post #6

“Most 'developers' don't understand functional programming concepts, and can't even write very good imperative code in C#. So what hope have they got of writing good functional code in F#?” i hope 11 years later we have a different attitude

Me in 2010: "Functional programming is great because you can write code that always gives the same output for the same input, making it super easy to test, debug and share. The downside is you need to put down those for-loops and start thinking in terms of map and reduce instead."

Programmers in 2020: "Yeah some of the people on the team know how to use flatMap."

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

#79

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, 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. Javascript). So, you cannot start from "this language is _clearly_ better, so it will certainly become more popular".

Well... it's complicated. I would say that for a new language to succeed now, it has to be clearly better at something - some niche, or some programming paradigm, or some such. It also has to meet the minimum bar of having libraries that cover much of the normal stuff that we expect libraries to cover. (That's where corporate backing comes in - it pays for building all the libraries that people have come to expect.)

But if the language isn't clearly better at something, then it's clearly worse, because I can hire people for a mainstream language, or I can have trouble hiring people for the offbeat language. If the offbeat language isn't enough better to make that a worthwhile trade-off, then why not use the mainstream one?

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

#80
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…

They are similar to the point of being identical relative to comparisons between either and any other language you can actually get a job using (although I have a soft spot for it, SML does not fall in this category as far as I can tell from a quick search).
Post reply on HN