hravnx

They might seem archaic (and even wrong) when we look at them today, but still: smart people put a lot of thought into the methods, they were hotly debated among professionals, books were written, and consultants made money teaching and preaching them.

In other words, not that different from today.

Really, Joel? So all the various software methodologies of the seventies and eighties, all the CASE tools of the nineties, Extreme Programming etc etc etc - all of this does somehow not count as "thought on how software should be developed"?!

The demos that Tomas Petricek and others in the community do are nice, but in real-world applications of even moderate complexity you almost invariably run into impedance mismatches and annoyances.

I'm currently working on a F# backend for a service with a WebAPI 2 front-end.

- We had to create a C# glue project to be able to publish it as a web app on Azure. This works, but dependency tracking across language barriers in .Net is flaky, so we have to remember to add all Nuget packages to the glue project manually, or we get run time errors in production (not during compilation or locally in test, but in production) as the assemblies are not published.

- Go to definition does not work across language barriers, even when the projects are in the same solution. So you're in F# code, place the cursor on a data tyope defined in a c# file and press F12 to navigate to the source and you get an F# view of the data structure, instead of going to the source.

- The async models are famously different between F# and C#, so you have to marshall back and forth between them, resulting in a lot of `|> Async.StartAsTask` and `Async.AwaitTask` in the F# code, and don't get me started on how to convert an f# async computation to a .Net Task in C#. Pretty, it aint.

- While you can easily create WepAPI controllers in F#, there are basic things that you just can not do. One that bit me recently: having optional query string parameters. Super easy in C#, impossible in F#. Ended up writing a C# controller just for the endpoints that require this, so now I have controllers in the same API surface written in two languages.

Neither of these things are the end of the world, but they do add up, so for me personally it is not a given that I will use F# for my next project.

The myth that Eclipse users try to perpetuate that "you must buy Resharper just to be able to work in VS" is just that: a myth.

My team has worked on both C# and Java backends for AAA-games and after we moved to C# we have had people actively threatening to resign if we ever went back to Eclipse (and Java). The debugging capabilities, the speed of the tools, the relative sanity of C# compared to Java ... there is simply no comparison.