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

151–160 of 203 posts

Re: The Problem with F# Evangelism

#151

Post by phillipcarter »

d--b wrote: post #84
phillipcarter wrote: post #33

Earlier quoted context omitted.

> #1 tooling: visual studio integration of F# is poor. You don't get cross language usage reference, so you lose all the benefits of static typic. Projects and references are a mess. Being primarily a scripting language, it feels like a toy language Could you clarify what you mean here? Although things like Go to Definition and Find all References don't work across C#/F# boundaries (yet), but you absolutely get Intel…

You get intellisense alright. But using C#, I never need to #open the namespaces myself for it to find the types I am using or the extension methods I need. (Maybe this is because I use resharper, but still, it really slows me down). Also the benefits of static typing are that it makes it easy to refactor. Here if I change things in C#, I need to grep my F# scripts for usage, it's a real pain.

> You get intellisense alright. But using C#, I never need to #open the namespaces myself for it to find the types I am using or the extension methods I need. (Maybe this is because I use resharper, but still, it really slows me down).

This is actually added in F# tooling for VS 2017! Both via a lightbulb code fix and with IntelliSense itself. If you have a reference to a .dll with symbols, the IDE can suggest an open statements for you.

Re: The Problem with F# Evangelism

#152

Post by phillipcarter »

mevile wrote: post #143
phillipcarter wrote: post #82

Earlier quoted context omitted.

Could you clarify what you had problems with? F# comes with Visual Studio (and VS for Mac), has templates, and builds/runs/debugs/etc out of the box. No need to configure beyond checking "F# language support" in the installer for VS 2017 (and in some cases, the Workloads in that installer come with F# already-checked).

Thank you, that was a really helpful comment! That seems to have been the problem. I had Visual Studio installed already and I just reran an installer and that gave me the option to install F#. That I needed to run the installer for visual studio again, that I couldn't just install F# support some other way, that just wasn't clear to me. I have to say that messing around in visual studio in F# just now was extremely…

You're welcome! The bug you're experiencing is known and fixed (both in nightlies and a servicing fix).

VSCode and F# is a great experience! We have some guides about how to get started with F# here: https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/

Re: The Problem with F# Evangelism

#153

Post by tome »

earthtolazlo wrote: post #105
tome wrote: post #50

Earlier quoted context omitted.

How many times have you had the runtime exception AttributeError: 'NoneType' object has no attribute 'foo' (or its equivalent in your favourite language)?

That's something addressed by static typing though. I'm pretty sure any dynamic language has that issue, functional or not.

It's fair to say that the boundaries of "functional programming" are pretty amorphous and I certainly didn't mean untyped functional programming. In any case, if you want to prevent null/None errors in a way that gives the programmer his/her own access to create similar new abstractions then you need

* sum types

* parametric polymorphism

* pattern matching

at which point you may as well also add

* first class functions

and then if you don't describe your language as "typed functional" then how do you describe it?

Re: The Problem with F# Evangelism

#154

Post by ice109 »

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.

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.

Re: The Problem with F# Evangelism

#155

Post by louthy »

jdmichal wrote: post #145
louthy wrote: post #69

Earlier quoted context omitted.

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

In C# 6.0 you can also make them properties instead of fields, though I have no idea if this works with your "Record" class. public class TestClass { public int X { get; } public string Y { get; } public Guid Z { get; } public TestClass(int x, string y, Guid z) { X = x; Y = y; Z = z; } } And C# 7.0 shortens this to: public class TestClass( int X, string Y, Guid Z);

> 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, but I find writing in a functional style that interfaces tend to be a rarity rather than the default setting.

> though I have no idea if this works with your "Record" class.

Yes, field backed properties are supported in the structural equality and ordering.

> And C# 7.0 shortens this to...

It doesn't. That maybe coming in a later release, but neither C# 7.0 nor 7.1 support the record syntax.

Re: The Problem with F# Evangelism

#156

Post by zeugmasyllepsis »

DeepRote wrote: post #107
rlander wrote: post #100

Earlier quoted context omitted.

What's with the "Clojure is dying" meme? In the last few months I've seen an uptake in Clojure jobs.

The fallacy there is that Clojure development is drastically slowing in favor cljs. Because there's jobs doesn't mean anything with regards to dev status. My dad has been writing COBOL for 30+ years, but I think we could both agree that it's a dead language in a certain sense. My first language was Scheme. I wrote some stupid BATCH scripts at school and decided I wanted to learn to program. I worked my way through ha…

I thought Elixir supported type annotations and could perform static analysis via Dialyzer? [1]

[1] https://hexdocs.pm/elixir/typespecs.html

Re: The Problem with F# Evangelism

#157

Post by tjalfi »

louthy wrote: post #155
jdmichal wrote: post #145

Earlier quoted context omitted.

In C# 6.0 you can also make them properties instead of fields, though I have no idea if this works with your "Record" class. public class TestClass { public int X { get; } public string Y { get; } public Guid Z { get; } public TestClass(int x, string y, Guid z) { X = x; Y = y; Z = z; } } And C# 7.0 shortens this to: public class TestClass( int X, string Y, Guid Z);

> 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,…

C# 7 does allow one to shorten that class a bit further. I saw this trick in the MEAP[0] of C# in Depth.

    public class TestClass
    {
        public int X { get; }
        public string Y { get; }
        public Guid Z { get; }

        public TestClass(int x, string y, Guid z) => (X, Y, Z) = (x, y, z);
    }
Disclaimer: I don't combine expression-bodied constructors and tuple construction/deconstruction in my code. I will use either feature but the combination seems likely to annoy my coworkers. I also haven't measured the costs of this idiom.

[0] https://www.manning.com/books/c-sharp-in-depth-fourth-editio...

Re: The Problem with F# Evangelism

#158

Post by brianberns »

mbenoni7 wrote: post #108
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.

There's a new type provider out that takes a different approach by bundling a SQL parser: https://github.com/rspeele/Rezoom.SQL It can't check everything that the other providers can, but IMO you get most of the benefit without requiring any onerous build-time dependencies.

Very cool. Thank you.

Re: The Problem with F# Evangelism

#159

Post by brianberns »

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.

Why? Compilers have to read source files anyway. What's wrong with reading other stuff as well? For example, there are type providers for XAML, JSON, app.config, etc. Do they also seem wrong to you?

Re: The Problem with F# Evangelism

#160

Post by pjmlp »

louthy wrote: post #155
jdmichal wrote: post #145

Earlier quoted context omitted.

In C# 6.0 you can also make them properties instead of fields, though I have no idea if this works with your "Record" class. public class TestClass { public int X { get; } public string Y { get; } public Guid Z { get; } public TestClass(int x, string y, Guid z) { X = x; Y = y; Z = z; } } And C# 7.0 shortens this to: public class TestClass( int X, string Y, Guid Z);

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

Post reply on HN