Why you should learn F# • Hacker News Board

Re: Why you should learn F#

#131

Post by knocte » Wed, Dec 19, 2018, 2:23 AM UTC

jweir wrote: post #22

A gripe about F# on MacOs - how to install it, count the ways - 6. https://fsharp.org/use/mac/ Don't I need Mono, wait, shouldn't I be using .NET? Oh I will probably install it one way, only to discover I should have installed it another. I find the .NET and Mono differences confusing. So this is a barrier to entry to consider. That said, this free book is kind of nice introduction: https://www.oreilly.com/programmin…

Yeah, the fact that Mono is inheriting all BCL code from .NETCore nowadays, but is still not .NETCore (because it has its own runtime) is a bit confusing.

That being said, the best/easiest way to use .NET in the Mac is just install "Visual Studio for Mac" (the Community edition is completely free), which will under the hood install all you need (Mono, .NET Core, etc).

Re: Why you should learn F#

#132

Post by rjblackman » Wed, Dec 19, 2018, 2:25 AM UTC

thedirt0115 wrote: post #125

I don't know F#, but I do know C#, and it feels like the author is trying to make C# look more difficult/verbose than it needs to be to make F# look better. Here is an alternative version of the "Everything is a function" section's IPasswordPolicy thing: https://ideone.com/3Savt9 I even went a little overboard with the function that takes a list of functions and returns a single composed function -- I could've also w…

I haven't read the article in depth, but the authors example is written according to SOLID principles where composition is decoupled via interfaces and dependency injection. I think the author is trying to show the difference between highly decoupled code examples in c# and f#. In f# you compose with functions, in c# you compose with object instances.

Re: Why you should learn F#

#133

Post by tokyodude » Wed, Dec 19, 2018, 2:26 AM UTC

contravariant wrote: post #16

algorithmsRcool wrote: post #14

F# is 3 big things to me: Safer threading with immutability Safer programming with null-safety Safer logic with precise domain modeling The precise domain modeling is the real paradigm shift. The whole point of static typing is to inform the compiler about your intent so that it can provide guarantees about correctness. F# makes it easy to define lots of small types that precisely model state so that you can give mor…

>I have personally struggled with domain complexity in C# that i was able to model precisely in F# and have it work perfectly on the first try. If you're willing to provide a (simplified) example I would be very interested.

There's a good example with explanation here

https://fsharpforfunandprofit.com/posts/designing-for-correc...

Re: Why you should learn F#

#134

Post by atombender » Wed, Dec 19, 2018, 2:30 AM UTC

knocte wrote: post #129

atombender wrote: post #105

F# seems like such an amazing language every time I look at it — a modern version of OCaml, with a clean syntax, some novel ideas, and fewer legacy warts. However, I wish that it had, like OCaml, a native AOT compiler that didn't come with the baggage of the .NET runtime. Some people might consider this a benefit, not baggage, of course. But it's the same reason I'm put off by Scala. From what I understand, to even r…

AOT not supporting generics? that's a pretty bad reading/summary of the webpage you link to (not to mention, that page may be a bit outdates, and more cases are supported by AOT now; take in account this is the mode that iOS apps developed with Xamarin need to use).

"As of Mono 2.0, AOT compilation is only supported for non-generic methods. support for generics is currently under development."

Re: Why you should learn F#

#135

Post by algorithmsRcool » Wed, Dec 19, 2018, 2:32 AM UTC

knocte wrote: post #129

atombender wrote: post #105

F# seems like such an amazing language every time I look at it — a modern version of OCaml, with a clean syntax, some novel ideas, and fewer legacy warts. However, I wish that it had, like OCaml, a native AOT compiler that didn't come with the baggage of the .NET runtime. Some people might consider this a benefit, not baggage, of course. But it's the same reason I'm put off by Scala. From what I understand, to even r…

AOT not supporting generics? that's a pretty bad reading/summary of the webpage you link to (not to mention, that page may be a bit outdates, and more cases are supported by AOT now; take in account this is the mode that iOS apps developed with Xamarin need to use).

In dotnet land generics are JITted on demand at runtime when you first execute a specific instance of that generic type.

So List doesn't necessarily get JItted even though List has been. This poses a bit of a problem for AOT compilation.

You would essentially have to either

A) Trace all possible execution paths and determine every needed generic instantiation and precompile and ship them all. This ain't easy, and it might be impossible. Also expect massive binaries due to all those types.

