5 ms·
Each has a different mental model and as Evan You said, the host language itself is not suited for a "pure" FP approach and you end up with a leaky abstraction.
by CharlieDigital 4y ago
Each has a different mental model and as Evan You said, the host language itself is not suited for a "pure" FP approach and you end up with a leaky abstraction.
As the article states, function closures are how classes are actually implemented in JavaScript so rather than mash the two together, it would seem a more cohesive mental model to simply use a class.
If you step back and look at the broader landscape of UI across desktop (Windows, Mac, Linux), devices (iOS, Android), and web: how many libraries and toolkits are FP and how many are OOP in their abstraction when it comes to managing components and object instances?
- Rapzid 4y ago> function closures are how classes are actually implemented in JavaScript Quite the opposite with V8.
- andix 4y agoIf you love OOP, then use Angular. It’s OOP all the way! But you will probably regret using it… There are also a lot of UI frameworks that are completely functional. Take your pick. (ReScript would be the most obvious choice for a react developer) But for a good reason the hybrid FP/OOP framework React on JS/TS is one of the most popular.
- CharlieDigital 4y agoEven Solid and Preact are OOP in nature since JS closures are how classes are represented in JS. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Classes are in fact "special functions", and just as you can define function expressions and function declarations, a class can be defined in two ways: a class expression or a class declaration. The difference is that React functional components are effectively "parroting" FP and half-in (stateless components) and half-out (hooks). Solid, Preact, Vue are all-out.
- andix 4y agoBy that logic F# is also not an functional language, because it gets compiled to CLR classes. For me those implementation details are not important. But sure, you’re right.
- CharlieDigital 4y agoF# is not a functional language. Even says so in the docs: https://learn.microsoft.com/en-us/dotnet/fsharp/style-guide/ https://learn.microsoft.com/en-us/dotnet/fsharp/style-guide/ F# has full support for programming with objects in .NET, including classes, interfaces, access modifiers, abstract classes, and so on. For more complicated functional code, such as functions that must be context-aware, objects can easily encapsulate contextual information in ways that functions cannot. https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/classes https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref... Classes represent the fundamental description of .NET object types; the class is the primary type concept that supports object-oriented programming in F#. https://learn.microsoft.com/en-us/dotnet/fsharp/what-is-fsharp https://learn.microsoft.com/en-us/dotnet/fsharp/what-is-fsha... F# has full support for objects, which are useful when you need to blend data and functionality. The underlying CIL representation of a lambda expression is an object; the functional side of .NET (whether C# or F#) is syntactic sugar on top of an OOP runtime. (C#/.NET dev by day dabbling in F#)
- pharmakom 4y agoI don’t see how your quotes imply that F# is not a functional language.
- andix 4y agoYou can find arguments to justify any point of view :)
- CharlieDigital 4y agoIt literally says on the box that it's not a functional language and it's clear that the actual underlying CIL is class based. If you still want to call that FP, then by all means. But then so is C# since you can do nearly exactly the same things in C#.