I like OCaml quite a lot so I’m F#-curious but I don’t know anything about the .NET environment and don’t currently have any need to program on Windows. What are the trade-offs between OCaml and F# for programming on Linux?
Why F# evangelism isn't working (2015)
271–280 of 333 posts
Re: Why F# evangelism isn't working (2015)
#272Earlier quoted context omitted.
I don't think it matters how good or bad C# is, Object Oriented Programming is a mess Learning, how to use an Object System (a tree of objects/classes) is inherently hard The current problem with F# is that it doesnt do enough to shield you from objects, it does what it can, but still to use F# effectively, you still need to learn some C# and a lot of API that basically Objects inside Objects inside Objects calling O…
The worst part of OOP is that all the properties of an object can be a mishmash of values and are mutable. In any method, you never know if the object is in some undesirable state without checking properties within the method itself. Multiply that headache across all methods and all other classes and it becomes a mutable mess. It makes it weird that we pass around objects as types when they encapsulate so much state…
This isn't a property of OOP. This is a property of poor class design. You absolutely should be designing classes such that every possible sequencing of their public methods leaves them in a valid state and maintains their invariants.
Structs have the issue you describe and they aren't really OOP.
Yes, if the first thing you do when you write a class is make a setter method for each field then you will have problems. That's not really a property of OOP.
Re: Why F# evangelism isn't working (2015)
#273Earlier quoted context omitted.
> You can get close to writing purely functional code in C# now. It seems that FP advocates overlook just how great LINQ is, even if it exists within the impure swamp of regular C#.
I don't really know Linq (and haven't used F# for 2 years, using .Net 5), but isn't F#'s `query` the interface to Linq? https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref... https://fsharp.github.io/fsharp-core-docs/reference/fsharp-l...
Yeah, that's the F# support for it. The interesting bit is that C# supports much nearly the same query syntax (`for item in something where item.IsInteresting select new { name = item.Name }`) and secretly supports just about any arbitrary Monad you want to write [1]. Just as C# also was one of the first languages to take something like F#'s async { } builder for async/await syntax, as a different Monad transformer (that C# also built to be duck-typable for any Monad that fits the right pattern).
LINQ and async/await alone can be heady "gateway drugs" in C# to learning functional programming fundamentals (including the deep, advanced fundamentals like Monads), and C# only seems to continue to pick up little bits of FP here and there over time.
There are definitely lots of reasons why even some of the biggest FP fans often think "C# is good enough" without needing to reach for F# in 2023. (Which is why the post here, and the comments above in this same thread lament that F#'s biggest problem is the shadow that C# casts.)
[1] Mark Seemann did an entire series of blog post on coding common Monads in both F# and C# and the C# code is very interesting at times: https://blog.ploeh.dk/archive/
Re: Why F# evangelism isn't working (2015)
#274(Author here) Well this is a blast from the past. Back when I wrote this, I kinda hoped F# would surprise me and gain more traction than I expected. But 8 years later, if anything, it seems like the dominance of C# in the .NET ecosystem has grown. F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive.
F# also tried to pivot into data science of lately, only to have Microsoft themselves jumping into Python and being the entity that finally managed to convince Guido and others to invest into improving CPython's performance, and possible JIT integration. Basically having the pivot efforts being sabotaged by the same company.
Microsoft has always been a polyglot company. They also invested heavily in R and I believe even contributed some things to Julia.
I don't think the pivot entirely failed, there's definitely a small niche for "data science, but it needs to run in .NET" and F# still to my understanding fills it well. It's a very small niche and I don't expect to hear a lot of data scientists directly training for it, but there's a lot of advantages in places that use the Azure stack, for instance, for faster/better/more integrated data science when done with F#.
F# would probably need a lot more investment in dynamic types to truly attract a lot of data scientist attention. (Though the .NET DLR still exists and could use some fresh, modern love.)
Relatedly, I appreciate a lot that Microsoft's polyglot approach helped standardize the ONNX runtime, and even if the data scientists I'm working with prefer Python or R, I can still take ONNX models they build and run them in a C# or F# library with very little sweat.
Re: Why F# evangelism isn't working (2015)
#275Earlier quoted context omitted.
Not OP but I would choose discriminated unions. Why? because Linq is basically just syntactic sugar for regular IEnumerable methods, while discriminated unions have no equivalent at all. Even if you wanted to claim that those IEnumerable methods ARE linq, then it would still be possible to implement them with a library while discriminated unions have to be a compiler feature.
Yep, Linq could be replaced by the more general Computation Expressions in F#
F# has a query { } expression for LINQ already.
Re: Why F# evangelism isn't working (2015)
#276Earlier quoted context omitted.
> OOP is bad because eventually OO systems becomes too complex, OO API is intimidation This strikes me as a sort of ... reverse of survivorship bias. You look around and see all complex systems are in OO, then you conclude that it is OO that is the cause of the complexity. Have you considered that the non-OO designs are deficient in some way that prevents them from being used for the type of systems that you find to…
I do feel like OOP introduces a lot of inherent overhead , not necessarily "complexity". I feel like doing anything in Java, for example, typically requires the creation of several separate files , spanning 30+ lines each, much of which is just class decorators and and the like. I do feel like often the equivalent program in something like Clojure will be much shorter, and be contained in substantially fewer files wi…
But if you convert that Java to Kotlin it'll get vastly shorter, whilst still being semantically the same. OOP doesn't have to mean verbosity. Java chose that path to keep the language simple, like how Go is also very verbose but simple (Kotlin is more concise but more complex).
Re: Why F# evangelism isn't working (2015)
#277Earlier quoted context omitted.
Doesn't look to me like they're trying to kill .NET at all. Maybe F# in particular isn't getting the love and attention it deserves but they'd have to be mental to be actively trying to kill off something as popular as .NET
Kill in the sense that from WinDev point of view, the less .NET ships on Windows the better. In case you aren't aware, WinRT basically marks the turning point started with Longhorn ideas being rewriten into COM. With WinRT, they basically went back to the drawing board of Ext-VOS, a COM based runtime for all Microsoft languages, hence why .NET on WinRT/UWP isn't quite the same as classical .NET and is AOT compiled, w…
UWP never required AOT, it was an opt-in performance boost (that has since been rebuilt to support all of .NET in ".NET Native").
Today's post-UWP C#/WinRT bindings don't require AOT either.
Beyond WinRT, .NET (Core) has supported all the raw COM, including COM component hosting since at least .NET Core 3.0. It's Windows-Only, of course, to use that, but that should go without saying. It's mostly backwards compatible with the old .NET Fx 1.0 ways of doing COM and a lot of the old code still "just works". .NET has proven that with .NET 5+ and all the many ways it (again) supports raw Win32 fun in the classic WinForms ways. (And all the ways that even .NET Fx 1.0 code has a compatibility path into .NET 5.)
It would have been nice if Windows had stronger embraced .NET, but WinRT is still closer to .NET in spirit than old raw COM anyway.
Re: Why F# evangelism isn't working (2015)
#278Earlier quoted context omitted.
Forcing linear dependence of files and definitions is considered a feature of F#. In codebases that allow out of order definitions, things get wild real quick.
> In codebases that allow out of order definitions, things get wild real quick. Not an issue in C# at all. Get wild in what way?
It can be an issue in C#. I've seen some mad circular dependencies between files. The file hierarchy doesn't always reflect the namespace hierarchy which sometimes doesn't reflect the actual code dependencies hardly at all and untangling the messes that result from that can be a big deal.
I'm not sure a project gets into that state "real quick", but it remains something that projects can do over time, sometimes without realizing it, especially when a DI abstraction makes it even less obvious how circular a project's dependencies really are.
Re: Why F# evangelism isn't working (2015)
#279Earlier quoted context omitted.
I think F# programmers lack that gamut because they get comfortable in the eager execution type safe world and stay there with no particular reason to learn dynamic programming techniques. There is also the effect that it allows less advanced functional programmers to be productive so that in randomly sampling currently active functional programmers the F# programmer is less likely to be advanced. Scala developers we…
I have been programming for 20 years, and yet despite having used dynamic languages I don’t actually know what it means to leverage dynamic programming techniques. For instance, I’ve never encountered a JavaScript codebase that I have thought couldn’t benefit from just being statically typed with Typescript. I get the impression that dynamic programming, besides the odd untyped line of code, is best used only for ext…
> For instance, I’ve never encountered a JavaScript codebase that I have thought couldn’t benefit from just being statically typed with Typescript
That's the type bias. If you look at a non-typed codebase, it always feels like it will be better with types. But if you had a chance to go back in time and start the same codebase in Typescript, it would actually come out way worse than what you have today.
Types can be great when used sparingly, but with Typescript everyone seems to fall into a trap of constantly creating and then solving "type puzzles" instead of building what matters. If you're doing Typescript, your chances of becoming a product engineer are slim.
Re: Why F# evangelism isn't working (2015)
#280Earlier quoted context omitted.
On top of your answer and the other, I still think Discriminated Unions are still a big hole in c#. I know they are supposedly working on it, but until they officially release it I'm not believing them.
I too miss discriminated unions in C#. But even more often, I find myself wishing C# blocks were expressions. In F#, I could do this: let x = let z = whatever ... value and z is inside a local scope. So in C#, I want to do: var x = { var z = whatever; ... value }; Maybe it's just me.
I'm finding switch expressions filling that gap a lot lately. I've also picked up at some point a bad habit in "borrowing" JS' ugly IIFE pattern in C#.
var x = (() =>
{
var z = whatever;
...
return value;
})();