B) Bundle a JIT and lazily emit code as needed.

C) No generics?

Re: Why you should learn F#

#136

Post by rjblackman » Wed, Dec 19, 2018, 2:32 AM UTC

javcasas wrote: post #113

atombender wrote: post #105

F# seems like such an amazing language every time I look at it — a modern version of OCaml, with a clean syntax, some novel ideas, and fewer legacy warts. However, I wish that it had, like OCaml, a native AOT compiler that didn't come with the baggage of the .NET runtime. Some people might consider this a benefit, not baggage, of course. But it's the same reason I'm put off by Scala. From what I understand, to even r…

After being deeply burned by the .NET framework, I consider OCaml significantly superior to F# just because it doesn't depend on .NET or Microsoft. And yes, somehow the OCaml guys have managed to implement generics and AOT compilation to optimized machine code long before the .NET framework existed, but now this is something "truly hard" on .NET.

Can you describe how you were burned by the .NET framework?

Re: Why you should learn F#

#137

Post by cgrealy » Wed, Dec 19, 2018, 2:35 AM UTC

thedirt0115 wrote: post #125

I don't know F#, but I do know C#, and it feels like the author is trying to make C# look more difficult/verbose than it needs to be to make F# look better. Here is an alternative version of the "Everything is a function" section's IPasswordPolicy thing: https://ideone.com/3Savt9 I even went a little overboard with the function that takes a list of functions and returns a single composed function -- I could've also w…

Actually you can make it even more concise with an inferred array

  var isValidShort = createPasswordPolicy(new [] {
        	Test.MinimumLength(8),
        	Test.MustHaveDigits,
        	Test.MustHaveUppercase,
        });

Re: Why you should learn F#

#138

Post by tigershark » Wed, Dec 19, 2018, 2:43 AM UTC

mavelikara wrote: post #109

ambulancechaser wrote: post #29

Earlier quoted context omitted.

We found it quite nice for properties of objects that appear over time. Think things like Order that might or might not have delivery details. In C# you are making classes with nullable delivery timestamps, delivery person, etc. And one or two properties isn't that bad but it gets a little onerous when you start to have constraints like "these four properties are either all null or all populated". In F# it is trivial…

Why do you struggle with this in C#, especially given that you are familiar with the F# style? I don't know C#, but in Java I'd write this as: public class Order { final Optional delivery; public Order(Optional delivery) { this.delivery = delivery; } } public class DeliveryDetails { final long deliveryTimeMs; ... public DeliveryDetails (long deliveryTimeMs,...) { this.deliveryTimeMs = deliveryTimeMs; ... } } My IDE w…

The ide maybe will write a small part of it, but you’ll have to keep reading it forever. And obviously it is modelled wrong because it is possible to have a Delivered order without delivery details, there is nothing that enforces it. Compare it with how I would write it in f#:

    type OrderId = OrderId of string
    type DeliveryTime = DeliveryTime of long
    type DeliveryDetails = { deliveryTime: DeliveryTime...}
    type Order = { id: OrderId ...}
    type DeliveredOrder = { id: OrderId, deliveryDetails: DeliveryDetails...}

Probably it is even better to define delivery time using the unit of measures and specifying it as ms. What is the difference in this way? That an order cannot ever have DeliveryDetails, while a DeliveredOrder must have DeliveryDetails. As a bonus you can’t just pass any string as an order id (for example a description) but you need to pass an actual order id. the same is true for the deliveryTime with the adddd advantage that you won’t be able to perform operations on it with a different unit of measure. In java or c# you would kill yourself if you try to do something similar and moreover you won’t have all the constraints specified here and the immutability automatically enforced.

Re: Why you should learn F#

#139

Post by Timothycquinn » Wed, Dec 19, 2018, 3:07 AM UTC

vumgl wrote: post #17

(no/less functional) C --> Java --> C# --> Scala --> F# ---> Haskell (more/all functional) - form a talk by Martin Odersky

Do you know which talk this is discussed? I'm interested in watch his stuff.

Re: Why you should learn F#

#140

Post by sidcool » Wed, Dec 19, 2018, 3:27 AM UTC

There's a thread every few months about 'Why You Should Learn X', and I feel overwhelmed by it. I liked the one about Rust and got into the Rust boat. Now I have no time and energy to learn F#. That's both frustrating and debilitating. Personal Opinions.