Slashdot Mirror
X Prize and John Carmack
Anonymous Coward writes "ABC News is running a story ostensibly about the X Prize but in reality they only talk about John Carmack and his teams efforts to win the prize (or at least compete). Quote: 'Some people have commented that I am trying very hard to make aerospace like software, and that's the truth," he says. "If we looked at what we do in software, if we could only compile and test our program once a year, we'd never get anything done. But that's the mode of aerospace.' "
Aerospace like software, eh?
"Crap, the rocket is not ready and the deadline for launch is tomorrow!"
"Bah, launch it anyways and we'll release a patch later!"
Burn the land and boil the sea, you can't take the sky from me
"Effectively, I stopped buying Ferraris and turbo-charging them and started building rocket ships," Carmack says.
Yeah, I hate it when I have to put off buying Ferraris.
Trolling is a art,
I read the internet for the articles.
Some people have commented that I am trying very hard to make aerospace like software, and that's the truth
Gives a whole new meaning to "blue screen of death", doesn't it?
Indeed, conventional rocket design is pretty brute-force. Big engine, hunking mechanical control systems with minimal intelligence.
Given the capabilities of modern IT, it makes much more sense to use software as the core of the system, in the same was as software is the core of a device like the Segway, or the stair-climbing robot, or the telescopes that consist of a thousand small mirrors, not one large one.
Rocket science has not changed significantly since 1950, and needs a rethink. I believe this project is a solid approach that has good chances of succeeding, and if so, will redefine the way we conceive of this kind of engineering project in the future.
Ceci n'est pas une signature
If he wins, I wonder if the ships' lifecycle will resemble those of his games?
I can see it allready:
1) Carmack devises a ship that excells in performance, but requires very costly componenets in order to deliver on its full functionality.
2) After a years' worth of excellent operational records, other countries license the engine design and build their own ships off of it
3) 2 years after launch a thriving Spaceship MOD community is launching new ships into space every couple of months....
What about the twinkie? - Dr. Peter Venkman, PHD
Duh.
.sigs are for post^Hers.
The crew hopes to launch the real deal at the White Sands Missile Range in New Mexico.
This, I have known for a while: I have a buddy that works in WSMR's flight safety group. I'm looking forward to it. I'm hoping that I'll get to watch. *crossed fingers*
However, John's attitude of build a little, test a little isn't just a software attitude. It's the old Xplanes or NACA (pre NASA) attitude towards aeronautics.
For those of you that still use usenet, go check out the sci.space.* heirarchy. You'll find that John's a contributor there, but he's empathetically not the first to espouse such views. However, I know of none that have compared it to software development like he did in this interview.
Do you know why the road less traveled by is littered with the bones of the unwary?
Somehow, "my software crashed" lacks that ominous feel that "my software crashed" has...
Read the article for once people instead of knee-jerk reacting to an analogy.
Carmack merely wants to improve the method by which rockets are constructed. He says he starts small and builds his way up, rather than constructing the rocket and control system and then working for six months to work out the problems.
This is a well-known software development technique, and I don't see why it wouldn't be generalizable to other fields. If anything it should inspire more confidence in the creator at least.
For spaceflight, we need people who think like the old school programmers. The ones that actually planned their programs before they wrote them. When it took twenty-four hours (or more) between when you submitted your card deck and when you got your output (or a core dump) you learned to be damned careful with your code. The modern attitude of "keep tweaking it until it compiles; we'll fix the bugs in 2.0" won't wash in spaceflight.
~Idarubicin
The tricky part is that I don't think tests done with small rockets will necessarily give you a good idea of how the big rocket will perform. If that were the case, all we'd really need is to buy a model rocket kit from Wal-Mart and just build it 20x bigger.
You call it a holy war, I call it English. The English language is being eroded gradually by ignorance.
There's a reason for having two words, then and than. It's preferrable to have exact words that aren't dependent upon context. If we just toss out "than", and exclusively use "then", our language will become even less precise.
Some other common mistakes that really suck:
confusing "your" with "you're"
confusing "their" with "they're"
adding unnecessary apostrophes to plural words - Dog's and Cat's...
Just because some people have forgotten or were never taught how to write the language they speak doesn't mean that we should just dumb it down completely. Taken to the extreme, we could just back all the way up to grunts and growls.
.sigs are for post^Hers.
Software developers have learned that the Waterfall model *doesn't work* because it's too slow, expensive, and inflexible. Sound like any space programs you know?
There is a continum between experimentation and analysis. So long as space is dominated by risk-averse govt. bureaucracies, your vision of space exploration will continue to slowly plod along. But remember when the real progress happened: in the 60s, when rockets blew up quite often. The consequence of a failed unmanned flight is only financial, and that means failure can be justified by overall savings.
You probably mean "Burt Rutan", the aircraft designer at Scaled. Dick Rutan is his brother, who piloted the voyager, and was the test pilot for XCOR's EZ-Rocket, but doesn't have anything to do with Space Ship One, the X-Prize vehicle.
I have always maintained that Burt is the odds-on favorite to win the X-Prize, but it isn't over yet. His design requires a pilot on board for all tests, so there is a non-negligable chance that there could be a fatality, which would almost certainly end the effort in the X-Prize timeframe.
John Carmack
I see a lot of skeptics replying, "Carmack is wrong headed, if you screw up a rocket, it crashes, it's not just a compile bug". Many of these comments seem to be suggesting that we should go back to the "old school" style of programmer that thought & planned his code before submitting, instead of relying on the feedback of a compiler.
This is based on the completely false assertion that code will be better / more bug free if you "think harder". It ignores that in the past 30 years of programming we have learned the value of feedback in the software development thought process.
The idea that somehow if I spend more time in a chair planning the solution that the solution will be better if I evolve my way to it is some sort of romantic vision of how solutions to tough problems are actually solved. This could be seen as a version the "prove the code works" vs. "test the code" debate. Or that proofs follow from the axioms. I counter that usually it's a process of some rather messy creativity, trial, and error.
In programming in the large, we have generally learned that "phased" approaches to software development (known as waterfall) tend not to work very well because they de-emphasize the feedback that occurs downstream in the development process. To contrast, an incremental approach enables smaller steps to be delivered , and minimizes the impact of erroneous assumptions discovered downstream in the development.
In programming in the small, development is a form of communication between the computer and the developer. The computer is designed to tell us where we are wrong, we just need to tell it exactly what to expect: for this we have compilers and test cases. Compilers can't catch everything.
Now, this is not suggesting that today's style of "let's see if it compiles!" development is appropriate for aerospace. That is the unfortunate effect of feedback & incremental approaches - it makes programming easier, even for people that shouldn't be doing it. These people "program by accident", and just meander through their code until it does the job, sort of. This is not a reflection of the incremental approach in the hands of an experienced developer that "programs on purpose", that understands what he or she is doing at every step of the way.
Aerospace development isn't "amateur hour", and the incremental approach will just make professionals all the more productive.
-Stu