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

181–190 of 203 posts

Re: The Problem with F# Evangelism

#181

Post by dcdcdcdc »

pjmlp wrote: post #168
bonesss wrote: post #166

Earlier quoted context omitted.

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.

I'm not a C# programmer, but it seems to me that the productivity drop argument is weird. Your engineers might be in a local maximum, and it might be worth the temporary productivity drop, if in the long run it would allow them to reach new (and better) heights. This, of course, is an outsider's supposition, and I understand that you're just conveying their point of view.

Re: The Problem with F# Evangelism

#182

Post by naasking »

pjmlp wrote: post #179
naasking wrote: post #178

Earlier quoted context omitted.

> Properties go all the way back to Smalltalk, which doesn't expose class internal data. Right, because Smalltalk doesn't conflate the use of public and internal members. Properties are second class citizens on .Net, since you can't pass them as ref or out arguments, but we can't use fields which are first class citizens because they have inadequate permissions control. Then properties exist, but also don't really ex…

> Properties are second class citizens on .Net, since you can't pass them as ref or out argument There is nothing at IL level that prevents it, they can eventually lift the restriction if they feel like it. > Properties don't help with changing more than one field either, so I'm not what your point is. The setter can do a cascade set of changes while keeping the invariants.

> There is nothing at IL level that prevents it, they can eventually lift the restriction if they feel like it.

While theoretically true, it will never happen. The whole point of ref/out parameters is efficient, direct pointer access to a member. This can never be made efficient for properties. The CLR GC is carefully tuned to handle internal pointers like this, so quite a bit of engineering has gone into making this efficient and safe, which means efficiency is important.

Furthermore, properties are entirely redundant with the simple change I suggested. They literally serve no purpose once you have permissions on fields, since methods cover the remaining use cases.

> The setter can do a cascade set of changes while keeping the invariants.

And so can methods. If you have mutating this much state, you should be invoking a method anyway. Properties are not the place for sophisticated behaviour.

Re: The Problem with F# Evangelism

#183

Post by pjmlp »

dcdcdcdc wrote: post #181
pjmlp wrote: post #168

Earlier quoted context omitted.

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

I'm not a C# programmer, but it seems to me that the productivity drop argument is weird. Your engineers might be in a local maximum, and it might be worth the temporary productivity drop, if in the long run it would allow them to reach new (and better) heights. This, of course, is an outsider's supposition, and I understand that you're just conveying their point of view.

How it is weird having a productivity drop when everything that is done graphical by tools with a simple mouse click, must be done manually in plain code without any kind of visual assistance, beyond "compile and see how it looks like"?

Re: The Problem with F# Evangelism

#184

Post by macca321 »

louthy wrote: post #63
macca321 wrote: post #47

Earlier quoted context omitted.

I think a better approach is encouraging the use of functional/F# concepts in C#.

I take this approach in my language-ext project [1]. I wrote it because as well as wanting to use F#, I had a decade old C# project to maintain, and I wanted to bring functional techniques into. We're (my team) finding that the pull to to F# is diminishing quite significantly; this is partly due to the functional framework features I've added to lang-ext; partly the new features of C# (expression bodied members, tupl…

We're singing from the same hymn sheet :)

https://github.com/mcintyre321/OneOf https://github.com/mcintyre321/ValueOf

Re: The Problem with F# Evangelism

#185

Post by TensorMetric »

toyotaboy wrote: post #171
TensorMetric wrote: post #138

Earlier quoted context omitted.

All those features mean nothing to seasoned .NET developers when you can't use the language natively on Microsofts primary application platform.

You can gripe about your fav UI stack not being supported just the way you want (you don't seem to have any other complaints), but your claim the language is not improving is wrong.

> You can gripe about your fav UI stack not being supported just the way you want (you don't seem to have any other complaints),

.NET Native and UWP are not just UI,

> but your claim the language is not improving is wrong.

You're confusing me with the parent commenter https://news.ycombinator.com/item?id=15029008

Re: The Problem with F# Evangelism

#186

Post by TensorMetric »

toyotaboy wrote: post #173
TensorMetric wrote: post #97

Earlier quoted context omitted.

The first-class IDE for F# is the full Visual Studio, not VS Code + Ionide.

VS Code is now recommended by Microsoft for F# + .NET Core. Get with it, you're behind the times.

It's only recommended temporarily, until the issues get ironed out. It doesn't make it THE first-class F# IDE.

Re: The Problem with F# Evangelism

#187

Post by TensorMetric »

toyotaboy wrote: post #174
GiorgioG wrote: post #59

Earlier quoted context omitted.

I'll get excited when the Visual Studio team actually holds up a release because something is horribly broken in its F# support. So basically...never.

Just use VS Code + Ionide. That's where the action is for at least for F# + .NET Core

It's misleading to pretend that it's a substitute for full Visual Studio.

Re: The Problem with F# Evangelism

#188

Post by DeepRote »

leshow wrote: post #119
DeepRote wrote: post #18

Earlier quoted context omitted.

Neither are making "big strides". They both are barely able to exist. Eta will never even approach Scala in terms of adoption, and I had only heard about Purescript a few weeks ago reading about Elm. Typescript will dominate functional JS-world (already is, tbh) and Scala is still crushing function JVM-world, and if Dotty ever actually materializes, adoption will get even better. Additionally, Scala-Native and ScalaJ…

> ScalaJS are making progress and could eventually be real players. So ScalaJS could be a "real player" but PureScript is barely able to exist? Forgive me if I don't just take your word for it.

ScalaJS already is a real player, it just doesn't stack up to Typescript.

I'm not making this shit up out of thin air, look at usage numbers.

Purescript is not going anywhere, most likely ever.

Re: The Problem with F# Evangelism

#189

Post by TensorMetric »

twodave wrote: post #121
phillipcarter wrote: post #86

Earlier quoted context omitted.

Perhaps it's worth taking a different viewpoint. With VS 2017, no single release updates every part of the product to the latest things. For example, UWP does not support .NET Standard 2.0 yet. That did not put the VS 2017 15.3 release on hold. Similarly, although F# fully supports .NET Core and .NET Standard 2.0 with this release, the tooling quality wasn't high enough for us to declare the associated tooling suppor…

This, and also VS2017 did in fact ship C# without some things (for instance, full support for value tuples).

This is minor compared to all the major things VS isn't shipping for many years in a row now.

Re: The Problem with F# Evangelism

#190

Post by tarmil »

brianberns wrote: post #37
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…

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.

Actually, for the providers from FSharp.Data.TypeProviders, it's only necessary when you need to pull a schema change.

You can pass `LocalSchemaFile = "foo.ssdl", ForceUpdate = false` to the provider, and it will only try to connect to the database if the file foo.ssdl doesn't exist; if it does, then the provider just uses it to compute the schema. When the schema changes, you just need to set ForceUpdate to true, wait for the IDE to pull the changes from the server and write foo.ssdl, then set ForceUpdate back to false, and you can commit the changed file.

Post reply on HN