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

The Problem with F# Evangelism

thomasbandt.com

Post reply on HN
Print view View original

161–170 of 203 posts

Re: The Problem with F# Evangelism

#161

Post by pjmlp »

louthy wrote: post #117
com2kid wrote: post #40

Earlier quoted context omitted.

> Functional programming is also seeping in but again tons of boiler plate. The bar has moved so much on this one. I remember when C#'s wonderful lambda syntax, along with all the extension methods that LINQ added, qualified it as having pretty good functional programming support. Now that other languages have gone out and copied sane lambdas, and "Map" is in libraries left and right, C# has to keep reaching for that…

What does the higher bar look like to you? For me, the major missing features of C# are: * Immutable record types * ADTs with completeness pattern matching * Higher-kinds F# is also missing higher kinds, but can do the others. Did you have something else in mind?

None of them makes me write prettier GUIs or better use of EF.

Re: The Problem with F# Evangelism

#162

Post by pjmlp »

arwhatever wrote: post #136
phillipcarter wrote: post #17

I actually work on F# at Microsoft. I've had success and some failures when it comes to evangelizing F# through Microsoft (but mostly success if my measures are accurate). I strongly believe that it can be boiled down to one major thing: Programmers learn how to program with C-style languages. C, C++, Java, C#, JavaScript, Python (sorta) . . . they're all in the same family. People, especially while learning, associa…

I feel like someone invented a toaster oven that doesn't catch fire, but everyone wants to stick with the model that does catch fire all the time.

Because when you manage to actually make a meal on both of them, the ones from the latter taste better.

Re: The Problem with F# Evangelism

#163

Post by pjmlp »

toyotaboy wrote: post #131
TensorMetric wrote: post #75

The real problem with F# is that the .NET Native UWP runtime isn't .NET compliant, therefore doesn't allow F# code. See this link explaining the problem https://news.ycombinator.com/item?id=15026396 We wouldn't need to evangelize F#, if it just worked everywhere C# does with proper tooling support.

Barely anyone uses UWP. It's irrelevant.

Except for the people using Windows 10, developing with HoloLens, gaming on XBox ONE (after the latest firmware updates), or using Surface meeting boards.

Re: The Problem with F# Evangelism

#164

Post by rubber_duck »

louthy wrote: post #69
rubber_duck wrote: post #32

Earlier quoted context omitted.

I disagree with this, you can sell F# to C# developers - things like type providers for SQL checking their query strings in compile time and no extra build step to produce SQL type definitions vs monstrosities such as Entity Framework... if they've been burned by ORMs to drop to stuff like Dapper they'll love F# type providers. Immutable data is also becoming a common pattern even in C# but it's tedious as hell to wr…

> Immutable data is also becoming a common pattern even in C# but it's tedious as hell to write. I can simplify it for you: public class TestClass : Record { public readonly int X; public readonly string Y; public readonly Guid Z; public TestClass(int x, string y, Guid z) { X = x; Y = y; Z = z; } } That is an immutable type that has structural equality and ordering, a strong GetHashCode() implementation, as well as a…

>If you need `With` functionality, then add the following member:

Without it it's useless - and do that example when fields aren't named X, Y, Z but have actual descriptive property names + 5-10 properties like DB tables.

It gets ridiculous really fast.

>Do you have an example?

Record types, result piping (best you can do is extension methods - again boilerplate), pattern matching, etc.

I recently wrote a C# report integration service - it was a C# service that connected to a DB at specific time intervals, did a bunch of data transformations then passed it off to different services over file system or TCP. Wrote it functional style with C# (immutable collections, record types, static functions).

I then rewrote the same project in F# because I wanted how much simpler the code would be in practice - off the top of my head I managed to reduce a ~20k LOC project filled with boilerplate to ~6k LOC of pure business logic data transformation and protocol specific data formatting. IIRC I had 5 logically grouped source files in F# that had connected logic inside of them (ie. record types were "one liners" defined in the same file they were used not a separate file like the C# tediousness)

The resulting code was easier to read because there was just less crap, easier to test from REPL/debug isolated issues and unit test.

C# is not Java but it's still ridiculously verbose for high level programming.

Re: The Problem with F# Evangelism

#165

Post by bonesss »

ice109 wrote: post #154
brianberns wrote: post #37

Earlier quoted context omitted.

C# developers in my shop loathe the SQL type provider because it requires them to have a compatible SQL Server database schema at build-time. The extra level of organization required is more than they can accept.

that kind of thing is a collosal mistake in my opinion - just on the face of it I/o at compile time seems very wrong.

An understandable position.

Here's the context that makes it not a big deal:

1) If there is some fundamental issue with having a dev DB then you would just use another ORM, just like in C#. Really, this specific type provider is not an ORM, it's for SQL server data munging. Most every project I've seen in a decade has multiple dev DBs, many used in testing, many used for staging... being able to talk to a valid schema source should be relatively straightforward... but if it isnt then get a different type provider or use an ORM with explicit code generation.

2) Compile time guarantees about data sources is a huge source of comfort when dealing with DBs owned by external actors or teams. For data scientist, integrator, sys admins, and such the norm is connecting to operational DBs that you have very little control over. This specific Type Provider ensures that your scripts will not compile if there has been a breaking schema change. That means you're seeing these issues during deployment, not as costly runtime errors that may or may not corrupt your application state. Less debugging, more safety, better guarantees, immediate feedback on issues; all in realtime.

To summarize: if compile time validation of JSON structures, XML structures, SQL Schema, or custom file formats creates some kind of pain, then don't use a provider of types that relies on analyzing data structures to create code :)

For the other 99.9999% of the time type providers are a DREAM for working with external data sources, provide most of what we want ORMs for, and are very lightweight in comparison. It's rapid data exploration with built in prototyping. Very nice.

