our team (C#) did an extended proof of concept in F# about ten years ago. we found that it was easier to hero-code in F# but harder to work as a team over time in F#. we ended up embracing a lot of the functional paradigm in C#, which seems like a very good compromise.
What is the case against F#? (2009)
21–30 of 107 posts
Re: What is the case against F#? (2009)
#22"Asked 11 years, 7 months ago" Has the need to use functional programming languages become obvious yet? Has C/C++ et al. fallen by the wayside, yet?
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.
Re: What is the case against F#? (2009)
#23Earlier quoted context omitted.
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…
I know OCaml and F# are super similar, but how similar is rust syntax?
(I wrote this without realising that you specifically meant "syntax for functional programming". Sorry.)
Syntax is fairly different but the concepts are broadly similar. Rust has many of the same nice things as F# does, like "if" as an expression rather than a statement, algebraic data types, mutability declared as a keyword, etc. In fact Rust is much stricter with the "declared mutability" thing, because in F# you can use an immutable reference to a mutable object to mutate the object.
The really big paradigm difference I found as an F# person when starting to learn Rust was the lack of guaranteed tail-call optimisation, meaning that Rust kind of wants you to avoid recursive functions. I also find it much more annoying to write sequences ("Iterators") in Rust than in F# (where the `seq` computation expression makes everything ludicrously easy at the cost of some oddly bad performance sometimes). F#'s anonymous interface implementations are also really handy, but Rust's situation there is at least no worse than C#.
Re: What is the case against F#? (2009)
#24Earlier quoted context omitted.
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…
I know OCaml and F# are super similar, but how similar is rust syntax?
Rust is influenced by OCaml but has lots of C++ concepts thrown in too. I don't think it makes sense to be choosing between OCaml/F# and Rust since they are so different. If you need the performance characteristics of Rust, then the choice is made for you (and you should also consider modern C++). If not, then the borrow checker is probably a burden that you don't need.
Maybe I'm missing something. Under what use-cases would someone be choosing between OCaml/F# and Rust?
Re: What is the case against F#? (2009)
#25"Asked 11 years, 7 months ago" Has the need to use functional programming languages become obvious yet? Has C/C++ et al. fallen by the wayside, yet?
Pretty much every mainstream language has adopted concepts from FP. C++ has closures. Even Java is getting pattern matching. Everyone has map/fold. ...
Most new languages I can think of have a concept of immutability and sum types. (Kotlin, Swift, Rust)
Many languages are in fact converging on what seems like a local optimum, with a blend of functional and non-functional idioms.
The line has become a lot blurrier, which makes the question hard to answer.
Re: What is the case against F#? (2009)
#26I 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…
The other thing is that most programs are probably doing nothing most of the time. Waiting for user input, waiting for network IO, waiting for some other real-world event. For most developers, it's probably not using another language so you can "wait faster" most of the time. The performance sensitive code can be scrutinised and properly optimised on a case-by-case basis.
Really the "reason why computers suck in 2021" is that user-interfaces are fundamentally single threaded, and that every time you see a spinning circle or beach ball on your computer, some application dropped the ball and none of the UI will render ever again until some function returns.
Maybe that function is waiting for a signal from Mars or a DNS lookup, or a 3GB file download, or for an O(N^2) algorithm to finish (e.g. does your "no code" tool know when to say "no"?,) but it hangs up everything else.
Web browsers are huge programs written in C++ by the greatest software development organizations and they block the render thread as little as possible, Javascript inherits this property as embedded in the browser and that is why it is so dominant on the front end.
Perhaps some more radical idea like breaking the application up into tasks that are killed in (say) 50ms and can be individually crashed (like Erlang) but going from that idea to conception is a lot of work -- one thing to do for a very simple mobile app, another to do write a framework you could write an IDE like VS Code in.
And that is what I find so irksome about the hand-wringing behind "Why isn't language X so popular?" is that if you really want to be doing something harder than what most people are doing you will need to thread a path from beginning to end and you're going to do that first through mastery of computer science (general) and second doing it through mastering your tools (specific).
There is so much path-dependence everywhere. I have gotten into the Arduino hobby lately. A 1970s computer scientist would think it was insane that it uses C instead of something more like Pascal or PL/I, that it should have a language that respects the Harvard architecture, etc.
They'd be right. C's a terrible language to use for that purpose, except that (1) the developers of Arduino could get a good C compiler and toolset off the shelf, (2) many people know how to program C, (3) you aren't wasting your time learning C, and (4) C isn't that bad, and (5) you can't write that big of a program for an Arduino anyway so you can only get into so much trouble with a "buffer overflows included" language.
Re: What is the case against F#? (2009)
#27When I was learning F# I felt the biggest barrier was lack of good documentation. I’m used to languages like node.js, ruby, and elixir where APIs/guides are straightforward.
programming language maintainers need to think about UX.
I’ve started building a web server library[1] in F# to address this. Other libraries took for granted that I had no knowledge of .Net and required lots of .Net boilerplate.
[1]: https://wiz.run
Re: What is the case against F#? (2009)
#28"Asked 11 years, 7 months ago" Has the need to use functional programming languages become obvious yet? Has C/C++ et al. fallen by the wayside, yet?
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.
I don't know about the currying, but Java has already lambda and optionals, and is getting immutable records, sealed class (product and sum types), pattern matching and type inference in Project Amber [1]. They all are features usually found in functional languages (Standard ML for example).
Re: What is the case against F#? (2009)
#29Earlier 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.
> I'd say Kotlin is the language with the most adoption that ticks the boxes.
How? Kotlin is decisively an object oriented language.
Re: What is the case against F#? (2009)
#30“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
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