"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"?!
He is not talking about software development methodologies, he is talking about the role of people (mostly developers) in the software development process.
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 have always been people who thought about how to make software development better, but there were far fewer of them, both in software and in management. Relative to what we have now, I think it's absolutely fair to say that there was almost no thought about it.
Even ten years ago I was convincing my co-workers and manager that we should be able to run our build without human intervention; today I would not believe you if you told me your team had that problem, let alone that people disagreed it was a problem.
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.
The comment was on the preposterous claim that programmers were treated as "typists" around the year 2000. It's as if dot.com boom has just been collectively erased from all the downvoters' memories.
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.
Yup, it's a bit unfortunate, but that's how it is most of the time.
I found myself using F# for core libraries with clearly defined boundaries between APIs and assemblies - IMO that's where the language shines right now. You can have your core logic contained in a library with a separate, C#-compatible API.
Using F# for WPF, ASP.NET MVC or ASP.NET WebAPI development wasn't quite as stellar experience, also because of the state of the tooling. I'm even wary about type providers, when they work - it's great, when they don't - you're pretty much screwed with no real recourse. In case of relational DB access, most .NET libraries (both full-ORMs and micro-ORMs) are C#-oriented.
Therefore, after including all the annoyances you listed, it's hard to justify anything more than 'handle core libraries in F# with C#-compatible API, do the rest in C# - it's good enough' to the business...
> Go to definition does not work across language barriers, even when the projects are in the same solution
I haven't used F#, but I do have a bunch of visual studio experience. I noticed if you do add reference to a dll (even in the same solution), go to definition doesn't work. But if you instead add a reference to a project, it does. So you might be able to just delete and re add your references and get it to work.
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.
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"?!