Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why you should learn F#

dusted.codes

Post reply on HN
Print view View original

101–110 of 179 posts

Re: Why you should learn F#

#101

Post by bunderbunder »

mcintyre1994 wrote: post #10

I've previously used Ocaml at my last job and use Scala at my current one, it's interesting that F# (just judging from this blog post) looks more similar to Ocaml than to Scala - like they've more aggressively pulled out syntax and embraced partial application etc. I'd always assumed F# was to C# what Scala is to Java - and I think that probably does represent their design goals, so I wonder what the different consid…

But F# tries to stay very close to its functional roots, and describes itself as "functional first".

By contrast, Odersky has always been clear that Scala tries to be a pragmatic mix of things from OOP and FP.

I also, personally, feel like F# has a tendency to be a bit more conservative about adding language features. For example, Don Syme has been very resistant to adding typeclasses to F#, because of how it would interact poorly with the rest of .NET. I love me some ad-hoc polymorphism, but, as someone who is currently working in a mixed Scala/Java codebase and frequently stumbles over the incompatibilities between Scala and Java, I've come to appreciate that decision in hindsight.

Re: Why you should learn F#

#102

Post by mobiliakas1 »

sparkie wrote: post #95
cgrealy wrote: post #55

While I really like the concept of functional programming and F# is definitely on my list of practical useful languages to learn, this article is clearly written by someone who doesn't know C# very well. Take the "To hell with interfaces" example. public interface ISortAlgorithm { List Sort(List values); } public class QuickSort : ISortAlgorithm { public List Sort(List values) { // Do QuickSort return values; } } pub…

I primarily use F# over C#, and I would prefer the interface version over the functions in many cases. An interface makes it a bit more explicit and self-explanatory what is expected to be passed. A Func , List > is not very meaningful and potentially ambiguous. Obviously, anywhere you expect more than one function, an interface is more desirable because it avoid the need to pass around multiple objects. One thing th…

You can use delegates in C# for that.

    delegate List SortAlgorithm(List values);

    List QuickSort(List values) => 
        values; // Do QuickSort

    List MergeSort(List values) =>
        values; // Do QuickSort

    void DoSomething(SortAlgorithm sort, List values)
    {
        var sorted = sort(values);
    }

    public void Main()
    {
        var values = new List { 9, 1, 5, 7 };
        DoSomething(QuickSort, values);
    }

Re: Why you should learn F#

#103

Post by weavie »

sifoobar wrote: post #83
pimeys wrote: post #35

Earlier quoted context omitted.

I would say it's the same with Rust and Haskell. And I agree, the superior type system of these languages is really a game changer for me and it's very hard to go back to languages missing these features.

For a while, yes. I know from experience that going the other way is a struggle as well. Habits die hard and change takes effort. There's nothing superior about these type systems, they're simply two of the most static and rigid systems in circulation right now. Try writing C, Lisp and Forth until it clicks. Then we can sit down and have an informed discussion about missing features.

I think a lot of it could be personality based. With C, Lisp and Forth you bash out code and run it, see if it works and then make changes. You get much faster visual feedback.

With Haskell, you need to put in a lot more up front thought. Then stuff doesn't compile and you spend ages working out why.. You can go for hours without having anything running. The cause of the errors can be quite abstract and obtuse and may seem like it is nothing to do with the actual problem you are trying to solve.

Different people just suit different styles.

Re: Why you should learn F#

#104

Post by sparkie »

mobiliakas1 wrote: post #102
sparkie wrote: post #95

Earlier quoted context omitted.

I primarily use F# over C#, and I would prefer the interface version over the functions in many cases. An interface makes it a bit more explicit and self-explanatory what is expected to be passed. A Func , List > is not very meaningful and potentially ambiguous. Obviously, anywhere you expect more than one function, an interface is more desirable because it avoid the need to pass around multiple objects. One thing th…

You can use delegates in C# for that. delegate List SortAlgorithm(List values); List QuickSort(List values) => values; // Do QuickSort List MergeSort(List values) => values; // Do QuickSort void DoSomething(SortAlgorithm sort, List values) { var sorted = sort(values); } public void Main() { var values = new List { 9, 1, 5, 7 }; DoSomething(QuickSort, values); }

