1) Let's assume we're dreaming. Are you saying science is not useful now?

2) Science does work within the "dream". See 1)

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.

Agreed. But no need to go to human engineering to experience such amazement. Scientific study of nature is enough. Case in point: I had the same reaction as you after reading The Selfish Gene.

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.

I really don't think you can say that Newton's mechanics are "wrong", they are simply not precise enough a model in certain use cases. See http://en.wikipedia.org/wiki/Newton's_laws_of_motion#Importance_and_range_of_validity

On a side note, I don't think philosophers would agree with your claim that their realm is that of the Truth.

Wow. You don't use their product and the onus is on YOU to prove you don't? This is so morally disgusting, I'm going to get sick.

By 3) you mean abandon engineering and work on the business side of finance i.e. a trader, correct? Because AFAIK for the majority of software engineers working in banks, the situation is more akin to 2) i.e. work for a big corporation (granted, with better perks than most other industries, but not insane wages).

When you move to Europe you'll be able to use Spotify. You'll very much enjoy being in Europe.

Thanks so much for this...A trip down memory lane with my Amiga...

Still, what's new here? What value has Google added to that existing OSS project - other than marketing power and visibility? Looking at the Google project's FAQ:

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.

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.

Very good point. It's been like that in the financial world for a while where some business people manage to make their bonus guaranteed at a minimum amount. It just becomes inflated salary. Source: Cityboy: Beer and Loathing in the Square Mile .

BRILLIANT! Mod parent up please!

I love one of the appreciative comments:

I hope you get 1000 blowjobs this year ;-)

You're referring to the "static initialization fiasco" and other joys? Yes, a bit of a shame for C++ really.

Real men code in Assembler.

1) is more labor-intensive (programmers are lazy) than 2) (it's risky to catch an exception and not let it fly unless you know exactly what you must do to recover correctly). So, in practice, 1) will generate more bugs. Not because it a worse engineering practice, but simply because it's more error-prone.