171–180 of 203 posts
Earlier quoted context omitted.
For library, see https://github.com/fsharp/fslang-design/blob/master/FSharp-4...
All those features mean nothing to seasoned .NET developers when you can't use the language natively on Microsofts primary application platform.
Earlier quoted context omitted.
No one who knew what they were talking about at Microsoft said F# was for mathematicians and engineers. It's a myth pushed by C# programmers and idiots. It's nonsense and you shouldn't repeat it. People at Microsoft repeatedly said "Simple Code for Simple Problems". C# programmers don't like repeating that.
Doesn't matter if they didn't know what they're talking about, that was what was written on the Microsoft sites when comparing C#, VB, F#. F# was always pigeonholed into scientific and financial categories, never aimed at general code. I'm only repeating it to point out that MS itself did poor marketing for F#, clearly favouring C#.
Earlier quoted context omitted.
The first class IDE for F# is VS Code + Ionide. The language service backend for F# is also very well supported for emacs.
The first-class IDE for F# is the full Visual Studio, not VS Code + Ionide.
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'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.
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…
Speaking of Jet.com and their billion, here is their GitHub page, https://github.com/jet :(
Earlier quoted context omitted.
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.
Immutable records are already possible today in C#, even if a bit more verbose than on F#, plus EF code is anyway mostly generated.
Earlier quoted context omitted.
> 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 sh…
Properties go all the way back to Smalltalk, which doesn't expose class internal data.
> Read/write fields should just be part of interface specifications. There is little value beyond that.
No because you cannot ensure their invariants, specially if more than one field needs to change at the same time.
Earlier quoted context omitted.
> 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 sh…
> The addition of properties was a big mistake IMO. Properties go all the way back to Smalltalk, which doesn't expose class internal data. > Read/write fields should just be part of interface specifications. There is little value beyond that. No because you cannot ensure their invariants, specially if more than one field needs to change at the same time.
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 exist at the reflection level, where you have to search for getters and setters by mangled name if they're private. It's a total frickin mess.
> No because you cannot ensure their invariants, specially if more than one field needs to change at the same time
Properties don't help with changing more than one field either, so I'm not what your point is.
And you can ensure invariants with field permissions, which is what I suggested. Publicly read-only but privately writable is all you need, then the values change via method invocations. Most use of properties just add permissions to field access anyway.
Read/write with default const/init-only fields should have been the default. Then you can't pass read-only fields as ref or out arguments due to permissions, not because they're second class citizens.
Earlier quoted context omitted.
> The addition of properties was a big mistake IMO. Properties go all the way back to Smalltalk, which doesn't expose class internal data. > Read/write fields should just be part of interface specifications. There is little value beyond that. No because you cannot ensure their invariants, specially if more than one field needs to change at the same time.
> 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…
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.
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…
I'm interested to know why you describe EF as a monstrosity? Genuine interest, I just started using EF for the first time a few weeks ago for a work project so I've only scratched the surface but it didn't seem terrible, although I did find that only being able to update all tables after a change to the database as opposed to a single table to be a bit of a limitation.
Contrast that with type providers - they expose SQL to the compiler - this way you get compile time SQL query checking, type checking (it generates types for SQL queries) and it's manipulating data as input and output with known standard SQL semantics.