Yes, my point was more that they're pretty much the same thing. A delegate and an interface with a single method are essentially isomorphic in their behaviour.

The delegate obviously breaks down when you have more than one method. For that interfaces work just fine. Even in the case of using a delegate where you capture variables, the C# compiler creates a new type, instantiates it and passes the method in place of the delegate. It's hardly any different to deriving from an interface.

I just tend to use interfaces more out of habit even for single methods. Creating an object expression in F# is pretty much the same outcome as creating a closure in C#.

EDIT: I guess the other problem is that F# functions are not directly compatible with Func and Action types, so when calling a C# function expecting these, you need to wrap the call in an anonymous function. C# interfaces and F# classes are compatible though.

Re: Why you should learn F#

#105

Post by atombender »

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 run a compiled F# program you have to have Mono installed? It does look like you can get AOT compilation with Mono [1], but the limitations (e.g. no generics, apparently) seem too onerous.

[1] https://www.mono-project.com/docs/advanced/aot/

Re: Why you should learn F#

#106

Post by AdeptusAquinas »

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…

Its part of dotnet core, so you don't need Mono installed. And you can build a self-contained dotnet core application so you don't need core installed to run it.

AOT is possible via something like CoreRT, but its still a bit beta and not straightforward. From my experience the only limitation with CoreRT and F# is certain reflection heavy functionality. No problem with generics.

Re: Why you should learn F#

#107

Post by sparkie »

victorNicollet wrote: post #99
contravariant wrote: post #39

Earlier quoted context omitted.

I see, although it looks like you're really after a state-machine there. Which I admit aren't the easiest to create in C#, and immutability and null-safety definitely make it easier... Although personally I'd rather have the different states encapsulated in separate classes than a single type that encapsulates all possible states and enforces them through the constructor.

This is what F# does (define multiple classes), but each of these classes only takes one line of code.

Also, it defines them as nested classes, and marks the outer class as `sealed`, as they're closed types, and it prevents the type being extended with new cases.

C# can't do this because the compiler rejects putting `abstract` and `sealed` on the same type.

Re: Why you should learn F#

#108

Post by moron4hire »

I really wish Unity3D would relinquish control of my Visual Studio Solution files and have a much nicer path to including its libraries as a dependency manually so I could start using some of the other languages in the CLR ecosystem.

I've managed to get it to work before by very carefully searching for the DLLs in the Unity install directory and compiling my own DLLs into a Plugins folder in my Unity project, but it's very brittle. It's not obvious which set of DLLs to import (there are lots of different versions of each, for various rhyme platforms), and I upgrade new Unity versions frequently, so the location is a moving target. And Heaven help you if you want to depend on something that is only released as a script bundle in a Unity Package (like every VR SDK out there right now). And given how Unity's braindead YAML metafile system works, you're pretty sure to break your component references in your scenes and prefabs with even the most minor of rearchitecturings.

Unity having its own build pipeline is a huge impediment. It all but forces you to write custom scripts that do some of the most basic things, as if we live in the Node hellscape of Gulp/Grunt/Webpack. And none of it is documented well enough to get it right without hours of ping-pong with test runs.

Re: Why you should learn F#

#109

Post by mavelikara »

ambulancechaser wrote: post #29
contravariant wrote: post #16

Earlier quoted context omitted.

>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.

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 writes most of these lines for me. I believe C# will have similar or more succinct constrcuts.

Re: Why you should learn F#

#110

Post by atombender »

AdeptusAquinas wrote: post #106
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…

Its part of dotnet core, so you don't need Mono installed. And you can build a self-contained dotnet core application so you don't need core installed to run it. AOT is possible via something like CoreRT, but its still a bit beta and not straightforward. From my experience the only limitation with CoreRT and F# is certain reflection heavy functionality. No problem with generics.

Well, if not Mono, then the .NET Core runtime package, right? It's not self-contained. I read this [1], but it's unclear to me how I build a self-contained binary, or what options are available for AOT.

[1] https://github.com/dotnet/core/blob/master/Documentation/sel...

Post reply on HN