Forgot your password?
typodupeerror

Comment: Re:Philosophical Question (Score 1) 1486

by Espressor (#35752856) Attached to: Is Science Just a Matter of Faith?

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.

Comment: Re:Understanding should increase astonishment (Score 1) 1486

by Espressor (#35752632) Attached to: Is Science Just a Matter of Faith?
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.

Comment: Re:Science does require faith (Score 1) 1486

by Espressor (#35752416) Attached to: Is Science Just a Matter of Faith?
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.

Comment: Re:Realities and Incentives (Score 1) 732

by Espressor (#35634128) Attached to: Friends Don't Let Geek Friends Work In Finance
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).

Comment: Re:Another one? (Score 1) 134

by Espressor (#35183064) Attached to: Google Brings Design-By-Contract To Java
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:

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.

Comment: Re:DEC did a good one (Score 1) 134

by Espressor (#35183002) Attached to: Google Brings Design-By-Contract To Java

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.

Comment: Re:The problem with C++ (Score 1) 553

by Espressor (#33904052) Attached to: Bjarne Stroustrup Reflects On 25 Years of C++
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.

"No problem is so formidable that you can't walk away from it." -- C. Schulz

Working...