@ScanIAm: Not being an advocate for database lookups, infinite loops and formatting C:\ in property code myself, I quite agree with you. However I see the broader issue as transparency in code.
The term "honest" has been used to describe code that signals its own effects, whether formally through types or informally through names or perhaps even comments (and "dishonest" vice versa). I prefer the term transparent because it's more neutral.
Haskell has the IO monad to make certain effects transparent. Java has checked exceptions to make exceptions transparent. C# has async methods to make time-consuming mehods transparent and asynchronous. In a double-whammy there's also a naming pattern associated with the use of async.
These constructs make it (painfully or blissfully) obvious to the consumer what the effects of calling a piece of code are. The IDE also has a role to play here, by making effects more clear to the developer. But by formalising effects, perhaps we can better manage code evolution by seeing types change as effects change - and indeed requiring types to change so that code built on the assuption of no effects - or only some particular effects, has to be revisited when the code it depends on changes effectfulness.
I'm hoping to see some interesting developments in this area in M# - or whatever the research variant of C# that MSR is working on is called. Well, just dreaming here - keen to gain some experience with such a language and how productive it will be.