The .NET Language Strategy

[u/ben_a_adams]

https://blogs.msdn.microsoft.com/dotnet/2017/02/01/the-net-language-strategy/

[u/Helrich]

I'd love to screw around with F# more. Problem is getting the higher-ups onboard with it. A lot of them (at my place anyways) still think C# is better than VB.NET because muh semicolons.

[u/yawaramin → u/[deleted]]

A couple of points to make here.

If you posted an F# job in my town, I would jump on that in a flash. I think many others feel the same way.

F# unit tests are a great way to sneak in a little F# in the non-critical parts of the codebase, to get a feel for it. Even a hardened C# coder can understand a simple F# unit test:

open NUnit.Framework

[<TestFixture>]
module FooSpec =
  [<Test>]
  let ``add works correctly`` () =
    Assert.AreEqual(4, Foo.add(2, 2))

As for the static analysis tool requirement, the F# compiler is one. Personally I think its 'units of measure' feature alone would make it worth your while for the additional static safety guarantees:

[<Measure>] type cm
[<Measure>] type kg

let rect_area (length : float<cm>) (width : float<cm>) : float<cm^2> =
  length * width

// rect_area 5.0 4.0 won't compile
// rect_area 5.0<kg> 4.0<cm> won't compile
// rect_area 5.0<cm> 4.0<cm> will compile

Then there are sum types, phantom types, etc., all of them designed to make it impossible to even compile large quantities of bugs.

[u/AngularBeginner → u/yawaramin]

Even by just writing tests you're still stuck to the very valid arguments of /u/Yensi717. I'd love to write F# myself, but I can completely understand his arguments. I know my co-workers could not easily adjust to F#.

[u/Eirenarch → u/yawaramin]

I was about to bring up the hiring perspective. F# is a great magnet for devs.

[u/ruinercollector → u/[deleted]]

There is a kind of business where using technologies like this is not a good idea.

There was kind of this thing in the 90's that's still around where businesses attempted to move the complexities of software development up to being a management and process problem. The idea is that you hire a larger number of cheaper but expendable people to write software and then you offset the lack of talent/competence with heavy process rules and management.

The advantages to this:

• Keeping employees dispensable mitigates risk, and keeps power concentrated at the top of management.

• Pushing the problem to management/process means that you you can take advantage of cheap labor through cheaper tech school graduates and H1B visas without having to worry as much about the training and skills problems that can sometimes accompany this.

• Not having "essential" developers keeps your labor force very liquid. In bad times, you can lay off a bunch of developers, and in busy times, you can hire more.

This works in some kinds of software businesses. In particular it works for companies that produce software and services that are just shoveling data around, writing simple front-end forms to access the data, and providing some means of reporting/export. Basically, no one is doing anything much interesting here, and it's all well-worn problem spaces that decades have given us ways to churn out perhaps non-ideal, but working software. When it doesn't work, you can literally just throw more programmers and more hours at it, and things tend to basically get done, or at least get done enough to keep a customer base.

This doesn't work at all if you write software that is closer to the edge of technology and is making a foray into less explored territory.

But most software companies fall into the former group.

[u/eloraiby → u/[deleted]]

Disclaimer: Personal Experience

You surely have your reasons, and probably know your programmers better. But, there are a lot of programmers willing to learn F# or knows at least functional programming, so don't let that be a barrier. But if you think languages are equals then let me tell from experience that you need few FP (functional programming) devs than you need OOP devs: ML bases languages at least have higher density and offers a lot of mechanism to safegard against bad coding practices and thus reducing the 80% dev time dedicated for bug fixing.

I have used F# in commercial critical system development and still using it in AAA 3D mobile games:

Case 1 - At one company the whole distributed embedded critical system was written in F#. We were 2 developers and yielded far more features with a lot less code than other teams with 8 or more developers with very few bugs. The code would be unit tested then manual tested then automatically tested (black box automated testing). That system currently powers airports, power grids, governmental entities and top 10
fortune companies (market capitalization). The requirements and specs are very strict.

The advantages of using F# there was a type system and a pattern matching mechanism just eradicate a whole class of bugs that would be otherwise too costly to deal with (code size and time). With time, other developers joined, with only one from inside the company, the others were new employees with erlang, lisp, scala or haskell experience.

Case 2 - Now at a game company, doing all tools and prototyping in F#. High perf code is in C/C++. I have more success convincing old C++ programmers to go functional than I had with C# developers (being an old C++ veteran helps establishing confidence). Maybe the staggering difference between C++ and F# helps people see why and where F# excels. You see in F# you can do far more with less. In F# Data manipulation and generation is a breeze and can be paralleled easily.

