Anytime the process boils down to "if it's not a new feature or an emergency bug fix, you are not allowed to spend any time on it. And if you do spend any time on something like fixing spaghetti code so that implementing new features and emergency fixes don't take an act of God, we will refuse to promote it to production, as our policy is to not promote changes to anything that 'already works.'"
This is the kind of attitude that naturally emerges from an environment without unit tests.
And the biggest kiss of death comes from this - the old, "we can't change the database design because we don't know what will break". The growing strain between changing requirements and the DB implementation eventually breaks the project utterly.
You have a problem dude,
I'm not totally wrong though.
Free translation between all languages is just a nice to have compared to the real thrust and purpose of their effort: Human Intermediate Language, and the compilers / reflectors that go with it. It's a hard nut to crack, but this is a natural progression for Google. And applied at Google scale with Google resources... well that could be scary powerful.
I would guess they already have a proof of concept and some execs are shitting themselves over the possibilities. Strong A.I. or something that looks like it is not too far behind. Ask the whole goddamn internet what all of human civilization thinks the meaning of life is, and actually get brilliant results back, with citations, in the language of your choice. This is why they brought Ray on.
Look around the ponderously inefficient, devastated landscape of medium to large-scale engineering. There are no meritocracies.
In no uncertain terms, this will be a pissing contest - let it be known IMMEDIATELY that you are on the warpath and you must get your way. Even if it is completely against your nature... be the asshole. Be the alpha type you may hate. FIGHT AND WIN according to the stupid and predictable primate rules of social structure and power that we all live by - power is taken, not given.
I bet you've never, ever used a unit test in your life.
A whole generation, ruined.
Use exceptions for error conditions that can be generalized, i.e., they need no more information than this for a domain-specific (client/service/DAL) Policy to decide what to do.
1. Is it a genuine error, or a stopping condition encountered in normal operation?
2. Does it contain a message intended for the end-user to see?
3. Should it be logged?
No need for try/catch blocks everywhere for this since you've generalized it.
Error conditions that can't or shouldn't be integrated into a generalized exception-handling policy... these should relay information through function return values as part of an application's business process, not through exceptions.
It's not complicated.
If more people dislike the law than like the law, the law will change.
No, it doesn't work like that. Not here.
This is also quite distinct from the event horizo
For an instant, before I saw "Read the rest of this comment...", I thought, OMG, the post got sucked in!
The numerical simulation scenario could reveal itself in the distributions of the highest energy cosmic rays exhibiting a degree of rotational symmetry breaking that reflects the structure of the underlying lattice.
This sounds similar to looking for aliasing artifacts. Right?
Among the observables that are considered are the muon g-2 and the current differences between determinations of alpha, but the most stringent bound on the inverse lattice spacing of the universe, b^(-1) >~ 10^(11) GeV, is derived from the high-energy cut off of the cosmic ray spectrum.
This is do not understand, I thought we already had a theory predicting and explaining a high-energy cutoff.
Never mixed Pink Floyd with Tolkien before. I usually don't get really creative, screwed up images like that unless I'm dreaming. Thanks, Slashdot!