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

61–70 of 179 posts

Re: Why you should learn F#

#61

Post by daxfohl »

jdmichal wrote: post #53
daxfohl wrote: post #33

The only thing I don't like is the DI story presented here and many other F# guides. Having gone down that rabbit hole and using F# in production for 5 years now, I have gone back to classes and interfaces in almost all cases. Functions as DI mechanism suffers from a few things. First, it's hard to search for implementations. They could be defined anywhere. With interfaces, the implementations are a hot key away. Sec…

Can the F# compiler not convert a lambda to a single-function interface instance? Honest question. I'm mostly a Java guy, and I know that is how Java works under the hood because the JVM does not have the concept of delegates. But it seems like a fairly simple and safe transformation, even when your underlying target does have delegates.

No, while implementing such a feature wouldn't be difficult, one of F#'s imperatives is to ensure type conversions are explicit everywhere. Plus, given dotnet does have delegates, and F# has anonymous classes that would give a one-line workaround, this feature would be of limited use.

Re: Why you should learn F#

#62

Post by dvlsg »

jadbox wrote: post #42
daxfohl wrote: post #33

The only thing I don't like is the DI story presented here and many other F# guides. Having gone down that rabbit hole and using F# in production for 5 years now, I have gone back to classes and interfaces in almost all cases. Functions as DI mechanism suffers from a few things. First, it's hard to search for implementations. They could be defined anywhere. With interfaces, the implementations are a hot key away. Sec…

It sounds like your (more or less) just using classes for just namespacing functions and allowing bundles of functions to get brought in?

I've definitely structured f# modules that way. The module exposes one function that "injects" the dependency into multiple other functions, and then returns them as a blob.

I'm not sure if that's "the fsharp way" (i suspect it isn't) and maybe I'll look back on it some day and cringe, but it's working pretty well for some of my (admittedly small) side projects I'm tinkering with right now.

Re: Why you should learn F#

#63

Post by avisser »

Annatar wrote: post #58

I don't touch anything that runs on CLR or a JVM: waiting for the world to compile is unacceptable. For functional programming, I'll just continue learning ANSI common Lisp which compiles straight to machine code, thank you very much.

Any reason in particular why it's "unacceptable"?

Re: Why you should learn F#

#64

Post by KallDrexx »

jadbox wrote: post #42
daxfohl wrote: post #33

The only thing I don't like is the DI story presented here and many other F# guides. Having gone down that rabbit hole and using F# in production for 5 years now, I have gone back to classes and interfaces in almost all cases. Functions as DI mechanism suffers from a few things. First, it's hard to search for implementations. They could be defined anywhere. With interfaces, the implementations are a hot key away. Sec…

It sounds like your (more or less) just using classes for just namespacing functions and allowing bundles of functions to get brought in?

Not the OP but IME with a lot of web/api development work this seems to be the case more than not.

I do realize that most web work is really more functional than OOP, but classes do make it very easy to bundle dependencies without adding noise to the implementation/signatures.

Re: Why you should learn F#

#65

Post by algorithmsRcool »

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…

You are right about the first example (although the F# version looks nicer =D)

But that struct example is less than great.

Just last night I had a readonly C# struct like that, that I used as a dictionary key and wondered why my perf tests took a nose dive when the Dictionary hit a few dozen entries.

My boneheaded mistake was i forgot to override GetHashCode and Object.Equals. Great my perf was looking decent, but even then I was allocating 32 bytes of memory on every lookup.

I forgot I needed to also implement IEquatable to prevent boxing on calls to Object.Equals.

My little 2 item struct is 3 lines of definition and 7 lines of boiler plate to get it right. and my GetHashCode impl is suboptimal.

F# records do all of that for you. every time. automatically.

Re: Why you should learn F#

#66

Post by mcintyre1994 »

pjmlp wrote: post #11
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…

F# is the evolution of ML.NET developed at Microsoft Research.

That makes sense, thanks! :)

Re: Why you should learn F#

#67

Post by drblast »

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…

In the first example the named interface would be easier for me to read in a large project than Func, List> and with actual code there for implementation the two lines to define the interface would end up being a tiny fraction of the total lines of code. An interface would also provide better documentation opportunities for someone trying to write a mock or new implementation.

The code in the article isn't outlandish or particularly verbose.

Re: Why you should learn F#

#68

Post by dustinmoris »

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…

Your sort solution limits which algorithms can be used, because you can't pass in a Func which might need an additional parameter anymore.

This is why most C# developers would use an interface for this. With an interface you add extra parameters or dependencies to the constructor of the concrete implementation. If this example wasn't sort algorithms but password hashing algorithms this would be clear.

So yeah.. it proves my point... writing good C# is not that easy, requires a lot of experience and mistakes before someone knows how to write SOLID code in C#. Thanks for helping my point!

Re: Why you should learn F#

#69

Post by algorithmsRcool »

dustinmoris wrote: post #68
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…

Your sort solution limits which algorithms can be used, because you can't pass in a Func which might need an additional parameter anymore. This is why most C# developers would use an interface for this. With an interface you add extra parameters or dependencies to the constructor of the concrete implementation. If this example wasn't sort algorithms but password hashing algorithms this would be clear. So yeah.. it pr…

Just to be clear, you are arguing the superiority of partial application/currying here right?

Because your F# example is the same except it's trading Func, List for (int list -> int list)

Re: Why you should learn F#

#70

Post by Annatar »

avisser wrote: post #63
Annatar wrote: post #58

I don't touch anything that runs on CLR or a JVM: waiting for the world to compile is unacceptable. For functional programming, I'll just continue learning ANSI common Lisp which compiles straight to machine code, thank you very much.

Any reason in particular why it's "unacceptable"?

It's slow and bloated. For someone who grew up coding intros and cracking protections in machine code on C=64 and the Amiga, such bloat simply won't fly. It's an abomination. I hate wasting my life away waiting for slow software.
Post reply on HN