Guilt-by-association - kind of the same that happens with browsers and bad plugins or operating systems and bad drivers. One hopes that these kinds of crashes are quickly reported via telemetry to the guilty party.
@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.
Will you be downgraded to 25/50GB after that year?
I'm not a big fan of properties having code within them, but I do understand that there are cases where it's necessary. I just don't know that adding notifications is one of those cases. If we are willing to accept some syntactic semi-sweetener to fix this, why not do it with a decorator that would imply that getting or setting the value should kick off an event?
Isn't the entire reason for the existence of the property construct to abstract over whether the accessed data is aquired via lookup or computation? Insofar as that is the case, you appear to dislike properties on the basis of their primary purpose - or? (Putting things on an edge here)
It's generally interesting to see - and control - the possible effects of calling a piece of code - but due to the abstraction afforded by methods and properties, that can be difficult without some form of static analysis. Such analysis could reveal potential effects of code - and a prescriptive mechanism could generate static errors before code is ever run. Future IDE's and languages should provide developers with much more insight and control.
What does this solve that a tool co-operating with the compiler in the IDE that notices 'bad patterns' during editing wouldn't?
Unrelated rant: I find properties are sometimes a pain when debugging as you hover over things hoping to get idea what the state is, then find you need to execute code and it can't execute the code right here since it's some complicated code. It's a bit "hey, I'm just a property, come see what value I am - then it 'laughs' at you for being so silly as to expect you could actually do that". It's obvious from a method that you need to execute it to get a value, with properties it's pretty much what C# tries to avoid - getting error at runtime - except here the runtime error is that no, you can't view the property right now, and the editor doesn't highlight this fact in any manner so you hover over it in *hopes* of getting something without needing to execute what could have side effects in 3rd party code that end up affecting the state of your code etc.
So that was a summary why I don't use properties much, and avoid things that make debugging harder. I chose C# as my preferred language because debugging it is easier. And that's key since most of the code in most projects I do will be stuff I didn't write and while I only use high quality 3rd party code, when bug does happen in 3rd party code, I like for it to be easy to debug and fix.
I agree with your sentiment but what would foo.P() vs foo.P gain in terms of debuggability? If P is an abstract (computed) property, then some code needs to execute whether it is syntactically expressed as a method or a getter. Maybe it's not sufficiently visibly expressed in the debugger UI that it is a property, if at all?
In general of course one is interested in knowing (and restricting) the effects of calling some code - can/does it write to disk, use the network. take a long time to execute, throw exceptions, spawn a thread, etc.
@Charles: You're welcome. I'm amazed at the quite sophisticated defense procedures these terminates have.
@Richard.Hein: Perhaps not. I think it's intriguing to connect concept of Fungi mycelia network to the Gaia hypothesis, playing a role in self-regulating ecosystems. All the applications of Fungi are also interesting.
I've seen that video and would not consider giving facebook any money for any promotion after that. Of course this guy is a Google employee but... veritas offendi.
I remember being a big user on a "semantic" social network that is now defunct. Before it shut down (and making all user content inaccessible - with no backup mechanism in place a la Google Takeout) it was completely overrun by 3rd-world human spam farm activity, fake profiles and spam content - to the extent that its Google PageRank suffered quite a bit from it.
I wouldn't call this facebook ad-click-case fraud however. I don't know of any law prohibiting a person from clicking an advertisement without intent to buy (whether with money or time). Annoying-as-hell, yes, but... I don't know how it's even possible to protect against unwanted ad-clicks.
That would mean Bass had to build a time-machine, then travel back in time to when Ximian was still a company and work for them in his new alternate time-line.
Equally shocking as it would also imply the invention of the time machine.
Seriously though, what does Google have to gain from buying Xamarin? They already have a thriving and winning ecosystem.