Re: The Problem with F# Evangelism

#166

Post by bonesss »

pjmlp wrote: post #128
nlawalker wrote: post #124

The problem with F# evangelism is that it doesn't exist. No one is evangelizing F#; everyone is evangelizing functional programming. F# is the Python of .NET - it's multi-paradigmatic and you can do whatever you want. Sell it to people that way, and let them get into functional concepts later, or never. F# has a huge opportunity in the enterprise. A ton of enterprise C# code is not object oriented at all, it's big, p…

> If you want to sell F# to enterprise developers, show them how they can write their C# code in it without having to pretend that it's object oriented anymore, and how that's a good thing. As enterprise consultant, for the types of customer projects I work with, lack of tooling support for Blend, WPF, UWP, EF, ASP.NET is a no-go to move from C# into F#.

Domain modelling in F# is lightyears beyond C#s. Parallel and concurrent development, not to mention actor systems (F#s built-in or Akka.net), are also leaps and bounds beyond the C# story. These are Enterprise issues. Identity management, default immutability, distate for null, and exhaustive pattern matching are all major Enteprise features that large, complex, and critical systems see measurable benefit from...

There is no barrier to mingling F# and C# libs to focus on specific tasks or parts of the app. Having application libraries in C# and domain code in F# is a common pattern. Particularly at the GUI level, extra-particularly with anything that uses databinding so your domain types can be used directly.

F# does not get the same amount of tooling love as C# for the "latest and greatest" from microsoft. If you look at the Enterprise track record of Microsofts "latest and greatest" since they started pushing ADO.net to present day... well, I would argue that's a huge benefit. Enterprise customers need tooling stability and platform stability, so letting ASPvReplacedInThreeMonths come and go without impacting projects is a big money saver.

Re: The Problem with F# Evangelism

#167

Post by bonesss »

brianberns wrote: post #87
d--b wrote: post #85

Earlier quoted context omitted.

It just adds up, and right now the combination of these annoyances outweighs the benefits of using F# for me.

This is how my C# developers feel as well. Personally, I've concluded that F# is a more reasonable language than C#, so I see these "annoyances" as challenges that are not a big problem.

Miguel de Icaza commented on a trend they've seen with the C# devs on Mono/Xamarian that matches well with my experience: the C# devs who start using F# simply do not come back.

F# is the first language built on top of a mature .Net framework, and it shows. Much of what has made C# become so great was pushed through the F# research group (remember when C# didn't have generics?... yeah...).

It is not Microsofts favorite child. It will never be the implementation language of MS's next GUI platform du jour.

Personally, looking at old XAML, Silverlight, EF1, EF2, EF3, EF4, EF5, and EF6 projects... [oh hey, EF7 is out, and it _still_ has no second level cache story! Back to NHibernate everybody!... again!] ... I do not think it's a bad thing to have some distance between production and Microsofts first-run attempts at products.

Re: The Problem with F# Evangelism

#168

Post by pjmlp »

bonesss wrote: post #166
pjmlp wrote: post #128

Earlier quoted context omitted.

> If you want to sell F# to enterprise developers, show them how they can write their C# code in it without having to pretend that it's object oriented anymore, and how that's a good thing. As enterprise consultant, for the types of customer projects I work with, lack of tooling support for Blend, WPF, UWP, EF, ASP.NET is a no-go to move from C# into F#.

Domain modelling in F# is lightyears beyond C#s. Parallel and concurrent development, not to mention actor systems (F#s built-in or Akka.net), are also leaps and bounds beyond the C# story. These are Enterprise issues. Identity management, default immutability, distate for null, and exhaustive pattern matching are all major Enteprise features that large, complex, and critical systems see measurable benefit from... Th…

> There is no barrier to mingling F# and C# libs to focus on specific tasks or parts of the app.

Try that on .NET Native apps.

> F# does not get the same amount of tooling love as C# for the "latest and greatest" from microsoft.

No tooling for Blend, WPF, UWP, EF, ASP.NET, no reason to switch and suffer a productivy drop.

Re: The Problem with F# Evangelism

#169

Post by naasking »

pjmlp wrote: post #160
louthy wrote: post #155

Earlier quoted context omitted.

> In C# 6.0 you can also make them properties instead of fields Why would I want to? It's more boilerplate for no gain. I have never understood the obsession with properties over fields. I realise that to some serialisation or interop libraries that rely on reflection to access properties it's important, but to my mind, those solutions should also support public fields. And obviously inheritance-land with interfaces,…

> I have never understood the obsession with properties over fields. Encapsulation, allowing to change the internal representation without requiring clients to update or recompile their code. Ensuring the class invariants are always kept valid.

> Encapsulation, allowing to change the internal representation without requiring clients to update or recompile their code

This benefit is exaggerated. In practice, classes end up being either record-like where you need visibility on all the actual fields, or they are protocol-like/more fully encapsulated with few public members and more methods. The addition of properties was a big mistake IMO.

Read/write fields should just be part of interface specifications. There is little value beyond that.

Re: The Problem with F# Evangelism

#170

Post by naasking »

pjmlp wrote: post #161
louthy wrote: post #117

Earlier quoted context omitted.

What does the higher bar look like to you? For me, the major missing features of C# are: * Immutable record types * ADTs with completeness pattern matching * Higher-kinds F# is also missing higher kinds, but can do the others. Did you have something else in mind?

None of them makes me write prettier GUIs or better use of EF.

Actually, higher kinds could make you write more composable and reusable GUIs. I don't see why "prettier" is the only metric of interest.

Immutable records also makes it easier to share data safely, thus making scaling across cores easier in some cases, without worrying about plan interference.

Post reply on HN