No, I define "abusing" as doing things like overloading an addition operator which doesn't perform an additive operation. (Which would be just as abusive if you used a non-operator function with a misleading name).
Can you provide an example which is non-abusive, but is a source of bugs? Or are we just expected to accept the veracity of your unsubstantiated claim that "today it is considered mostly a source of bugs"?
Me, amongst others. I'm a member of a National Body delegation to an ISO committee.
given the cost of entry is often in the 6 to 7 digits (the lower one is just to use the standard, if you want to participate in making them, it's $$$$ and always has been)
This is flat out wrong; neither I not my employer pay even a single cent to participate in making ISO standards.
I don't actually know off the top of my head how many collisions you should expect if you hashed N items.
One of the characteristics of a good cryptographic hash is that it has a uniform distribution in the hash space - so really, you have a generalisation of the birthday paradox; the section there on 'Collision Counting' gives the expected number of collisions as n - d + d ( ( d -1 ) / d ) ^ n (where d is the number of possible hash values, and n is the number of items).
Since we're hashing N items, with N outcomes, then we can substitute d==N, n==N N - N + N ( ( N - 1 ) / N ) ^ N and simplify a little: N ( ( N - 1 ) / N ) ^ N
My calculus is embarrassingly rusty, so I did a quick graph of that (and its differential) on Wolfram Alpha, and it looks to be tending to around 36.7% collisions, which I thought was surprisingly high - but then again, the birthday paradox still strikes me as a surprising result...
No puppetry, but a considerable amount of model work (for vehicles, moonbase, etc). Naturally, Anderson's team had a considerable amount of experience in that field from the earlier marionette series - as a result of which, UFO stands up extremely well to other shows of a similar age.
I'm guessing, but I'd imagine a sizeable chunk of that budget was to get Martin Landau and Barbara Bain on board (which was, as I recall, deemed necessary for the lucrative US market).
For me personally, neither of them added much to the show (despite the fact that both are fine actors - Landau especially so); I think the whole thing would have worked better as an ensemble cast without the two "big names".
They can't because there might be a single copyrighted file in there, and that would make it IP piracy!
Actually, there's already a massive amount of copyrighted material on there (most material is implicitly copyright in most jurisdictions UNLESS the authour takes specific steps to ensure otherwise).
Printing it wouldn't make it any more pirated than simply archiving it.
Firstly, most source code management systems (quite rightly) consider whitespace to be significant, so if Bob messes around with Alice's whitespace, then as far as the SCM is concerned, it's a change (regardless of whether there's a semantic change or not). So futzing around with whitespace can lead to the appearance of considerable code churn - despite the fact that it's actually just noise.
Secondly, ignoring whitespace in a diff can lead to false negatives - since whitespace *can* have a semantic impact.
I can't say enough about peer review. I wish I had more
This, this and this again. Only more so.
one thing that geeks LOVE to do, is cut down other geeks
Folks who are doing that in a code review have completely the wrong approach, and should be battered around the head with a clue stick. I've found that the best way to deal with them is to point out that this shouldn't be seen as an opportunity to cut others down, but as an opportunity to show off by educating the reviewee (and, of course, showing off is the other thing that geeks love to do;-)
Negative feedback makes the product better. Positive feedback makes the producer feel better.
That depends on the actual feedback. Negative feedback like "man, this sucks" hurts the project team's morale and thus, long term, the product. Negative feedback like "you can improve this by doing X here, which is better because Y" is actually very positive - it directly improves the product, improves the team's skill set, and improves communication within the team - win, win, win.
This is one of the things I really like pair programming - instant, on-the-fly, cod review. And it doesn't much matter if your partner has a zillion times your experience, or is just writing their first program; both halves of the pair benefit from the process. I have my team spend about 50% of their actual coding time pairing, and rotate the pairs each session. Some folks seem to have the concept of man-hours too deeply ingrained in their psyche to understand how this can be as productive as everyone flying solo, but in my experience, pairing tends to be *more* productive.
I've been programming in C for over 30 years, and honestly can't remember how long it's been since I used a compiler that wouldn't warn me about something like if( i = 1 ). Mind you, in my early days (when compilers were more concerned about code generation than correctness), I used to push everything through lint every so often - which would have generated a similar warning.
All that being said, to this day I still favour if( 1 == x ), despite the raised eyebrows it gets from the younger crowd.
If every value read from memory had to be sanity checked there would be little CPU horsepower left to perform useful work
That's why ECC memory exists - the 'sanity check' is a real-time hardware operation that (typically) generates an NMI when it fails. It's not common in consumer-grade PCs (due to cost), but it does get used in some critical applications.
That we're seeing so many near misses is mostly indicative of the improvements in our technology. The better our sky watching gets, the more we'll see - it's not that there will actually be more near misses - it's just that we're getting better at spotting them.
Slashdot Mirror
No, I define "abusing" as doing things like overloading an addition operator which doesn't perform an additive operation.
(Which would be just as abusive if you used a non-operator function with a misleading name).
Can you provide an example which is non-abusive, but is a source of bugs? Or are we just expected to accept the veracity of your unsubstantiated claim that "today it is considered mostly a source of bugs"?
I know this is crazy talk — especially for /.
Couldn't agree more - since most folks can't even be bothered to RTFA, do you *really* expect them to wait to WTFE?
Boris the Program Monitor (USSR space race surplus):
In Soviet Russia, Program Monitors Boris!
(sorry - that was just too good a fed line...)
Remember who populates these standards bodies
Me, amongst others. I'm a member of a National Body delegation to an ISO committee.
given the cost of entry is often in the 6 to 7 digits (the lower one is just to use the standard, if you want to participate in making them, it's $$$$ and always has been)
This is flat out wrong; neither I not my employer pay even a single cent to participate in making ISO standards.
today it is considered mostly a source of bugs
[Citation Needed]
Having the facility to overload operators isn't a source of bigs; abusing that facility is a source of bugs.
I don't actually know off the top of my head how many collisions you should expect if you hashed N items.
One of the characteristics of a good cryptographic hash is that it has a uniform distribution in the hash space - so really, you have a generalisation of the birthday paradox; the section there on 'Collision Counting' gives the expected number of collisions as
n - d + d ( ( d -1 ) / d ) ^ n
(where d is the number of possible hash values, and n is the number of items).
Since we're hashing N items, with N outcomes, then we can substitute d==N, n==N
N - N + N ( ( N - 1 ) / N ) ^ N
and simplify a little:
N ( ( N - 1 ) / N ) ^ N
My calculus is embarrassingly rusty, so I did a quick graph of that (and its differential) on Wolfram Alpha, and it looks to be tending to around 36.7% collisions, which I thought was surprisingly high - but then again, the birthday paradox still strikes me as a surprising result...
whether or not you celebrate Christmas, Christmas celebrates you.
But only in Soviet Russia
Take a look at this
There wasn't puppets in UFO, was there?
No puppetry, but a considerable amount of model work (for vehicles, moonbase, etc). Naturally, Anderson's team had a considerable amount of experience in that field from the earlier marionette series - as a result of which, UFO stands up extremely well to other shows of a similar age.
..and Lady Penelope (voiced by Sylvia) was my puppet fantasy woman when I was 12
Trivia: Not only did Syliva voice Lady P, she also provided her ankles for the occasional live-action close up.
Come to think of it, she still is
*nods* :)
The acting in Stingray was way less wooden than that in Farscrape...
I'm guessing, but I'd imagine a sizeable chunk of that budget was to get Martin Landau and Barbara Bain on board (which was, as I recall, deemed necessary for the lucrative US market).
For me personally, neither of them added much to the show (despite the fact that both are fine actors - Landau especially so); I think the whole thing would have worked better as an ensemble cast without the two "big names".
They can't because there might be a single copyrighted file in there, and that would make it IP piracy!
Actually, there's already a massive amount of copyrighted material on there (most material is implicitly copyright in most jurisdictions UNLESS the authour takes specific steps to ensure otherwise).
Printing it wouldn't make it any more pirated than simply archiving it.
+1 - where are my mod points when I need 'em.
PHP developers
Awooga! Oxymoron alert.
Most diffs can ignore whitespace.
This is true - but it's not really a solution.
Firstly, most source code management systems (quite rightly) consider whitespace to be significant, so if Bob messes around with Alice's whitespace, then as far as the SCM is concerned, it's a change (regardless of whether there's a semantic change or not). So futzing around with whitespace can lead to the appearance of considerable code churn - despite the fact that it's actually just noise.
Secondly, ignoring whitespace in a diff can lead to false negatives - since whitespace *can* have a semantic impact.
CodingStandardsThatMandateCamelCaseDecreaseReadability.
coding_standards_that_mandate_underscores_increase_readability.
No, but a delivery address can be helpful.
If you're a creationist, then you ARE the margin of error.
I can't say enough about peer review. I wish I had more
This, this and this again. Only more so.
one thing that geeks LOVE to do, is cut down other geeks
Folks who are doing that in a code review have completely the wrong approach, and should be battered around the head with a clue stick. ;-)
I've found that the best way to deal with them is to point out that this shouldn't be seen as an opportunity to cut others down, but as an opportunity to show off by educating the reviewee (and, of course, showing off is the other thing that geeks love to do
Negative feedback makes the product better. Positive feedback makes the producer feel better.
That depends on the actual feedback. Negative feedback like "man, this sucks" hurts the project team's morale and thus, long term, the product. Negative feedback like "you can improve this by doing X here, which is better because Y" is actually very positive - it directly improves the product, improves the team's skill set, and improves communication within the team - win, win, win.
This is one of the things I really like pair programming - instant, on-the-fly, cod review. And it doesn't much matter if your partner has a zillion times your experience, or is just writing their first program; both halves of the pair benefit from the process. I have my team spend about 50% of their actual coding time pairing, and rotate the pairs each session. Some folks seem to have the concept of man-hours too deeply ingrained in their psyche to understand how this can be as productive as everyone flying solo, but in my experience, pairing tends to be *more* productive.
I've been programming in C for over 30 years, and honestly can't remember how long it's been since I used a compiler that wouldn't warn me about something like if( i = 1 ). Mind you, in my early days (when compilers were more concerned about code generation than correctness), I used to push everything through lint every so often - which would have generated a similar warning.
All that being said, to this day I still favour if( 1 == x ), despite the raised eyebrows it gets from the younger crowd.
If every value read from memory had to be sanity checked there would be little CPU horsepower left to perform useful work
That's why ECC memory exists - the 'sanity check' is a real-time hardware operation that (typically) generates an NMI when it fails. It's not common in consumer-grade PCs (due to cost), but it does get used in some critical applications.
Yes that has happened in the past with trains, trucks, airplanes , ect's.
12+ hours of ECT is just asking for trouble...
Only 8%? I'd have thought it was far more than that...
bad news that we're seeing so many near misses.
That we're seeing so many near misses is mostly indicative of the improvements in our technology. The better our sky watching gets, the more we'll see - it's not that there will actually be more near misses - it's just that we're getting better at spotting them.