If you think the software methodologies of Olden Times did not consider the role of people in the software development process you are mistaken.
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.
"There was almost no thought around how software should be developed."
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"?!
It's fairly sad that the "script for the future" is (partly) being written by people who consider a mere 665 words a "wall of text" that is OK to comment on, but apparently too long to read.
I really, really like the F# language, but the tooling is so bad (compared to C#) that it's a real struggle to continue to justify using it. I admire the effort put in to F# Power Tools development (I've been using it for a long time and is currently on 2.0), but TBH it's like a slow, buggy implementation of a quarter of the C# tooling. Don't get me wrong, the effort is commendable and I know you're not supposed to criticize OS projects unless you're involved yourself, but from a practical day-to-day point of view, it's not working well.
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.
Out-of-the-box VS 2013 (and C# development) is so far ahead of Eclipse (and Java development) that it isn't even the same sport.
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.
PowerShell is awesome. A shell with proper intellisense, a real object pipeline, string interpolation and cool meta-programming facilities - to mention just a few areas where it runs rings around bash.
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.