If you're going to go for a truly Worst Case, you have to consider what would happen if the falling elevator suddenly spontaneously converted into antimatter. The resulting explosion when it hit bottom would be enough to devastate the surrounding city in an (admittedly spectacular) flash of high-energy radiation.
if a function is small enough that they do one logical operation, then wouldn't it just be easier to read the code to figure out what's going on than read some developer's comments?
Ah, you've got mixed up about abstraction levels; one developer's single logical operation is another dev's complex function or even a whole code module. For example, suppose you have a function DrawShadedBox. It's a single logical operation (the drawing of a shaded box of course!) but when you look inside it, it's made up of many smaller operations for things like color management, manipulating the mapping from abstract space to viewing space, shoving pixels on the screen, etc. and the way some of those operations compose might well be non-obvious. A comment explaining those tricky bits would save loads of maintenance heartache, and the advantage of a comment is that it is in the right spot; someone looking to maintain the code will see the comment, whereas they might not bother to read some PDF somewhere in the wild. The situation is often worse with internal documentation; sometimes you end up with developers who produce docs, but only in printed form (they keep the electronic form on their machine behind an agressive firewall) and you have to hope that someone can find a copy in a filing cabinet somewhere in order to be able to read it.
I imagine at this point some smartarse is going to point out that some methodology-of-the-month ensures that comments are never necessary because they break down every function/method into named sub-functions and everything's self-documenting through appropriate long names. My experience that such systems have real problems as they get larger because you end up with enormous numbers of tiny named functions splattered all over and to get anything done you have to memorize loads of the things. It's like you've gone from a graph where the interesting things are the nodes to a graph where the interesting things are the links, and there's many orders of magnitude more links than nodes. My working memory just isn't good enough to hold all that stuff in my head at once! To cut a long story short, as in all programming tasks, there is a balance to be struck between keeping individual components small (and so comprehensible in themselves) and keeping the overall system comprehensible. What marks a really good programmer is that they get that balance right just about all the time. And (to get back on topic!) comments help a lot by making it easier to fully comprehend more complex components, freeing up more brain-cells for the bigger picture.
Trust me a four year old end of line comment that reads "SRQ 5678" is not helpful to anyone.
It's useful, but only if you've still got the bug/issue database too. Not that having such a DB means you can get away with not having a revision control system and policy in place. Instead, you should use every tool available to try to keep track of what happened, and if putting a comment in means that you can come back to the code later and get back up to speed faster, that's an unmitigated Good Thing. Which isn't to say that the comments should be trusted implicitly, but well-commented code is so much better than uncommented or poorly-commented code since it helps you understand what other people have thought about this bit of code in the past.
By the way, I have seen some neat systems which offer integration of issue database and revision control; they're very neat and if you've got access to such a thing, use it! (I'd offer a link, but I can't quite remember the name of it...)
// Bump the refcount to stop premature deallocation during the recursive call
An example of an enormously useful comment:
/* Bump the refcount to stop premature deallocation during the recursive call. [Bug 122345]. * Watch out here, the fooble compiler V7 has a tendency to reorder instructions wrongly * so the obvious optimization results in a bizarre crash in production. [Bug 179981]. * This is a candidate for improvement when we finally switch to V8 */
"What" should be obvious from the code. "How" sometimes needs commenting. "Why" is the important one though. Even if the "why" is out of date, at least it records what someone intended at some point and that gives you at least a chance to maintain the code instead of having to relearn all the subtleties from scratch each time. And the "gotchas" should always be commented; documenting them elsewhere is good too, but putting them in the code makes sure that Joe "In a Hurry" Maintenance Coder (or yourself) three years down the line doesn't have to relearn all the subtleties you've just sweated blood to discover.
I use a laptop at work and I find it is better for my hands and wrists because it puts a mousepad in a place where I can use it without removing my fingers from the home row. By contrast, a real mouse is much less comfortable to use (leastways that's what I found). I think the whole trick lies in the angle of the wrists.
If you can, get someone who knows about desk ergonomics to assess your working environment and follow their recommendations. Your body is more important to you than your slobby bad seating habits. Similarly with your eyesight; a good opthalmologist might not be cheap, but it's not a thing to skimp on.
then there's the eternal caveat about the design document:
- no one will read it.
Sure, but if you don't have a design document then it will be something else far more nebulous that everyone fails to read. By having a design document, whenever there's a possibility that there's going to be a conflict between coders, one of them (or both) will check the relevant bit of the document and figure out "Oh, I'm wrong. Shucks." and stop getting worried about their ego so much.
Design documents are a bit like mission statements: a standing joke that is better than the alternative.
It seems that IE seems to always do magic checking; renaming a PNG image to.html left it still renderable as an image. Ick!
By contrast, Firefox (on Win) won't interpret anything that is claimed to be of text/* MIME type as any of the image/* types, but will do magic guessing to get the type of image if the server supplies the wrong content-type. Which is not to say that FF is vulnerable in the first place; that depends on whether it displays WMF-format images at all.
Not as good as the call site, but still better than in C where you can only tell from the method implementation (or documentation) that a parameter isn't changed.
That's not actually true; you're just talking about C code where the author has left out some of the 'const's they could have used. (Of course, given that both C and C++ can cast things away anyway, you're still actually stuck with the source/docs for the information. Neither language promises that no non-type-safe casts can occur.)
When you say "typesafe" do you mean with respect to run-time type-safety or compile-time type-safety? Hmm, you're talking about C++, so I guess it's "compile-time"; to code in C++ is to reject the concept of managed code and strict enforcement of basic language guarantees. Which means that if there are any bugs in the compilation, you're in trouble. Note that that's true for many other systems too; it's not a specific dig at C++.
Of course, type-safety is a much lesser concept than program correctness. All it does is catch a larger subset of lower-level problems (FWIW, there's an infinite number of possible layers of abstraction and nothing as simple as a type system can tackle them all tractably) and occasionally get horribly in your way when you're coding something. But all too often people don't want to pay for correctness; they assume (usually correctly) that they can get "good enough" for less cost.
A little examination of WinXP SP2 indicates that that's not the case; MS have at least reversed that daft decision. (Otherwise I'd agree with the gist of what you are saying.)
The unnamed senior tearfully admitted to the hoax after UMD history professor Brian Glyn Williams confronted him with inconsistencies in his story at his parents' home...
The confrontation was at the home of Professor Brian Glyn Williams?
Do scientists need to say a prayer before measuring how many millilitres is in the graduated cylinder- "Oh dead God, give me the wisdom to tell where the meniscus rests"?
Just for your information, most people normally say "Oh dear God,..."
Well, unless they happen to be worshippers of Osiris or Cthulhu or something else unusual. If that's a description of you, I sincerely apologize.
The real weak-point in this system is the manufacturer's private key. If that leaks (want to bet that that won't happen?) the only way the TCG's got of dealing with it is to revoke that key, which will render every machine bought from the manufacturer useless. If that's a few million devices, consumers are going to go completely apeshit, and the politicians will go along with it because siding with consumers (i.e. voters) always makes a congresscritter look good.
The only way to deal with this is for the manufacturer to make utterly sure that that key never leaks. (The TCG's master key is like this in spades; a theft of that would ruin the whole system.)
How can you know whether the code is clean, if it's closed source?
In theory, you can't, but in practice, you don't really need to see a crock of shit to be able to smell that it is there. If things are bad underneath, bits of it leak through (large numbers of visible bugs, unresponsive developers, rumours about people quitting, etc.) Learn to read between the lines...
You would probably have to reboot the servers every night at midnight to keep those things up and running with that kind of volume.
Wouldn't work, or at least not unless you could have a programme of rolling reboots throughout the whole day. Basically, ebay (as a global operation these days) doesn't have much in the way of quiet periods; when the US sleeps, first the Far East and then Europe are busy instead. Makes you wonder what the MTBF on their server hardware is...
Re:Emacs vs Eclipse: A losing battle
on
The Future of Emacs
·
· Score: 2, Funny
I don't see any line item bugs for "Make Emacs like Eclipse". There should be. Eclipse kills emacs.
I'm sorry, but I don't think even emacs could be bloated up as much as a bog-standard eclipse run, let alone one with plenty of plugins installed. Maybe eclipse kills emacs, but that's only through making the machine run out of swap space...
Why the hell is Swing only starting to work at the level that an app like Eclipse does, when QT widgets have worked smoothly and quickly?
Because Swing (and AWT and SWT) are slow and sucky. I like Java for server-side apps (there are some really nice libraries there) but Java GUIs all gobble memory for no good reason. The reason they're appearing to not suck so much now has got to be that you're only now getting enough memory that you machine doesn't start paging like fury when you do anything with a Java GUI...
What about relligions that discard the concept of god? Or use multiple gods?
The atheistic religions would need to fight it out over thereisno.god and the polytheistic religions would need to get busy grabbing domains (thor.god, zeus.god, seth.god, hmm might be some time there...)
Your main problem though is going to be the people offended that there isn't a.goddess TLD; someone's bound to think that's important and kick up a fuss.
It's better to laugh at such a bad situation than to cry. There's too much crying in the world already, and laughter will help to put the fools behind such asinine censorship in their place.
The real value is that you only have to make one call to malloc() or new. That's valuable in places where saving cycles counts but you still have to use variable-sized structures. The only alternatives are either doing malloc()s, or allocating on the stack. Stack allocation is all very well if you're writing a small single-threaded program that runs on a desktop system, but it sucks in big complex programs (where memory allocation and usage patterns tend to get non-trivial) threaded apps (you usually try to use a smaller stack in threads if you can, since stack space is essentially largely unshared between threads) and embedded contexts (where you tend to have a miniscule stack!)
Sometimes predictable object destruction IS necessary.
For what? The reason why GC can get away without it is that you can have many tens or hundreds of millions of objects with modern physical memory sizes. By contrast, even if I recompile the kernel I'm not going to be able to sensibly handle even close to that many file descriptors.
Scoped objects? They never really seemed all that useful to me, but maybe it's a peculiarity of the code I usually write that most significant resources allocated do not have lifetimes linkable to any scope. But that's probably a peculiarity of the code I'm usually working with.
On the other hand, GC doesn't work too well with it either (because GC across a distributed object system sucks unless your network is perfect). Time-linked lifetimes (which you can update, of course) seem to work better.
Slashdot Mirror
If you're going to go for a truly Worst Case, you have to consider what would happen if the falling elevator suddenly spontaneously converted into antimatter. The resulting explosion when it hit bottom would be enough to devastate the surrounding city in an (admittedly spectacular) flash of high-energy radiation.
:-)
Likely? No, but a Worst Case is a Worst Case.
I imagine at this point some smartarse is going to point out that some methodology-of-the-month ensures that comments are never necessary because they break down every function/method into named sub-functions and everything's self-documenting through appropriate long names. My experience that such systems have real problems as they get larger because you end up with enormous numbers of tiny named functions splattered all over and to get anything done you have to memorize loads of the things. It's like you've gone from a graph where the interesting things are the nodes to a graph where the interesting things are the links, and there's many orders of magnitude more links than nodes. My working memory just isn't good enough to hold all that stuff in my head at once! To cut a long story short, as in all programming tasks, there is a balance to be struck between keeping individual components small (and so comprehensible in themselves) and keeping the overall system comprehensible. What marks a really good programmer is that they get that balance right just about all the time. And (to get back on topic!) comments help a lot by making it easier to fully comprehend more complex components, freeing up more brain-cells for the bigger picture.
By the way, I have seen some neat systems which offer integration of issue database and revision control; they're very neat and if you've got access to such a thing, use it! (I'd offer a link, but I can't quite remember the name of it...)
I use a laptop at work and I find it is better for my hands and wrists because it puts a mousepad in a place where I can use it without removing my fingers from the home row. By contrast, a real mouse is much less comfortable to use (leastways that's what I found). I think the whole trick lies in the angle of the wrists.
If you can, get someone who knows about desk ergonomics to assess your working environment and follow their recommendations. Your body is more important to you than your slobby bad seating habits. Similarly with your eyesight; a good opthalmologist might not be cheap, but it's not a thing to skimp on.
Why put a default in when the default default (do nothing) is good enough?
Design documents are a bit like mission statements: a standing joke that is better than the alternative.
It seems that IE seems to always do magic checking; renaming a PNG image to .html left it still renderable as an image. Ick!
By contrast, Firefox (on Win) won't interpret anything that is claimed to be of text/* MIME type as any of the image/* types, but will do magic guessing to get the type of image if the server supplies the wrong content-type. Which is not to say that FF is vulnerable in the first place; that depends on whether it displays WMF-format images at all.
Of course, type-safety is a much lesser concept than program correctness. All it does is catch a larger subset of lower-level problems (FWIW, there's an infinite number of possible layers of abstraction and nothing as simple as a type system can tackle them all tractably) and occasionally get horribly in your way when you're coding something. But all too often people don't want to pay for correctness; they assume (usually correctly) that they can get "good enough" for less cost.
Well, unless they happen to be worshippers of Osiris or Cthulhu or something else unusual. If that's a description of you, I sincerely apologize.
The only way to deal with this is for the manufacturer to make utterly sure that that key never leaks. (The TCG's master key is like this in spades; a theft of that would ruin the whole system.)
Your main problem though is going to be the people offended that there isn't a .goddess TLD; someone's bound to think that's important and kick up a fuss.
It's better to laugh at such a bad situation than to cry. There's too much crying in the world already, and laughter will help to put the fools behind such asinine censorship in their place.
The real value is that you only have to make one call to malloc() or new. That's valuable in places where saving cycles counts but you still have to use variable-sized structures. The only alternatives are either doing malloc()s, or allocating on the stack. Stack allocation is all very well if you're writing a small single-threaded program that runs on a desktop system, but it sucks in big complex programs (where memory allocation and usage patterns tend to get non-trivial) threaded apps (you usually try to use a smaller stack in threads if you can, since stack space is essentially largely unshared between threads) and embedded contexts (where you tend to have a miniscule stack!)
On the other hand, GC doesn't work too well with it either (because GC across a distributed object system sucks unless your network is perfect). Time-linked lifetimes (which you can update, of course) seem to work better.