Firstly, no, people still do. Not everyone, but people do.
But even if nobody did, that doesn't change anything. The article isn't about the dangers of printf, it's about the dangers of side effects: printf is just an example. A printf inside an otherwise pure function is not the only possible example of a side effect.
> And if you're using LINQ, it's because you know you want deferred execution and that's explicitly what you're hoping for. Developers who don't know this feature/limitation of LINQ just plain don't know about LINQ.
So? You can still make mistakes here and your compiler won't catch them.
In pure functional coding the lack of side-effect guarantees safety during parallelism at the cost imperativity(code readability for those who have only ever written imperative code.).
In purely imperative code you get a guaranteed order of execution at the cost of simple parallelism because you are managing shared state.
With both you get to juggle the order of execution and shared state with none of the guarantees!
It can be done and I have seen it done successfully, but I would argue it is not a good starting point for a project or a language design.
According to TFA, apparently nothing that "works".
If you're working in C#, you're most likely working in Visual Studio (Mono is just such a terrifically small proportion of C# users, and even then, some Mono users are using Visual Studio), so you have access to one of the best (and easiest to use!) debuggers in the world. This isn't embedded C++. It is common for .NET developers to know how to use the debugger. People don't use printf-style debugging, and even if they thought they would want to, there is no easy way for such an undertrained developer to do it. You have to make a special build to get the "console" window, and it's a setting most developers I've encountered just plain don't even know exists.
And if you're using LINQ, it's because you know you want deferred execution and that's explicitly what you're hoping for. Developers who don't know this feature/limitation of LINQ just plain don't know about LINQ.
So after all these C# strawmen, his proposed solution is... rewrite your entire world in Haskell. Yeah, that's totally going to happen. I'm going to get my stakeholders on board for that, I'm going to have all of the libraries I've come to love available to me, or reasonable analogues (Just looked at HDBC, it looks like a toy compared to ADO.NET). We're just going to switch to Haskell and everything is going to be peaches and cream.