I'd much rather code F# than Python, it's more principled, at least at the small scale. But F# is in many ways closer to modern mainstream languages than a modern pure functional language. There's nothing scary about it. You can write F# mostly like Python if you want, i.e. pervasive mutation and side effects, if that's your thing.
If Python is the only language you have to compare other languages to, all other programming languages are going to look like "Python with X and Y differences". It makes no sense to compare Python to F# when OCaml exists and is a far closer relative. F# isn't quite "OCaml on .NET" but it's pretty close.
It absolutely does make sense to compare it to the worlds most popular programming language, especially when dismissed as "functional programming". Who benefits from an OCaml comparison? You think F# should be marketed to OCaml users who might want to try dotnet? That's a pretty small market.
Python is the world's most used scripting language, but for application programming languages there are other languages that are widely used and better to compare to F#. For example, C# and Java.
F# was pitched by Microsoft to be used in areas where Python dominates, especially for scripting in the finance domain and "rapid application development". So it doesn't make sense at all that C# and Java are a "better comparison".
> F# was pitched by Microsoft to be used in areas where Python dominates
Haha, no. Microsoft barely talks about F# at all, and has largely left the evolution of the language up to the open source community that supports it. Furthermore, you shouldn't take your cues about what a language is best suited for from marketing types, you should evaluate it based on its strengths as a language and broader ecosystem. If you seriously doubt that C# is a better comparison to F# than Python, then I suspect you haven't used either C# or F# and you're basing your views on marketing fluff.
Less of the personal attacks please, you know nothing about me. I actually think it is you that is missing context here. Don Syme personally visited and presented at a variety of investment banks. He was the creator not a marketing type. I was present at one of his pitches and met him. One bank, Credit Suisse ended up adopting it. Any comparisons he made to C# where based around readability and time to market (C# is very verbose and boilerplate heavy compared to both Python and F#). This was all on the 2010-2015 timeframe. Python ended up winning in these markets. My point has always been that this now puts it in a difficult position, it's simply not radical enough to disrupt but still carries the perceived "functional programming" barrier to entry.
It all depends on the lens one chooses to view them. None of them are really "functional programming" in the truly modern sense, even F#. As more and more mainstream languages get pattern matching and algebraic data types (such as Python), feature lambdas and immutable values, then these languages converge. However, you don't really get the promises of functional programming such as guaranteed correct composition and easier reasoning/analysis, for that one needs at least purity and perhaps even totality. That carries the burden of proof, which means things get harder and perhaps too hard for some (e.g. the parent poster).
I am an avid functional programmer (it’s my default when working on solo projects) and I teach a PL class that covers the lambda calculus, LISP, etc. But the bulk of the course uses F#. I’ve been using F# regularly for the last 13 years.
It’s pretty easy to stick to pure F# if what you want is the pure functional programming experience. But what I like about it is its pragmatism, and this is a big reason why it’s the language I chose for the course. It is by-value, eagerly evaluated by default, and has an easy-to-learn idiomatic syntax. It has a large and well-behaved standard library, and you can use C#’s excellent standard library if you need additional things (e.g., mutable data structures). I have used F# in many performance-sensitive applications, and the fact that I can say “you know, inside this function, I’m going to use mutability, raw pointers, and iteration” has been a lifesaver in some places. But because it is a functional language, I can also abstract all that away and pretend that it is functional.
I understand why other FP folks dislike this approach. But the insistence on purity makes many problems artificially difficult. Debugging a lazily evaluated program is a nightmare. There are lots of times I want a well-behaved language but I am not willing to do CS research just to solve common algorithmic problems. The generally pragmatic streak from the SML family makes them easy to love.
If purity is a requirement for "real" functional programming, then OCaml or Clojure aren't functional. Regarding totality, even Haskell has partial functions and exceptions.
Both OCaml and Clojure are principled and well designed languages, but they are mostly evolutions of Lisp and ML from the 70s. That's not where functional programming is today. Both encourage a functional style, which is good. And maybe that's your definition of a "functional language". But I think that definition will get increasingly less useful over time.
Haskell. But there are other examples of "pure functional programming". And the state of the art is dependently typed languages, which are essentially theorem provers but can be used to extract working code.
Sure, Python has types as part of the syntax, but Python doesn't have types like Java, C#, etc. have types. They are not pervasive and the semantics are not locked down.
Exactly what I've observed in practice because most devs have no background in writing functional code and will complain when asked to do so.
Passing or returning a function seems a foreign concept to many devs. They know how to use lambda expressions, but rarely write code that works this way.
We adopted ErrorOr[0] and have a rule that core code must return ErrorOr<T>. Devs have struggled with this and continue to misunderstand how to use the result type.
Cool. I’ll have to check this out. I often find myself rolling my own “option type” when writing C#.
Agreed with getting developers to see the value. The most convincing argument I’ve been able to make thus far has been “isn’t it embarrassing when your code explodes in production? Imagine being able to find those errors at compile time.” The few who actually understand the distinction between “compile time” and “run time” can usually appreciate why you might want it.
honestly this sounds like you've never really done it.
FP is much better for ergonomics, developer productivity, correctness. All the important things when writing code.
I like FP, but your claim is just as baseless as the parent’s.
If FP was really better at “all the important things”, why is there such a wide range of opinions, good but also bad? Why is it still a niche paradigm?
It’s niche because the vast, vast majority of programmers just continue to do what they know or go with the crowd. I spend roughly 50% of my time doing FP and 50% doing imperative (most OOP) programming. I am dramatically more effective writing functional code.
Like other posters, I am not going to claim that it is better at all things. OOP’s approach to polymorphism and extensibility is brilliant. But I also know that nearly all of the mistakes I make have to do with not thinking carefully enough about mutability or side-effects, features that are (mostly) verboten in FP. It takes some effort to re-learn how to do things (recursion all the things!) but once you’ve done it, you realize how elegant your code can be. Many of my FP programs are also effectively proofs of their own correctness, which is not a property that many other language styles can offer.
No it's not pleasant at all. It's boilerplate heavy, non-local and indirect. It's presumably a large part of why pattern matching is arriving in Python.
I guess that's subjective - I'm as big a fan of pattern matching as anyone, but when I was writing a type checker in python we made heavy use of visitors and it made the code pleasant to maintain.
The vast majority of which unfortunately still come with Intel processors, especially the premium models. I handed my work issued Lenovo X1 back to my employer as being unusable due to overheating and excessive thermal throttling. The M4 Macbook Pro I now have is such a huge positive difference, I have adjusted to macOS and enjoy Intel outside.
X1 is Intel only, but the new Lunar Lake is quiet and cool. And T14(s) comes with AMD. Mac hardware still is #1, but kernel panics because holding it wrong is definitely not normal.
I would argue that not sanitising strings is analogous to a form of memory unsafety. You take as an input, an opaque blob of bytes that you then pass on to a myriad of other libraries and pieces of code. Nothing is captured in the types other than "String". Mainstream programming languages need to make it easier to define new types and parse strings into them. Rust is very promising in this area, as it features algebraic data types.
GEM was in ROM on the Atari ST and it was fantastic. It was light years ahead of where Windows was at the time. It was Amiga Workbench that was somewhat limited by being on a floppy disk.
Absolutely, when I first tried Windows Cubase in the 90s, it wasn't long before it ate all my data. Even today's DAWs still haven't caught up with the original ST Cubase in terms of stability.
Well said. I guess such ignorance is not that surprising given that most "programming" today is glueing code together with scripting languages. This is really just a form of configuration. It certainly requires domain knowledge and a tolerance for digital bureaucracy, but not always maths. I do wish schools would do a better job of teaching that the entire fabric of western civilization rests upon mathematics.
How about F#? Isn't F# mostly C# with better ergonomics?