Re:“Mostly functional” programming does not work (2014)
by moron4hire on Monday June 22, 2015 @09:09AM
(#9758005)
But what he's showing is "not even close to functional", not "mostly functional".
Re:“Mostly functional” programming does not work (2014)
by TazeTSchnitzel on Monday June 22, 2015 @09:11AM
(#9758018)
How so? LINQ is functional.
Re:“Mostly functional” programming does not work (2014)
by sqeaky on Monday June 22, 2015 @12:00PM
(#9759212)
I think that the author's point was that C# was imperative and linq is functional. But the merge of the two does not give you best of both worlds, but rather to worst of both.
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.
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.