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

Why F#?

batsov.com

Post reply on HN
Print view View original

411–420 of 424 posts

Re: Why F#?

#411

Post by GiorgioG »

aaronmu wrote: post #407
GiorgioG wrote: post #126

Earlier quoted context omitted.

As a 20+ year C# dev...where do I learn how to structure apps in F#? In C# my ASP.NET Controller might use a service (or a mediator) to execute some domain logic and that in turn will use a repository pattern (or EF DbContext) to update/query a database. How are dependencies injected in? It seems like there are multiple ways of going about it, but I don't have enough knowledge of F# to know 'the proper way' to do it.

Just start. Use whatever style you are used to. Use controllers. Adapt your style as F# pulls you deeper inside the pit of success. You'll struggle the first couple of features, but you'll reach a sweet spot between your current style and functions relatively fast.

I suspect you're right. I just have to get over the hump of being uncomfortable/fumbling my way through things that I would otherwise know how to do in C#. Thanks!

Re: Why F#?

#412

Post by caspper69 »

tubthumper8 wrote: post #408
caspper69 wrote: post #194

Earlier quoted context omitted.

It has been in discussion for quite some time. I believe they'll get there soon: (example) https://dev.to/canro91/it-seems-the-c-team-is-finally-consid... In the interim, MS demonstrates how C# 8.0+ can fake it pretty well with recursive pattern matching: https://learn.microsoft.com/en-us/dotnet/csharp/language-ref... Not the same I know, and I would love me a true ADT in C#. Edit (a formal proposal): https://github.…

There's also going to be quite a big ecosystem / standard library difference between languages that had fundamental type system features since the beginning vs. languages that added fundamental features 23 years later. Imagine all the functions that might return one thing or another, which was inexpressible in C# (until this proposal is shipped), will all these functions release new versions to express what they coul…

Having reviewed the proposal (of course no guarantee that's what discriminated unions (aka product types aka algebraic data types) will look like), and it appears that it very much integrates nicely with the language.

I don't suspect they'll make too many changes (if any) to the existing standard library itself, but rather will put functions into their own sub-namespace moving forward like they did with concurrent containers and the like.

Given their penchant for backwards compatibility, I think old code is safe. Will it create a schism? In some codebases, sure. Folks always want to eat the freshest meat. But if they do it in a non-obtrusive way, it could integrate nicely. It reminds me of tuples, which had a similar expansion of capabilities, but the integration went pretty well.

Re: Why F#?

#413

Post by klysm »

bob1029 wrote: post #240
klysm wrote: post #224

Earlier quoted context omitted.

> if we are concerned about the underlying data shifting when the collection is actually enumerated I’m not sure what you mean by this. You can fulfill the IEnumerable contract without allowing multiple enumerations, but that doesn’t really have to do with the data shifting around. Doing ToList can be an expensive and unnecessary allocation

Imagine a live SQL query you are subsequently filtering with LINQ.

Then the ToList will force it to be evaluated on the client - not sure that situation applies

Re: Why F#?

#414

Post by klysm »

DeathArrow wrote: post #330
klysm wrote: post #90

Earlier quoted context omitted.

This isn’t a great example of what linq is good at. There’s no reason to do ToList there, and the ForEach isn’t particularly idiomatic

Yes, ForEach isn't idiomatic but he could use Select instead.

Side effects in a Select is not idiomatic either

Re: Why F#?

#415

Post by LinearEntropy »

110bpm wrote: post #249

I put together a quick-start guide to F# Computation Expressions — showing how you can go from C# async/await all the way to Result workflows with let!... and!... expressions, and even a custom validation {} CE. [0] This is a practical side of F# that doesn’t get enough spotlight — but one I’m using daily. [0]: https://news.ycombinator.com/item?id=42636791

That was a great read. Thanks for sharing.

Re: Why F#?

#416

Post by tubthumper8 »

caspper69 wrote: post #412
tubthumper8 wrote: post #408

Earlier quoted context omitted.

There's also going to be quite a big ecosystem / standard library difference between languages that had fundamental type system features since the beginning vs. languages that added fundamental features 23 years later. Imagine all the functions that might return one thing or another, which was inexpressible in C# (until this proposal is shipped), will all these functions release new versions to express what they coul…

Having reviewed the proposal (of course no guarantee that's what discriminated unions (aka product types aka algebraic data types) will look like), and it appears that it very much integrates nicely with the language. I don't suspect they'll make too many changes (if any) to the existing standard library itself, but rather will put functions into their own sub-namespace moving forward like they did with concurrent co…

>that's what discriminated unions (aka product types aka algebraic data types)

Just an FYI, discriminated unions are not product types, they are sum types. It's named so because the total number of possibilities is the sum of the number of possibilities for each variant.

Ex. A sum type Color is a PrimaryColor (Red, Blue, Yellow) OR a SecondaryColor (Purple, Green, Orange), the total number of possibilities is 3 + 3 = 6.

For a product type, if a ColorPair is a PrimaryColor AND a SecondaryColor, the total number of possibilities is 3 * 3 = 9

Both sum types and product types are algebraic types, in the same way that algebra includes both sums and products.

For the standard library, I'm curious for the family of TryParse kind of functions, since those are well modeled by a sum type. Maybe adding an overload without an `out` argument would give you back a DU to `switch` on

Re: Why F#?

#417

Post by caspper69 »

tubthumper8 wrote: post #416
caspper69 wrote: post #412

Earlier quoted context omitted.

Having reviewed the proposal (of course no guarantee that's what discriminated unions (aka product types aka algebraic data types) will look like), and it appears that it very much integrates nicely with the language. I don't suspect they'll make too many changes (if any) to the existing standard library itself, but rather will put functions into their own sub-namespace moving forward like they did with concurrent co…

>that's what discriminated unions (aka product types aka algebraic data types) Just an FYI, discriminated unions are not product types, they are sum types. It's named so because the total number of possibilities is the sum of the number of possibilities for each variant. Ex. A sum type Color is a PrimaryColor (Red, Blue, Yellow) OR a SecondaryColor (Purple, Green, Orange), the total number of possibilities is 3 + 3 =…

I make that mistake more often than I care to, but you are 100% spot-on. They are sum types, not product types. Thank you for making me walk the walk of shame!

Re: Why F#?

#419

Post by netdevphoenix »

ninalanyon wrote: post #223
netdevphoenix wrote: post #23

Earlier quoted context omitted.

you are not supposed to do oop in f#

Why not? It does it very well, better than C# in my opinion. At least that was the case ten years ago when I last used C# and played with F#.

It probably depends on your definition of "OOP" and your definition of "better"

Re: Why F#?

#420

Post by tubthumper8 »

GiorgioG wrote: post #411
aaronmu wrote: post #407

Earlier quoted context omitted.

Just start. Use whatever style you are used to. Use controllers. Adapt your style as F# pulls you deeper inside the pit of success. You'll struggle the first couple of features, but you'll reach a sweet spot between your current style and functions relatively fast.

I suspect you're right. I just have to get over the hump of being uncomfortable/fumbling my way through things that I would otherwise know how to do in C#. Thanks!

"pit of success" from the previous comment might refer to this video, which is long but good especially to adjust to a different mindset

https://youtu.be/US8QG9I1XW0?si=N07ZsYSYfA12mGVc

Post reply on HN