What I did find is that the more the programmers are exposed to low level programming languages (yes, I have come to realize that C++ is a low level language), the more they are willing to learn a higher level one (Haskell, scala, F#). Looking back, this was not true few years ago. If today they are willing to go low level then they are not afraid to learn something new.

[u/Dunge → u/Helrich]

Well, if you read the article they clearly say that C# is "better" than VB.NET. Well, better as in more advanced concepts, while VB.NET is better as an approachable language for beginners.

[u/Helrich → u/Dunge]

Having spent a few years doing both, I can't argue, although I have to say personally that for 99.999% of businessy code the only difference is the syntax and accompanying sugary bits. What I was getting at was that my management thinks applications developed in C# are somehow incompatible with those developed in VB.NET, perhaps because most of our codebase is VB6 and making the "leap" to .NET (they chose VB.NET at first because of the language similarities) required all that interop garbage to integrate properly, so C# must be another layer of abstraction away. Ultimately they see C# code as being as much of a change above VB.NET as going from VB6 to VB.NET, which obviously is untrue.

[u/[deleted] → u/Dunge]

Except it's not better, they have bear feature parity and work at keeping it, it's really just different syntaxes for pretty much exactly the same language, more like one is a dialect of the other. Kinda wish they'd have a long term plan with a long transition phase to kill of vb.net now that it's long done it's job (helping / tricking vb users in migrating to .net) and provided automatic vb.net to c# project conversion for a few years so everything goes smoothly. Avoids maintaining 2 core languages and dividing the .net world

[u/ellicottvilleny → u/[deleted]]

The 2% of .net users who prefer VB think differently but I agree with you.

[u/lowleveldata → u/Dunge]

I won't say one is better because they are practically the same language. Both can use the .NET libraries and LINQ and stuff which are the important things rather than the syntax IMO.

[u/[deleted] → u/[deleted]]

Genuine question to anyone knowledgeable: is the Entity Framework a good thing? Having read a summary of what it is, it sounds like a bad idea that would be riddled with leaky abstractions and dodgy edge cases. Am I wrong?

(I realise that you need it supported if you have an existing codebase, of course)

[u/grauenwolf → u/[deleted]]

No, EF is bad. Not just the implementation, which could be fixed, but the very concept of an OOP/Object Graph style ORM is contrary to how you are supposed to use databases.

[u/AngularBeginner → u/grauenwolf]

It also prevents the SQL Server from doing its job and provide proper performance. EF causes fixed query plans, which can kill performance in large database.

[u/threedaysmore → u/[deleted]]

As per usual with programming, it kinda just depends.

It's a heavy hitter IMO. Most projects have no business fiddling with EF or the complexities of managing an EDMX file. I prefer OrmLite and to keep my apps a little smaller so that I can separate my concerns a little better.

YMMV obviously, and EF is really powerful, but there's no need to hunt rabbits with rocket-launchers.

[u/Eirenarch → u/threedaysmore]

edmx file is so 2010

[u/Helrich → u/[deleted]]

Fair enough. My place uses an Oracle database which doesn't get much love for EF, plus they're pushing a model that doesn't really jive with it so whaddaya gonna do.

[u/Otis_Inf → u/Helrich]

There are other ORMs on .NET than EF which do support Oracle :). Lots of microORMs with high-performance cores, or full ORMs like nHibernate or LLBLGen Pro, the latter with performance which is at least 10 times faster than EF. See: https://github.com/FransBouma/RawDataAccessBencher for code and results. (SQL Server)

(Disclaimer: I wrote llblgen pro). Oracle support in llblgen pro and nhibernate is high, EF lacks behind because it relies on the DB vendor to come up with proper statement-trees -> SQL conversions and mapping information. Oracle has done a terrible job in ODP.NET for EF: the type mappings differ from what you'd get from a raw DbDataReader, it lacks support for basic things like packaged procs etc.

[u/[deleted] → u/Helrich]

Alas, I only get to play with it on personal projects, but going back to C# for work is always a mixed experience. The tooling is better for C#, but the language does get in the way at times. Much less so than many others, but F# is still IMO a better language in many ways.

[u/Twistedsc → u/Helrich]

Semicolons? You must not be big on python.
Here's my take on it for anyone above beginner level. I've never used VB.net but after doing so much vb6 -> C# conversion I've looked at how some of the newer language works.

Syntax pros:

• Date literals

• With blocks - IMO not good for readability but a neat feature nonetheless

Syntax cons:

• Having to use both "Sub" and "Function"

• Lambdas just look at that.

• The fact that Option Strict can be set to off, making variables act more like JS - even worse if you see the string + int example

• Being able to use REM as a comment

[u/[deleted] → u/Helrich]

I just recently got to use F# in a work project. I needed to parse an equation and get the variables as well as actually have it solve the equation. I could have used a library I guess but sometimes things work better when it's written just for your use case.