It's pretty simple, really. There are a lot of platforms which simply do not have a Python implementation, period. Just to pull out one random example, you can write C++ on a Lego Mindstorms brick, but good luck squeezing a Python implementation in there.
C++ goes just about anywhere that C goes, and Python is necessarily limited to a subset of where C goes due to being implemented in C. Now, if all you're doing is Windows and UNIX-alikes, this doesn't matter so much, but C++ can be a lot more portable depending on exactly what you're writing and where you want to run.
I'm not being unfair, I'm explaining why I use what I use.
It's still an external library, not built in. And even ignoring that, I couldn't find any indication that Boost implements some pretty basic things like URL fetching or data compression. I could be wrong.
Since C++ is not a dynamically typed language, how can you say that it has nothing to do with C++? Newsflash: I don't like C++ because it's not dynamically typed.
Python uses reference counting with a cycle collector. This makes an enormous difference. Plain old refcounting is just a memory management aid, whereas adding cycle collection gives you a full-up garbage collector.
And on for your last point, if I were writing a web server then I probably would do it in Python, since any web server I write is almost certain to be I/O bound, not CPU bound. I have no idea what a daemon control program would do that would require using C++; it sounds like a pretty simple and performance-unintensive thing to me. And large desktop software is exactly where dynamic, duck-typed, true OO languages shine. Note that Adobe wrote a significant chunk of Lightroom in Lua, just as one example.
When you have a language like Python, which is defined by a single (very slow) implementation, and a language like C, which is nearly always compiled fairly directly to machine code, I think it's entirely fair to say that C is a faster language than Python. The comparison isn't perfect, but IMO it's quite meaningful.
Boost is an external library, and from my very limited experience none too easy to incorporate.
Likewise, an external library. But putting that aside for a moment, what's the C++ equivalent to this python code? d = {"name":"Bob", "age":42} print "Name is %s and age is %d" % (d["name"], d["age"]) Keep in mind that this is a complete python program, no further code is required.
While those are handy, they don't substitute for a real garbage collector.
I hope you're right, but I'm skeptical. Massive template instantiation errors seem to be a compiler problem, not a spec problem.
Key words being "can be". It's tough to do, especially since the compilers out there almost never comply perfectly with the spec.
Of course it's a matter of taste, I never said otherwise.
Wow, I don't know what I wrote to deserve such a response.
Speaking from my own personal experience, developing anything sizable in C++ takes much longer than in other languages. Maybe there are C++ gurus out there for whom this is not true. If so, good for them. It does not change my situation. For me, C++ is the wrong tool for the job, end of story. You don't have to agree with that, or even like it, but you ought to at least respect it.
No, the "premature optimization" thing applies to all areas. Especially areas where it's never fast enough.
Why? It's simple: resource management.
You have X amount of resources to put into your product. X is always finite. It's kind of tough to measure X, but you can think of it as lines of code, man-years, or even just dollars. The amount of resources you have varies a lot depending on your budget, how much time you have, and the quality of the programmers you have. But the important thing is that X is always limited.
Now you have two approaches:
Spend X on making the code fast from the start, and keep spending X until you run out.
Spend X on making the code functional and with good design. When appropriate (i.e. when the design is good and the code works), start spending X on making the program go faster. Keep spending X on speed until you run out.
Paradoxically, I hold that #2 will produce a faster program. This is because the X you spend on making the program faster in #2 will be more effective, because you've already laid the groundwork for it. It's always difficult and time consuming to optimize code that doesn't even run yet. It's much more efficient to optimize code that already works. So the result, even though you spend less X on speed, is a faster program.
Think of it as transporting a lot of material into the wilderness somewhere. If you first spend some of your resources on building a road, you'll get the job done for less time and money than if you just start hauling stuff into the woods immediately.
Well, here's what I personally dislike about C++. You don't have to agree with them, but this is how I feel and I think it's how many other people do as well. Certainly when talking to people who prefer other languages over C++, they have expressed similar sentiments.
Lack of libraries. The C++ standard library basically gives you file IO, containers, and that's it. If I want to do something like fetch the contents of an HTTP URL, parse XML, serialize objects, compute dates and times, use regular expressions, compress data, or even just simple, basic Unicode support, then I have to hit some external library that I may have to install and probably can't rely on existing on another machine.
Flexibility. In C++ it is essentially impossible to make, say, a dictionary where each key can refer to an object of a completely different type. This is what you refer to as "sloppy", but I actually find this flexibility to be essential in designing good software. The fact that C++ does not allow it forces me to either twist my program's design in unnatural ways to fit the language, or do a lot of extra work to twist C++ to fit my program's design.
Manual memory management. In any complex program, balancing your news with deletes is not as simple as you make it out to be. Object ownership is a tough problem. Lots of C++ code solves this problem by making a lot of defensive copies, which in turn hurts performance greatly.
Errors. Make one simple typo in a template instantiation and you can generate literally pages of twisted, non-obvious errors. This makes it much harder to get a C++ program to compile than it should be.
Nonportability. C++ compilers tend to differ massively in just how well they adhere to the C++ specification. Creating portable C++ code is much harder than it ought to be, especially when you take into account the necessary dependence on external libraries I mentioned above. And then you need a build system to go with all of that, which brings its own set of headaches.
Readability and writability. With all the type information being declared all over the place, big template declarations, and the like, I find that C++ takes considerably more effort to both read and write.
The really big issues for me are the flexibility and the lack of libraries. The rest is less important. But with C++ it's like building a house out of 2x4s that you're not allowed to cut to length, whereas with moer modern languages it's more like building a house out of prefabricated rooms, with a ready supply of 2x4s and tools to shape them as you need if the prefabbed rooms don't fit your needs.
Please note that this is just my opinion, and you asked for it. Feel free to disagree, but please don't flame.
Objective-C is essentially unrelated to C++ in every way. C++0x does not change this fact at all. Comparing the two makes just slightly more sense than comparing C++ and Prolog.
For the curious, I'd have to drive 1 million miles at $4 a gallon before I spend as much money in gas as I save on my mortgage.
Well, over a typical 30 year mortgage at 50 miles each way per workday, you'll be driving about 624,000 miles so you're already a good chunk of the way there. Add in to that the additional wear and tear on your vehicles, the probability of gas prices rising further, the likely need to have two vehicles instead of one at least at some point, and this ceases to sound very good to me.
Was it a "fucking shame" when Rolladen-Schneider installed a bunch of mass balancing lead on the LS-3 control surfaces to guard against aerodynamic flutter? Was it a "fucking shame" when Boeing installed depleted uranium mass balances in the 747 for the same reason?
Installing extra equipment to guard against destructive vibration is standard in aerospace. The only thing unusual about this system is that it's active, rather than passive, which makes it lighter.
It might be plain to you, but it's not plain to me. I could make a wild guess as to what point you're trying to make with your approximate quote of my words, but I don't feel like putting forth the effort to play that game.
Wrong. It was an engine pressure sensor that tripped, due to pressure fluctuations naturally associated with pogo. Luck had nothing to do with it.
The pressure sensor was meant to detect consistent low chamber pressure. It was not intended to detect pogo, and there was no particular reason to expect it to pick up massive pressure fluctuations at 16Hz. It did so because the pogo had also lowered the average pressure, but there's no reason to expect this would happen consistently enough to reliably trip the sensor.
No, you're talking nonsense about "elegant" design versus "kludgey" design. I'm talking about real problems encountered due to engineering problems, shortsightedness, lack of care, or just plain inability to perfectly predict the future.
And I'm going to have to ask you for some direct evidence that all of Saturn's good parts were due to elegant European design and all of the bad parts were due to poor American workers, or else I'm going to have to simply dismiss you as a total loon, not to mention an asshole.
That's kind of funny, because I didn't source from the Wikipedia entry....
The engine was just seconds away from ripping off its mounts, which in turn would have almost certainly led to total destruction of the second stage. That surely counts as "nearly rip the entire rocket to little pieces" in my mind.
As to whether the fuel sensor tripped "falsely" or not is really a semantic debate. Suffice it to say, the condition that the sensor was supposed to detect (consistent low fuel pressure) and the condition that it actually detected (massively oscillating fuel pressure) were not the same, and the reason the computer shut the engine down (consistent low fuel pressure) and the reason the flight was in danger (literally tons of equipment vibrating 3 inches at 16Hz) were not the same. When you detect one problem, take corrective action, and inadvertently save yourself from a completely different disaster, that's what I call luck. As far as I'm aware there's no particular reason to believe that this fuel sensor would have necessarily caused the engine shutdown in time to save the flight had circumstances been slightly different.
I would like some actual evidence that 1600 pounds is abnormally large for vibration suppression. I don't know enough about the field to say whether it is or not, but from everything I've read about it, that number does not strike me as particularly bad. These rockets are big. For comparison, although the total weight of the rocket is not yet determined, this 1600 pound damping system will account for roughly one tenth of one percent of the total weight of just the first stage.
That fallacy does not detract from my overall point. Adding mass, structure, and systems to rockets in order to deal with vibration is a perfectly standard part of large rocket design. I do not know enough about the field to say whether 1600 pounds is a lot, a little, or a typical amount for the size of the rocket. But I have no reason to believe that it's abnormally large.
First, no Saturn V stage had six engines. It is therefore nonsensical to talk about "two affected engines" and "the other four engines". The first and second stages both had five engines.
Second, Apollo 13 only had one engine shut down due to pogo. There was an unmanned flight that lost two engines, Apollo 6. This also happened due to totally unanticipated violent pogo. Pieces were seen falling off the rocket at about two minutes after launch due to the intense vibration in the first stage. The second stage then experienced two premature engine shutdowns. The remaining three (not four!) engines burned for about a minute longer to compensate, but this was still not enough, and the third stage also had to burn for about half a minute longer. All of this combined to place the vehicle in the wrong orbit, although this was not a disaster and the mission was still abel to meet many of its goals.
Launch disaster during Apollo 13 was not averted due to an intentional cut-off as you state. A low fuel pressure sensor was tripped by the violent vibration, tricking the flight control computer into thinking that there was a fuel pressure problem and causing it to shut down the engine. This was all by accident. The computer was not programmed to deal with pogo in any way, and this sensor could have easily not tripped if things had gone just a little bit differently.
Saturn V pogo was never really solved, although after the modifications which were in place for Apollo 14 it became much less severe. Apollos 11 and 12 experienced pogo in the same engine as 13, but in a slightly different mode which happened to be much less violent. Significant pogo also happened on the third stage of Apollo 10 and the first stage of Apollo 6. Less violent pogo happened on essentially every flight of the Saturn V run. As a result, the Saturn V was being continually modified and refitted to deal with the different pogo oscillations which presented themselves after each new flight. In fact a fix for the Apollo 13 pogo was already in the pipeline (having been already observed on 11 and 12), but it was deemed too expensive to retrofit to the Apollo 13 launcher.
Calling this hodgepodge of guess-and-check which never really solved the problem "elegant", while calling a nifty, light, active damping system a 'kludge" is simply stupid.
Since resonance depends on the entire structure, not just the component that's generating the vibrations, there's no reason to expect that the experience from designing the shuttle SRBs would carry over to this new vehicle in terms of knowing what vibration to damp ahead of time.
Vibration damping in aircraft is extremely common. Just one example, a controversial use of depleted uranium is as control surface ballast on large airliners, used to modify the structure's resonance to avoid catastrophic flutter at high speeds. There's no real reason to expect any different in a spacecraft. Remember, the thing is still being designed. There may be reason to legitimately worry about such measures after the thing has been designed and tested and is into regular production flight, but criticizing them for a novel approach to fixing a very common problem during the design phase seems rather asinine to me.
I can't find that quote anywhere on the page I linked to. Your quote seems to have come from an Everything2 page, and of course in terms of reliability and authoritativeness, Everything2 makes Wikipedia look like the direct Voice of God.
Saying that the problem of pogo was "solved" is overstating things. There are known techniques for how to deal with it, and generally it doesn't catch people by surprise anymore. But the techniques for dealing with it, surprise surprise, involve installing extra equipment to damp out the vibrations. Just like these guys are doing here on Orion. Just about any large rocket is going to have some mass dedicated to damping vibration, there's no reason to think that Orion should be any different in this respect.
Large rockets really are surprisingly complex given how simple the principle is. I mean, stuff goes into the engine, stuff happens, stuff goes out faster than it went in! How hard could it be?
The real problem is scaling things up. A little plastic water rocket has an untenably low fraction of its weight dedicated to fuel, and a ridiculously poor specific impulse. A rocket that can reach orbit needs much more fuel and much better performance, and this pushes it right up to the bleeding edge of engineering and materials.
(And I'm sure you know this already and your comparison was not serious. I just wanted to elaborate a bit.)
How much do you suppose a "small" damper on the fuel line weighs on a 6.7 million pound rocket? I couldn't find any answers, but it would not surprise me if the Saturn V's "small" pogo suppressors weighed over 1600 pounds in total.
Slashdot Mirror
It's pretty simple, really. There are a lot of platforms which simply do not have a Python implementation, period. Just to pull out one random example, you can write C++ on a Lego Mindstorms brick, but good luck squeezing a Python implementation in there.
C++ goes just about anywhere that C goes, and Python is necessarily limited to a subset of where C goes due to being implemented in C. Now, if all you're doing is Windows and UNIX-alikes, this doesn't matter so much, but C++ can be a lot more portable depending on exactly what you're writing and where you want to run.
I'm not being unfair, I'm explaining why I use what I use.
And on for your last point, if I were writing a web server then I probably would do it in Python, since any web server I write is almost certain to be I/O bound, not CPU bound. I have no idea what a daemon control program would do that would require using C++; it sounds like a pretty simple and performance-unintensive thing to me. And large desktop software is exactly where dynamic, duck-typed, true OO languages shine. Note that Adobe wrote a significant chunk of Lightroom in Lua, just as one example.
Rather than rewrite it, I'll just direct you to another post I made. I don't claim these to be universal, but they're why I don't use the language.
When you have a language like Python, which is defined by a single (very slow) implementation, and a language like C, which is nearly always compiled fairly directly to machine code, I think it's entirely fair to say that C is a faster language than Python. The comparison isn't perfect, but IMO it's quite meaningful.
Counter-counterpoints:
d = {"name":"Bob", "age":42}
print "Name is %s and age is %d" % (d["name"], d["age"])
Keep in mind that this is a complete python program, no further code is required.
Wow, I don't know what I wrote to deserve such a response.
Speaking from my own personal experience, developing anything sizable in C++ takes much longer than in other languages. Maybe there are C++ gurus out there for whom this is not true. If so, good for them. It does not change my situation. For me, C++ is the wrong tool for the job, end of story. You don't have to agree with that, or even like it, but you ought to at least respect it.
No, the "premature optimization" thing applies to all areas. Especially areas where it's never fast enough.
Why? It's simple: resource management.
You have X amount of resources to put into your product. X is always finite. It's kind of tough to measure X, but you can think of it as lines of code, man-years, or even just dollars. The amount of resources you have varies a lot depending on your budget, how much time you have, and the quality of the programmers you have. But the important thing is that X is always limited.
Now you have two approaches:
Paradoxically, I hold that #2 will produce a faster program. This is because the X you spend on making the program faster in #2 will be more effective, because you've already laid the groundwork for it. It's always difficult and time consuming to optimize code that doesn't even run yet. It's much more efficient to optimize code that already works. So the result, even though you spend less X on speed, is a faster program.
Think of it as transporting a lot of material into the wilderness somewhere. If you first spend some of your resources on building a road, you'll get the job done for less time and money than if you just start hauling stuff into the woods immediately.
Well, here's what I personally dislike about C++. You don't have to agree with them, but this is how I feel and I think it's how many other people do as well. Certainly when talking to people who prefer other languages over C++, they have expressed similar sentiments.
The really big issues for me are the flexibility and the lack of libraries. The rest is less important. But with C++ it's like building a house out of 2x4s that you're not allowed to cut to length, whereas with moer modern languages it's more like building a house out of prefabricated rooms, with a ready supply of 2x4s and tools to shape them as you need if the prefabbed rooms don't fit your needs.
Please note that this is just my opinion, and you asked for it. Feel free to disagree, but please don't flame.
Objective-C is essentially unrelated to C++ in every way. C++0x does not change this fact at all. Comparing the two makes just slightly more sense than comparing C++ and Prolog.
Been there, done that.
Most of the time, the potentially reduced running time of the C++ implementation never comes close to the months saved in development.
And when it does, it's trivial to go in and write the speed-sensitive portions of the program in a faster language.
For the curious, I'd have to drive 1 million miles at $4 a gallon before I spend as much money in gas as I save on my mortgage.
Well, over a typical 30 year mortgage at 50 miles each way per workday, you'll be driving about 624,000 miles so you're already a good chunk of the way there. Add in to that the additional wear and tear on your vehicles, the probability of gas prices rising further, the likely need to have two vehicles instead of one at least at some point, and this ceases to sound very good to me.
Was it a "fucking shame" when Rolladen-Schneider installed a bunch of mass balancing lead on the LS-3 control surfaces to guard against aerodynamic flutter? Was it a "fucking shame" when Boeing installed depleted uranium mass balances in the 747 for the same reason?
Installing extra equipment to guard against destructive vibration is standard in aerospace. The only thing unusual about this system is that it's active, rather than passive, which makes it lighter.
It might be plain to you, but it's not plain to me. I could make a wild guess as to what point you're trying to make with your approximate quote of my words, but I don't feel like putting forth the effort to play that game.
Wrong. It was an engine pressure sensor that tripped, due to pressure fluctuations naturally associated with pogo. Luck had nothing to do with it.
The pressure sensor was meant to detect consistent low chamber pressure. It was not intended to detect pogo, and there was no particular reason to expect it to pick up massive pressure fluctuations at 16Hz. It did so because the pogo had also lowered the average pressure, but there's no reason to expect this would happen consistently enough to reliably trip the sensor.
No, you're talking nonsense about "elegant" design versus "kludgey" design. I'm talking about real problems encountered due to engineering problems, shortsightedness, lack of care, or just plain inability to perfectly predict the future.
And I'm going to have to ask you for some direct evidence that all of Saturn's good parts were due to elegant European design and all of the bad parts were due to poor American workers, or else I'm going to have to simply dismiss you as a total loon, not to mention an asshole.
That's kind of funny, because I didn't source from the Wikipedia entry....
The engine was just seconds away from ripping off its mounts, which in turn would have almost certainly led to total destruction of the second stage. That surely counts as "nearly rip the entire rocket to little pieces" in my mind.
As to whether the fuel sensor tripped "falsely" or not is really a semantic debate. Suffice it to say, the condition that the sensor was supposed to detect (consistent low fuel pressure) and the condition that it actually detected (massively oscillating fuel pressure) were not the same, and the reason the computer shut the engine down (consistent low fuel pressure) and the reason the flight was in danger (literally tons of equipment vibrating 3 inches at 16Hz) were not the same. When you detect one problem, take corrective action, and inadvertently save yourself from a completely different disaster, that's what I call luck. As far as I'm aware there's no particular reason to believe that this fuel sensor would have necessarily caused the engine shutdown in time to save the flight had circumstances been slightly different.
Once again proving my point.
I would like some actual evidence that 1600 pounds is abnormally large for vibration suppression. I don't know enough about the field to say whether it is or not, but from everything I've read about it, that number does not strike me as particularly bad. These rockets are big. For comparison, although the total weight of the rocket is not yet determined, this 1600 pound damping system will account for roughly one tenth of one percent of the total weight of just the first stage.
That fallacy does not detract from my overall point. Adding mass, structure, and systems to rockets in order to deal with vibration is a perfectly standard part of large rocket design. I do not know enough about the field to say whether 1600 pounds is a lot, a little, or a typical amount for the size of the rocket. But I have no reason to believe that it's abnormally large.
You are very confused, I'm afraid.
First, no Saturn V stage had six engines. It is therefore nonsensical to talk about "two affected engines" and "the other four engines". The first and second stages both had five engines.
Second, Apollo 13 only had one engine shut down due to pogo. There was an unmanned flight that lost two engines, Apollo 6. This also happened due to totally unanticipated violent pogo. Pieces were seen falling off the rocket at about two minutes after launch due to the intense vibration in the first stage. The second stage then experienced two premature engine shutdowns. The remaining three (not four!) engines burned for about a minute longer to compensate, but this was still not enough, and the third stage also had to burn for about half a minute longer. All of this combined to place the vehicle in the wrong orbit, although this was not a disaster and the mission was still abel to meet many of its goals.
Launch disaster during Apollo 13 was not averted due to an intentional cut-off as you state. A low fuel pressure sensor was tripped by the violent vibration, tricking the flight control computer into thinking that there was a fuel pressure problem and causing it to shut down the engine. This was all by accident. The computer was not programmed to deal with pogo in any way, and this sensor could have easily not tripped if things had gone just a little bit differently.
Saturn V pogo was never really solved, although after the modifications which were in place for Apollo 14 it became much less severe. Apollos 11 and 12 experienced pogo in the same engine as 13, but in a slightly different mode which happened to be much less violent. Significant pogo also happened on the third stage of Apollo 10 and the first stage of Apollo 6. Less violent pogo happened on essentially every flight of the Saturn V run. As a result, the Saturn V was being continually modified and refitted to deal with the different pogo oscillations which presented themselves after each new flight. In fact a fix for the Apollo 13 pogo was already in the pipeline (having been already observed on 11 and 12), but it was deemed too expensive to retrofit to the Apollo 13 launcher.
Calling this hodgepodge of guess-and-check which never really solved the problem "elegant", while calling a nifty, light, active damping system a 'kludge" is simply stupid.
Since resonance depends on the entire structure, not just the component that's generating the vibrations, there's no reason to expect that the experience from designing the shuttle SRBs would carry over to this new vehicle in terms of knowing what vibration to damp ahead of time.
Vibration damping in aircraft is extremely common. Just one example, a controversial use of depleted uranium is as control surface ballast on large airliners, used to modify the structure's resonance to avoid catastrophic flutter at high speeds. There's no real reason to expect any different in a spacecraft. Remember, the thing is still being designed. There may be reason to legitimately worry about such measures after the thing has been designed and tested and is into regular production flight, but criticizing them for a novel approach to fixing a very common problem during the design phase seems rather asinine to me.
I can't find that quote anywhere on the page I linked to. Your quote seems to have come from an Everything2 page, and of course in terms of reliability and authoritativeness, Everything2 makes Wikipedia look like the direct Voice of God.
Saying that the problem of pogo was "solved" is overstating things. There are known techniques for how to deal with it, and generally it doesn't catch people by surprise anymore. But the techniques for dealing with it, surprise surprise, involve installing extra equipment to damp out the vibrations. Just like these guys are doing here on Orion. Just about any large rocket is going to have some mass dedicated to damping vibration, there's no reason to think that Orion should be any different in this respect.
Damn right! Currently, space travel is inherently unsafe. By denying that fact, NASA just wastes more money without helping the problem.
Large rockets really are surprisingly complex given how simple the principle is. I mean, stuff goes into the engine, stuff happens, stuff goes out faster than it went in! How hard could it be?
The real problem is scaling things up. A little plastic water rocket has an untenably low fraction of its weight dedicated to fuel, and a ridiculously poor specific impulse. A rocket that can reach orbit needs much more fuel and much better performance, and this pushes it right up to the bleeding edge of engineering and materials.
(And I'm sure you know this already and your comparison was not serious. I just wanted to elaborate a bit.)
How much do you suppose a "small" damper on the fuel line weighs on a 6.7 million pound rocket? I couldn't find any answers, but it would not surprise me if the Saturn V's "small" pogo suppressors weighed over 1600 pounds in total.