2) Science does work within the "dream". See 1)
Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
If my senses actually reflect some underlying reality then the scientific method will help me learn something about that reality. However if my senses do not reflect an underlying reality then the scientific method is useless.
p. p. I disagree. In either case, science helps you understand and make use of what your senses tell you. It's useful in its applications in either case, whether what you perceive is "real" or not. Even in the latter case, 1) you will never know that your senses are lying to you anyway, so it makes no difference and 2) science as a method of knowledge will remain consistent with itself within that illusion. It will be useful.
I think grandparent alluded to people taking for granted the technological miracles that are their iPhone, their TV, etc. In that sense people are jaded, but I agree with you: it's because they do not grasp the beautiful, incredible complexity of those systems, and the decades, centuries of brilliant scientific and engineering work that made them possible.
On a side note, I don't think philosophers would agree with your claim that their realm is that of the Truth.
Is this framework related to 'ModernJass' from Sourceforge.net?
Yes, Cofoja is a significant rewrite of ModernJass. We worked closely with the original author of ModernJass (Johannes Rieken) on this.
OK...then why not contributing to the OSS project instead of phagocyting it and re-branding it into another Google product? I guess I'm answering my own question here...
Has anyone found more details? For instance, Modern Jass does not support JML. Is Google going to support it? If not, why didn't they create their own work to implement it?
I'm just saying, until proof to the contrary, this really feels like Google is trying to make geeks' headlines while bringing nothing new or groundbreaking to the table.
The hacks that try to do design by contract at run time tend to avoid expressions which examine big data structures, since they have to run them over the whole data structure every time. Real verifiers prove or disprove such things at compile time. It turns out, though, that a few standard cases for collections cover many of the usual things you want to say.
Very good point, and the irony is that the Google blog uses collections in one of their examples.
The Google project is based on a library called Modern Jass. I'm not familiar with it since the last time I did research on DbC was in 1999/2000 when the only DbC tool for Java that existed might have been Reto Kramer's iContract. Yet, to call it a hack...is it purely because of this absence of static analysis you mention? BTW what kind of static analysis is implemented in Eiffel?
As for concurrency, I agree this would need to be addressed as well. There was an interesting article about a decade ago in JavaWorld about how preconditions would sometimes need to be turned into guard conditions. Anyway, I don't know if any of the many DbC tools for Java address this, but after so long I would hope at least one does.
I love one of the appreciative comments:
I hope you get 1000 blowjobs this year