"It depends what you consider 'real' Hungarian used 'reasonably'."
I use: "m_" for private members (in my code, typically, all the data members of a class will be private; structs will be nothing but public data members)
Then, in apropriate order:
"a" for arrays (in the generic sense; i.e. STL containers too)
"p" for pointers (again generically, could be a "Whatever *", could be a SmartPointer<Whatever>
"r" for a non-const reference
Finally type: "n", "f", and "s" to indicate generic integers, floating points, and strings. I'll use "u", "i", "l", and "d" if the specific flavor of integer or floating point matters particularly.
I also use a small salad of other things, e.g "it" for iterator (though I think of that as an abreviation, not a notation.)
"Using 'm_fValue' for a member value of type float is foolish, because if you ever change the value to be of type double, or LibraryExtendedPrecisionDouble, your name is now worse than useless, it's misleading."
The same argument can be made against commenting your code. If you change the code and not the comment, the comment will be misleading. Should one then never comment code? If you change the type of the variable, you're right there at the declaration, so change the name too. Now the compiler will quickly show you all the places the old name was used. You were going to check all those places to make sure your change wasn't a problem, right? Of course you were. So while you're at it you can update the name to indicate that you've checked it.
So I'll frequently have an "f" on a double. The important thing is that it's a floating point. You may have noticed I have no way to indicate a float that definitely isn't a double. I've never had a problem with that. Nor can I imagine well written code using a float theat couldn't use a double.
"The best one I ever saw was someone who insisted on prefixing all variables of reference types with "r", e.g., "rValue" instead of "value". That demonstrates a spectacular misunderstanding of both the value of warts and the implications of using a reference, all with one letter.:-)"
Well, I wouldn't put an "r" in front function argument that's a const reference; that's just an optimization, it doesn't matter for your use of the var. For a non-const reference though, I'd put that "r" tied with "m_" for most useful hungarian element. Using a non-const reference has important imlications. I want to know that's what it is every time I use the variable.
I would write it "m_fContainingCircleArea". I do like knowing at a glance that an identifier is a member variable, and I've never heard a good reason why people don't like reasonable use of Hungarian.
I had one coworker who hated it. So, for example, when declaring an integer, he would absolutely refuse to stick a lowercase "i" or "n" on the front. 8 times out of 10 the variable name would include "Num", "Number", "Count", etc. anyway, but not in a consistant place, and not all the time. An "n" would have been shorter, easier to find, and would have become a habit.
Really, what is the problem people have with Hungarian, assuming it is used reasonably? (By which I mean, my prefix strings are almost exclusively single-charachters, and only about 6 different ones.)
"Starting salaries for teachers in Fairfax County appear to be at least 30, or maybe 36"
Says a random poster on a message board in answer to someone w/ 7 years experience. Googling around a bit on starting teacher salaries (no experience/bachelors degree/presumably a year of making even less while getting certified) I see mostly numbers in the low 20s. Assuming of course you start right out in the public schools, which you can't because you're competing with people who have experience in private schools, where you'll start mid-high teens. Anyway, I'd expect Fairfax is pretty close to the top of the curve, so maybe it's near 30.
"You're rebuttal about 'average accross the profession' just doesn't compute. Somebody has to make up the other side of that average.."
Of course. Over the course of a career as a teacher, you will make up both sides of the average. Starting out below, and winding up above, with your career-long average probably somewhere close to 44K.
"That still sounds like d*** good money to me." Of course it does right now while you're making less. But my question is, would you be happy knowing that was going to be your average salary over the course of your career as a programmer? I sure wouldn't.
"Maybe that's because I don't eat out every night, drive a Mercedes, live in a box mansion, or buy every new disposable gadget that comes down the pike." Niether do I. I have kids instead. Let's guess: You're a 25 year old bachelor living in an apartment with a roomate? I was making 28K at that stage, and thinking it was hog-heaven. I'm guessing that when you get to mid-career (say age 40), being at 44K won't sound so good to you.
But really, you're mainly bugging me with your constant refrain of "whining teachers". Get it straight: I'm the one who's whining, and I'm not a teacher.
I think teachers should be paid more. Not because I feel sorry for the poor underpaid teachers, but because I think we should have better teachers. I had a few good teachers, and I do think they deserve more. But more importantly I also had a whole bunch of mediocre or even poor teachers, and I think they should be replaced by better ones. But most of the people who could be better ones won't because the pay sucks.
The bottom line? I think we should have better teachers than we do. In any proffession, you get better people by offering more. I think we should offer more for the position of "teacher", which you'll note is slightly different from saying we should pay those who are now teachers more.
For the level of education/training/certification required, it kind of sucks if you ask me. Anyone who could be a good teacher ought to be able to do better elsewhere. Which of course, most of them do.
"It's more than I made in tech support or programming."
How long were you a programmer? 44K average; as in for teachers at all points in their careers. If making an average of 44K over the course of a life long career as a programmer sounds good to you, you must be a lousy programmer. I passed that mark in year 2. Teachers should expect to in year what? 15, 20? That's pretty lame. I don't know what you were getting paid as an entry level programmer, but whatever it was, I'll bet you that much that it's more than an entry-level teacher gets in your school district.
Perhaps if good teachers couldn't make more money doing tech support, we'd have better teachers, and then you'd know how to spell "persistent". Not to mention knowing whether it makes sense to compare your entry level salary to the average for an entire profession.
NASA is worried about being "shown up"? I think not. NASA sent Alan Shepard on a flight roughly equivalent to what these guys are attempting. In 1961. Maybe NASA will be worried when these guys are a little less than 42 years behind.
Why would you measure c? c is exactly 299,792,458 m/s. If you are talking of measuring c, I don't think you're in a position to question anyones grasp of physics.
You might use c (the speed of light in a vaccum) in measuring the speed of light in whatever is inside your microwave, and there would be no problem there.
But you can't really measure c itself at all. Its value is not the result of measurement, it is the result of definition. Certainly a bunch of measurement was done to pick a value to define it to that wouldn't make the meter too different from what it was, but at this point, if you measure how far light travels in a vaccum in a certain amount of time, you are not measuring c. You are measuring the meter.
On every keyboard I've ripped apart (several) the keys slope differently between the different rows, giving the keyboard a slightly dished shape from top to bottom. You don't notice it until you rearange the keys and they're all wonky.
Relabeling the keys is an option, but most labeling methods don't hold up well. And it's a pain, considering you can buy a Dvorak labeled keyboard for not too much money.
But it need not be looked at so cynically. Sure, a lot of amazing new things are really just finding things that worked well in the past. But the key is finding the right things, and doing them in ways that take advantage of advances made in between.
People using "plain text" found that they needed to express more of the structure of the data, and invented various ways to do this, but they lost the advantages of plain text because they used different markup strategies, or different binary formats. So some people realized they could get most of the advantages of plain text, plus the advantages of markup, if they could get people to standardize on a particular markup strategy. Hence XML.
XML really is nicer for many things than "plain text". If by "plain text" you mean really plain text (no markup), then XML is more expressive. If you mean text using some markup scheme, then it is nicer because it's standardized. If I never have to figure another one-off markup scheme, that alone will qualify as "gee whizzery".
And the margin of error for purely electronic voting methods is...
Hmm, I'm don't know what it is. I guess we could find out by going back and recounting all the votes in various precincts to see how differently it turned out. Now that I think about it, that would be a good way to detect fraud as well, pretty much the only way. OK, I'm sure, we really ought to recount ballots in some randomly selected set of precincts, and we should definitely do it in any close races. Wait a second, there aren't any original ballots! The machine says how many votes were cast for each candidate, and we've got no way to check it. We just have to take the machines word for it, despite various incidents where we know the machine had problems.
I think most would agree this situation is theoretically really scary. It would be really really scary if, for example, electronic voting machines were widely used in a senate race that was won in a surprising upset by a candidate who was the former CEO of the company that made the voting machines. I mean, that would be really scary right? Good thing that didn't happen. Like, to pick a random example, in the election of Nebraska Senator Chuck Hagel in 1996 and again in 2002.
I'll take arguments about paper ballots any day. At least there is something to argue about.
I'm depressed the google searh returns no mention of the first game console I ever owned, named "Telstar". No cartriges, just a slide switch on top for selecting between 4 types of Pong.
"If you are thinking of work outside of work and you are not the owner of the business, you are a sap."
If you're spending eight hours a day doing something that doesn't interest you enough to think about it when you're not getting paid, you're the sap. I think about work outside of work when I want to, if I owned the place I'd have to. And I'd have to think about all the boring stupid parts of the business too.
Re:None of them measure up to good old C for speed
on
Does C# Measure Up?
·
· Score: 1
What moronic compiler are you using? In mine, a vector of int IS good old realloc and int *. and "[]" cooks down to the same position + offset as it does in C (using the default optimizations there's also some code to grow the memory by jumps instead of steps, avoiding most of those expensive reallocs; i.e. the way you should have written it in C if you were after max speed and thought about it enough). Any possibility you were dealing with a debug build?
C++ is slower when you use inheritance? So don't use it. C doesn't do inheritance at all, how can it be faster at it?
I was saying that code doing the same thing, if well written in C++ should be just as fast as if well written in C, and in many cases faster.
Even without inheritance, every function call already caries a fat price. C++, with templates and inlining, avoids a bunch of function calls C cannot.
You can take your C code, call it C++, and with a minor tweak or two it will compile, probably to the same machine code. So you've got a hard case to make if you're saying C++ can't be as fast as C. C++ also has a bunch of features designed to let you make the code even faster, and a bunch that let you make it "nicer" without any performance penalty. And a couple that let you make it much nicer, with some performace penalty. But unlike Java (for example) none of the additional features are compulsory. So, honestly, I think C still has it's place only amongst those who don't know C++.
Funny story:
A friend of mine who was a state trooper used to go down to the local track on the open to the public "race-what-you-bring" night. He'd park a mile or so down the road and listen to the tire squeals as people leaving peeled out of the lot. One squeal - he'll be speeding when he gets to you, but wait for a bigger ticket. Two squeals (starting and shifting into second) - Get the radar gun ready. Three squeals - Nice car. Floor it along the shoulder now, so you'll be up to speed to pull out behind him and pop on the siren. Fine will be very large.
The relevant thing about the story though - this was a small rural road, and absolutely everybody leaving the track was doing 10+ over the limit a mile away.
Well, I'm very careful about memory management and bounds checking:)
Seriously though, some simple coding practices/standards can help a lot there. My first day on my first job with C++, my boss showed me a template he had written named "SmartPointer", and said "never call 'new' except on the right hand side of an assignment to a SmartPointer; never call 'malloc' at all". I have followed this advice (well, mostly), and thus have never had a memory management problem. SmartPointer acts just like a pointer, you don't have to think about it. But it reference counts, so the last copy to go out of scope frees the memory.
I don't use char buffers except when forced (I use various string classes instead), and when I am forced I'm just uncomfortable enough with it to be very careful. I'm also concious of when I'm writing code that needs to be particularly security concious (not often).
Anyway, my experience is that while Java protects you from a certian class of problems, there are vastly more ways to write bad code that it doesn't (and can't) protect you from, so you still need talented, careful programmers. Also, "protecting" you from this one class of problems costs too much, IMO. For example, consistant use of SmartPointer handles memory cleanup as well as garbage collection, but I know exactly when it's going to happen, if I need to care I. (more likely, I know it's not going to happen in the middle of somewhere I need all the CPU I can get) I must admit though, my opinions are undoubtably shaped somewhat by the programmers I have known: The C++ ones have covered the spectrum from poor to excellent. The poor ones were easy to weed out, as they immediately foundered. The Java ones were Poor to Good (I assume Excellent ones exist, but I haven't met them). Java did enable the poor ones to muddle along, which might be considered a strength. But they eventually failed at the myriad aspects of programming that are language neutral. More than half of the Java programmers I have worked with have produced huge amounts of code which presumably had no memmory allocation or buffer overflow problems, but still wasn't worth doing anything with but deleting. I suspect I've had a particularly bad experience, obviously YMMV.
All that said, I think the best language for any job is one your programmers are comfortable with. So it's not that C++ is the best language, it's just that the best programmers like C++. Just kidding... mostly.
Re:None of them measure up to good old C for speed
on
Does C# Measure Up?
·
· Score: 1
"the difference in speed between a debug and optimized build in C++ seems to be greater than for C"
Big time. With C, one section of assembly maps fairly directly to one section of source. All of C++s features, particularly the ones that make things go faster are based on the compiler doing extra work that breaks that neat mapping. When it inlines that comparison function into the code generated by the templated sort, it creates a specialized, very fast sort function that exists in machine code only, and calls that from your code. Debug builds need to keep track of what source everything corresponds to, so the things that made it faster either don't happen, or happen with extra bookeeping that makes it even slower than the simpler way.
Re:None of them measure up to good old C for speed
on
Does C# Measure Up?
·
· Score: 1
Gotta disagree about C++ and the STL - they can be used so as to be just as fast as C, or faster. Take the sort function in the stardard c library versus in the STL. It's the same algorithm in both, probably a lot of the same code. It's a lot faster in C++. Since it's a template, the compiler can inline the comparison function, avoiding piles of function calling overhead. Lot's of people seem to think C++, and particularly templates, are a performance hit over C. But in fact, a lot of C++, and particularly templates, were designed specifically to avoid places in C where you had to make a choice between good (and easy) coding practices or performance (like using the standard sort rather than writing your own). I won't get you started on Java, since that would get me started on Java...
You're correct about why the C sort was slower - the function calling overhead for the comparison. Note that in C++, that same sort function is a template, so the compiler has the comparison operator at compile time and can inline it. Giving you the same benefit as the Java double sorter, but for any type, and any comparison function.
Re:As someone who's developed in C#, C++, C, VB...
on
Does C# Measure Up?
·
· Score: 1
"Yes, Assembly is faster then C/C++,"
Not in the real world. Studies have compared "hand optimized" assembly to that produced by good optimizing compilers, and the compilers won, hands down.
If there are 20 ways to do a particular construct in assembly, a human might know them all, and he might pick the fastest one in any given circumstance. But he'll miss the top few plenty of times too. The compiler might know only 19, but it can try all 19 and get the fastest of those every time. This boringly consistant very good code beats the humans occasional flashes of brilliance mixed with mostly only good code and occasional fumbles.
Re:The problem is: that's not the problem
on
Does C# Measure Up?
·
· Score: 1
"You're right. But with ever-increasing CPU horsepower, memory bandwidth, memory size, etc., there simply is no incentive for optimizing the things you're talking about. Moore's 'Law' has attenuated the advancement of software technology, by eliminating the need for efficient software."
Bull. I hate it when people say stuff like that. The optomizations he's talking about are in fact exactly how good compilers/linkers do it. Because it is needed. The faster machines get, the more we ask of them. Efficient software is still necessary. Let's say your program takes twice as many CPU cycles as mine. Maybe you got it done a little faster, so you have some cash left over for a twice as nice box to run it on. Great. Now I want to deploy it to 5000 boxes; who's more cost effective? I write code that goes on servers being used by a bunch of users at once. We're constantly trying to balance how much CPU we can let one user monopolize vs keeping things responsive for the rest. If my software is twice as fast today, you can wait six months and be as fast as I am today, but I'll still be twice as fast as you. We do build intelligent software that optimizes itself, such as the very techniques he's talking about.
"least-worst" is an important question. If I gave you the choice of being shot in the head, shot in the leg, or missed entirely, but I made it clear that if you picked "missed entirely", I was going to ignore you and shoot you in the head anyway, what would you pick?
"Little reason to put humans into space, huh? Perhaps there is little immediate practical reason to put humans into space, but it is the dream of a good number of humans to go to space."
Feel free to pay for it then. If you want me to pay for it, I'd like some return on my investment, and I'd like my money to be used wisely. For all of the reasons in the articles list, unmanned missions are just much more cost effective than manned ones.
"Here's an example: the Hubble telescope. Without humans, we would have a peice of junk floating around with a bad mirror." Without humans on the ground to figure out how to fix it, maybe. But what do you imagine the humans who went up and installed the fix did that couldn't have been done by a remotely operated robot? Apollo 13? without humans, it would just have been a failed mission (which it was anyway), no drama required.
I don't say humans should not be in space. I just don't think it's the most effective way to do the things in space that actually make a difference for those of us here on earth. Humans in space has a nice gee-whiz factor, and it's inspiring. But if you want gee-whiz and inspiration, pay for it your self.
RTFA. It points out some truly worthwhile goals served by a space program. Things that actually make our lives better and safer here on Earth. They're all acomplished by unmanned missions in earth orbit.
"It's understandable why the general case opinions are thusly biased, to some extent. Peer pressure, pressure and bias from the educational system, why, even our everyday language reinforces this learned predisposition towards evolution."
Before "Origin of Species" everyone beleived in creation. There was a huge bias against evolution. Evolution overcame this bias because the theory had merit. So creationists can suck it up. If your theory has merit, bias won't stop it. The fact that it has largely fallen by the wayside despite starting out with almost universal bias in its favor might be seen as an indication of its merit...
"That is why in this discussion I need -- must -- to see proof of... species crossing specie boundaries and becoming new, viable organisims of a new kind"
Which you know you're safe from, because evolution says it will take thousands, even millions of years.
I direct you for a third time to the bony skeletons of marine mammals. Let us consider the explaination for this under three different hypotheses:
Biblical Creation: God made them that way. Joe-The-Giant-Turtle: Joe barfed them that way. Evolution: The distant ancestors of these creatures lived on land, and thus needed rigid skeletons.
Now let us imagine that marine mammals had skeletons of flexible cartilage, like everything else that lives exclusively in water, yet still had air-breathing lungs, like land dwellers:
Biblical Creation: God made them that way. Joe-The-Giant-Turtle: Joe barfed them that way. Evolution: That doesn't make sense.
See the difference? The Creationisms (whether biblical or giant turtle) work regardless of the evidence, while evolution does not. This is why evolution is a theory and creationism is not. Bring up all the contorted reasons you like why evolution might be wrong even though it seems right. Evolution is still a theory. It may be "just" a theory, but gravity is "just a theory". Why doesn't anyone get up in arms about our teaching that bodies attract each other in proportion to their mass? Don't you think we should be teaching the alternate explanation that things fall because God makes them fall, that planets orbit the sun because that's where God wants them to be? Gravity is just a theory after all, it's never been proved.
Certainly evolution should be taught as a theory, just like gravity should be taught as a theory. Creationism is not a theory, and should not be taught as one.
Slashdot Mirror
"It depends what you consider 'real' Hungarian used 'reasonably'."
:-)"
I use:
"m_" for private members (in my code, typically, all the data members of a class will be private; structs will be nothing but public data members)
Then, in apropriate order:
"a" for arrays (in the generic sense; i.e. STL containers too)
"p" for pointers (again generically, could be a "Whatever *", could be a SmartPointer<Whatever>
"r" for a non-const reference
Finally type:
"n", "f", and "s" to indicate generic integers, floating points, and strings. I'll use "u", "i", "l", and "d" if the specific flavor of integer or floating point matters particularly.
I also use a small salad of other things, e.g "it" for iterator (though I think of that as an abreviation, not a notation.)
"Using 'm_fValue' for a member value of type float is foolish, because if you ever change the value to be of type double, or LibraryExtendedPrecisionDouble, your name is now worse than useless, it's misleading."
The same argument can be made against commenting your code. If you change the code and not the comment, the comment will be misleading. Should one then never comment code? If you change the type of the variable, you're right there at the declaration, so change the name too. Now the compiler will quickly show you all the places the old name was used. You were going to check all those places to make sure your change wasn't a problem, right? Of course you were. So while you're at it you can update the name to indicate that you've checked it.
So I'll frequently have an "f" on a double. The important thing is that it's a floating point. You may have noticed I have no way to indicate a float that definitely isn't a double. I've never had a problem with that. Nor can I imagine well written code using a float theat couldn't use a double.
"The best one I ever saw was someone who insisted on prefixing all variables of reference types with "r", e.g., "rValue" instead of "value". That demonstrates a spectacular misunderstanding of both the value of warts and the implications of using a reference, all with one letter.
Well, I wouldn't put an "r" in front function argument that's a const reference; that's just an optimization, it doesn't matter for your use of the var. For a non-const reference though, I'd put that "r" tied with "m_" for most useful hungarian element. Using a non-const reference has important imlications. I want to know that's what it is every time I use the variable.
I would write it "m_fContainingCircleArea".
I do like knowing at a glance that an identifier is a member variable, and I've never heard a good reason why people don't like reasonable use of Hungarian.
I had one coworker who hated it. So, for example, when declaring an integer, he would absolutely refuse to stick a lowercase "i" or "n" on the front. 8 times out of 10 the variable name would include "Num", "Number", "Count", etc. anyway, but not in a consistant place, and not all the time. An "n" would have been shorter, easier to find, and would have become a habit.
Really, what is the problem people have with Hungarian, assuming it is used reasonably? (By which I mean, my prefix strings are almost exclusively single-charachters, and only about 6 different ones.)
"Starting salaries for teachers in Fairfax County appear to be at least 30, or maybe 36"
Says a random poster on a message board in answer to someone w/ 7 years experience. Googling around a bit on starting teacher salaries (no experience/bachelors degree/presumably a year of making even less while getting certified) I see mostly numbers in the low 20s. Assuming of course you start right out in the public schools, which you can't because you're competing with people who have experience in private schools, where you'll start mid-high teens. Anyway, I'd expect Fairfax is pretty close to the top of the curve, so maybe it's near 30.
"You're rebuttal about 'average accross the profession' just doesn't compute. Somebody has to make up the other side of that average.."
Of course. Over the course of a career as a teacher, you will make up both sides of the average. Starting out below, and winding up above, with your career-long average probably somewhere close to 44K.
"That still sounds like d*** good money to me."
Of course it does right now while you're making less. But my question is, would you be happy knowing that was going to be your average salary over the course of your career as a programmer? I sure wouldn't.
"Maybe that's because I don't eat out every night, drive a Mercedes, live in a box mansion, or buy every new disposable gadget that comes down the pike."
Niether do I. I have kids instead. Let's guess: You're a 25 year old bachelor living in an apartment with a roomate? I was making 28K at that stage, and thinking it was hog-heaven. I'm guessing that when you get to mid-career (say age 40), being at 44K won't sound so good to you.
But really, you're mainly bugging me with your constant refrain of "whining teachers". Get it straight: I'm the one who's whining, and I'm not a teacher.
I think teachers should be paid more. Not because I feel sorry for the poor underpaid teachers, but because I think we should have better teachers. I had a few good teachers, and I do think they deserve more. But more importantly I also had a whole bunch of mediocre or even poor teachers, and I think they should be replaced by better ones. But most of the people who could be better ones won't because the pay sucks.
The bottom line? I think we should have better teachers than we do. In any proffession, you get better people by offering more. I think we should offer more for the position of "teacher", which you'll note is slightly different from saying we should pay those who are now teachers more.
"44k average nationwide isn't bad at all."
For the level of education/training/certification required, it kind of sucks if you ask me. Anyone who could be a good teacher ought to be able to do better elsewhere. Which of course, most of them do.
"It's more than I made in tech support or programming."
How long were you a programmer? 44K average; as in for teachers at all points in their careers. If making an average of 44K over the course of a life long career as a programmer sounds good to you, you must be a lousy programmer. I passed that mark in year 2. Teachers should expect to in year what? 15, 20? That's pretty lame.
I don't know what you were getting paid as an entry level programmer, but whatever it was, I'll bet you that much that it's more than an entry-level teacher gets in your school district.
Perhaps if good teachers couldn't make more money doing tech support, we'd have better teachers, and then you'd know how to spell "persistent". Not to mention knowing whether it makes sense to compare your entry level salary to the average for an entire profession.
NASA is worried about being "shown up"? I think not. NASA sent Alan Shepard on a flight roughly equivalent to what these guys are attempting. In 1961. Maybe NASA will be worried when these guys are a little less than 42 years behind.
"You CANNOT use the value of c to measure c"
Why would you measure c? c is exactly 299,792,458 m/s. If you are talking of measuring c, I don't think you're in a position to question anyones grasp of physics.
You might use c (the speed of light in a vaccum) in measuring the speed of light in whatever is inside your microwave, and there would be no problem there.
But you can't really measure c itself at all. Its value is not the result of measurement, it is the result of definition. Certainly a bunch of measurement was done to pick a value to define it to that wouldn't make the meter too different from what it was, but at this point, if you measure how far light travels in a vaccum in a certain amount of time, you are not measuring c. You are measuring the meter.
On every keyboard I've ripped apart (several) the keys slope differently between the different rows, giving the keyboard a slightly dished shape from top to bottom. You don't notice it until you rearange the keys and they're all wonky.
Relabeling the keys is an option, but most labeling methods don't hold up well. And it's a pain, considering you can buy a Dvorak labeled keyboard for not too much money.
But it need not be looked at so cynically. Sure, a lot of amazing new things are really just finding things that worked well in the past. But the key is finding the right things, and doing them in ways that take advantage of advances made in between.
People using "plain text" found that they needed to express more of the structure of the data, and invented various ways to do this, but they lost the advantages of plain text because they used different markup strategies, or different binary formats. So some people realized they could get most of the advantages of plain text, plus the advantages of markup, if they could get people to standardize on a particular markup strategy. Hence XML.
XML really is nicer for many things than "plain text". If by "plain text" you mean really plain text (no markup), then XML is more expressive. If you mean text using some markup scheme, then it is nicer because it's standardized. If I never have to figure another one-off markup scheme, that alone will qualify as "gee whizzery".
And the margin of error for purely electronic voting methods is...
Hmm, I'm don't know what it is. I guess we could find out by going back and recounting all the votes in various precincts to see how differently it turned out. Now that I think about it, that would be a good way to detect fraud as well, pretty much the only way. OK, I'm sure, we really ought to recount ballots in some randomly selected set of precincts, and we should definitely do it in any close races. Wait a second, there aren't any original ballots!
The machine says how many votes were cast for each candidate, and we've got no way to check it. We just have to take the machines word for it, despite various incidents where we know the machine had problems.
I think most would agree this situation is theoretically really scary. It would be really really scary if, for example, electronic voting machines were widely used in a senate race that was won in a surprising upset by a candidate who was the former CEO of the company that made the voting machines. I mean, that would be really scary right? Good thing that didn't happen. Like, to pick a random example, in the election of Nebraska Senator Chuck Hagel in 1996 and again in 2002.
I'll take arguments about paper ballots any day. At least there is something to argue about.
"I got it done in time--about nine months. It was a beautiful candidate for rapid application development. "
LOL! I'll let you know when I get a development cycle longer than 2 months. Until then, I guess I'll stick to C++.
Not terribly on-topic:
I'm depressed the google searh returns no mention of the first game console I ever owned, named "Telstar". No cartriges, just a slide switch on top for selecting between 4 types of Pong.
"If you are thinking of work outside of work and you are not the owner of the business, you are a sap."
If you're spending eight hours a day doing something that doesn't interest you enough to think about it when you're not getting paid, you're the sap. I think about work outside of work when I want to, if I owned the place I'd have to. And I'd have to think about all the boring stupid parts of the business too.
What moronic compiler are you using? In mine, a vector of int IS good old realloc and int *. and "[]" cooks down to the same position + offset as it does in C (using the default optimizations there's also some code to grow the memory by jumps instead of steps, avoiding most of those expensive reallocs; i.e. the way you should have written it in C if you were after max speed and thought about it enough). Any possibility you were dealing with a debug build?
C++ is slower when you use inheritance? So don't use it. C doesn't do inheritance at all, how can it be faster at it?
I was saying that code doing the same thing, if well written in C++ should be just as fast as if well written in C, and in many cases faster.
Even without inheritance, every function call already caries a fat price. C++, with templates and inlining, avoids a bunch of function calls C cannot.
You can take your C code, call it C++, and with a minor tweak or two it will compile, probably to the same machine code. So you've got a hard case to make if you're saying C++ can't be as fast as C. C++ also has a bunch of features designed to let you make the code even faster, and a bunch that let you make it "nicer" without any performance penalty. And a couple that let you make it much nicer, with some performace penalty. But unlike Java (for example) none of the additional features are compulsory. So, honestly, I think C still has it's place only amongst those who don't know C++.
Funny story:
A friend of mine who was a state trooper used to go down to the local track on the open to the public "race-what-you-bring" night. He'd park a mile or so down the road and listen to the tire squeals as people leaving peeled out of the lot.
One squeal - he'll be speeding when he gets to you, but wait for a bigger ticket.
Two squeals (starting and shifting into second) - Get the radar gun ready.
Three squeals - Nice car. Floor it along the shoulder now, so you'll be up to speed to pull out behind him and pop on the siren. Fine will be very large.
The relevant thing about the story though - this was a small rural road, and absolutely everybody leaving the track was doing 10+ over the limit a mile away.
And when you THINK you're the only one on the road...
Well, I'm very careful about memory management and bounds checking
Seriously though, some simple coding practices/standards can help a lot there. My first day on my first job with C++, my boss showed me a template he had written named "SmartPointer", and said "never call 'new' except on the right hand side of an assignment to a SmartPointer; never call 'malloc' at all". I have followed this advice (well, mostly), and thus have never had a memory management problem. SmartPointer acts just like a pointer, you don't have to think about it. But it reference counts, so the last copy to go out of scope frees the memory.
I don't use char buffers except when forced (I use various string classes instead), and when I am forced I'm just uncomfortable enough with it to be very careful. I'm also concious of when I'm writing code that needs to be particularly security concious (not often).
Anyway, my experience is that while Java protects you from a certian class of problems, there are vastly more ways to write bad code that it doesn't (and can't) protect you from, so you still need talented, careful programmers. Also, "protecting" you from this one class of problems costs too much, IMO. For example, consistant use of SmartPointer handles memory cleanup as well as garbage collection, but I know exactly when it's going to happen, if I need to care I. (more likely, I know it's not going to happen in the middle of somewhere I need all the CPU I can get)
I must admit though, my opinions are undoubtably shaped somewhat by the programmers I have known: The C++ ones have covered the spectrum from poor to excellent. The poor ones were easy to weed out, as they immediately foundered. The Java ones were Poor to Good (I assume Excellent ones exist, but I haven't met them). Java did enable the poor ones to muddle along, which might be considered a strength. But they eventually failed at the myriad aspects of programming that are language neutral. More than half of the Java programmers I have worked with have produced huge amounts of code which presumably had no memmory allocation or buffer overflow problems, but still wasn't worth doing anything with but deleting. I suspect I've had a particularly bad experience, obviously YMMV.
All that said, I think the best language for any job is one your programmers are comfortable with. So it's not that C++ is the best language, it's just that the best programmers like C++. Just kidding... mostly.
"the difference in speed between a debug and optimized build in C++ seems to be greater than for C"
Big time. With C, one section of assembly maps fairly directly to one section of source. All of C++s features, particularly the ones that make things go faster are based on the compiler doing extra work that breaks that neat mapping. When it inlines that comparison function into the code generated by the templated sort, it creates a specialized, very fast sort function that exists in machine code only, and calls that from your code. Debug builds need to keep track of what source everything corresponds to, so the things that made it faster either don't happen, or happen with extra bookeeping that makes it even slower than the simpler way.
Gotta disagree about C++ and the STL - they can be used so as to be just as fast as C, or faster. Take the sort function in the stardard c library versus in the STL. It's the same algorithm in both, probably a lot of the same code. It's a lot faster in C++. Since it's a template, the compiler can inline the comparison function, avoiding piles of function calling overhead.
Lot's of people seem to think C++, and particularly templates, are a performance hit over C. But in fact, a lot of C++, and particularly templates, were designed specifically to avoid places in C where you had to make a choice between good (and easy) coding practices or performance (like using the standard sort rather than writing your own).
I won't get you started on Java, since that would get me started on Java...
You're correct about why the C sort was slower - the function calling overhead for the comparison. Note that in C++, that same sort function is a template, so the compiler has the comparison operator at compile time and can inline it. Giving you the same benefit as the Java double sorter, but for any type, and any comparison function.
"Yes, Assembly is faster then C/C++,"
Not in the real world. Studies have compared "hand optimized" assembly to that produced by good optimizing compilers, and the compilers won, hands down.
If there are 20 ways to do a particular construct in assembly, a human might know them all, and he might pick the fastest one in any given circumstance. But he'll miss the top few plenty of times too. The compiler might know only 19, but it can try all 19 and get the fastest of those every time. This boringly consistant very good code beats the humans occasional flashes of brilliance mixed with mostly only good code and occasional fumbles.
"You're right. But with ever-increasing CPU horsepower, memory bandwidth, memory size, etc., there simply is no incentive for optimizing the things you're talking about. Moore's 'Law' has attenuated the advancement of software technology, by eliminating the need for efficient software."
Bull. I hate it when people say stuff like that. The optomizations he's talking about are in fact exactly how good compilers/linkers do it. Because it is needed. The faster machines get, the more we ask of them. Efficient software is still necessary. Let's say your program takes twice as many CPU cycles as mine. Maybe you got it done a little faster, so you have some cash left over for a twice as nice box to run it on. Great. Now I want to deploy it to 5000 boxes; who's more cost effective? I write code that goes on servers being used by a bunch of users at once. We're constantly trying to balance how much CPU we can let one user monopolize vs keeping things responsive for the rest.
If my software is twice as fast today, you can wait six months and be as fast as I am today, but I'll still be twice as fast as you.
We do build intelligent software that optimizes itself, such as the very techniques he's talking about.
"least-worst" is an important question. If I gave you the choice of being shot in the head, shot in the leg, or missed entirely, but I made it clear that if you picked "missed entirely", I was going to ignore you and shoot you in the head anyway, what would you pick?
"Little reason to put humans into space, huh? Perhaps there is little immediate practical reason to put humans into space, but it is the dream of a good number of humans to go to space."
Feel free to pay for it then. If you want me to pay for it, I'd like some return on my investment, and I'd like my money to be used wisely. For all of the reasons in the articles list, unmanned missions are just much more cost effective than manned ones.
"Here's an example: the Hubble telescope. Without humans, we would have a peice of junk floating around with a bad mirror."
Without humans on the ground to figure out how to fix it, maybe. But what do you imagine the humans who went up and installed the fix did that couldn't have been done by a remotely operated robot? Apollo 13? without humans, it would just have been a failed mission (which it was anyway), no drama required.
I don't say humans should not be in space. I just don't think it's the most effective way to do the things in space that actually make a difference for those of us here on earth. Humans in space has a nice gee-whiz factor, and it's inspiring. But if you want gee-whiz and inspiration, pay for it your self.
RTFA. It points out some truly worthwhile goals served by a space program. Things that actually make our lives better and safer here on Earth. They're all acomplished by unmanned missions in earth orbit.
"It's understandable why the general case opinions are thusly biased, to some extent. Peer pressure, pressure and bias from the educational system, why, even our everyday language reinforces this learned predisposition towards evolution."
... species crossing specie boundaries and becoming new, viable organisims of a new kind"
Before "Origin of Species" everyone beleived in creation. There was a huge bias against evolution. Evolution overcame this bias because the theory had merit. So creationists can suck it up. If your theory has merit, bias won't stop it. The fact that it has largely fallen by the wayside despite starting out with almost universal bias in its favor might be seen as an indication of its merit...
"That is why in this discussion I need -- must -- to see proof of
Which you know you're safe from, because evolution says it will take thousands, even millions of years.
I direct you for a third time to the bony skeletons of marine mammals. Let us consider the explaination for this under three different hypotheses:
Biblical Creation: God made them that way.
Joe-The-Giant-Turtle: Joe barfed them that way.
Evolution: The distant ancestors of these creatures lived on land, and thus needed rigid skeletons.
Now let us imagine that marine mammals had skeletons of flexible cartilage, like everything else that lives exclusively in water, yet still had air-breathing lungs, like land dwellers:
Biblical Creation: God made them that way.
Joe-The-Giant-Turtle: Joe barfed them that way.
Evolution: That doesn't make sense.
See the difference? The Creationisms (whether biblical or giant turtle) work regardless of the evidence, while evolution does not. This is why evolution is a theory and creationism is not.
Bring up all the contorted reasons you like why evolution might be wrong even though it seems right. Evolution is still a theory. It may be "just" a theory, but gravity is "just a theory". Why doesn't anyone get up in arms about our teaching that bodies attract each other in proportion to their mass? Don't you think we should be teaching the alternate explanation that things fall because God makes them fall, that planets orbit the sun because that's where God wants them to be? Gravity is just a theory after all, it's never been proved.
Certainly evolution should be taught as a theory, just like gravity should be taught as a theory. Creationism is not a theory, and should not be taught as one.