So I buy an X-BOX, buy the chip, and then install a linux based bios.... on what amounts to a shitty celeron based machine? I don't know... seems kind of weird.
When the machine first came out it was pretty good hardware for the price, and MS may well have been losing money on every unit sold.
By now though I'd bet that component prices have dropped enough that MS is making a profit on them.
If you think that you can buy one and make MS lose money... you're probably wrong.
Actually, I'd argue that the genericity of lisp's syntax is as much a hindrance as it is a help, emacs parenthesis-matching aside.
The above quoted lisp sexp could mean almost anything or nothing, depending on the context in which that sexp occurs. (Is it data? Is it code? In what evaluation context will it be processed?). Java, C, and most other languages at least give you more distinct contextual tokens to guide you in your understanding.
I like Lisp a lot, but I tend to agree with this point of view. I'm simply more comfortable infix-syntax for simple arithmetic. Prefix syntax is great for function calls -- and I don't really care whether the parens go around the whole thing (Lisp), after the function name and aroudn the arguments (most languages), or aren't there at all (ML/Haskell/Logo). Hell, I even cope happily with postfix function calls (Postscript/Forth/GML).
But when it comes to control structures I really, really prefer a keyword-rich syntax and explicit markers saying just what it is that you've just come to the end of. e.g. if/then/elseif/fi or any of a number of equally reasonable alternatives.
This is why I think that Dylan is currently the best language out there. It does pretty much everything that Common Lisp does, but in a more familiar syntax and with a lot of CLs historical cruft cleaned up. Dylan was designed by a bunch of Common Lisp gurus with the intention of designing the replacement for CL. And I think they suceeded technically.
Dylan currently has two implementations, one open source batch compiler for Unixy systems and one commercial IDE for Windows (with a free personal edition). Both systems compile to fast machine code and can compete with C in all but the most hardcore applications -- certainly far far better than Java or Perl or Python.
Functional Developer is a quite mature system with nice IDE and debugger and lots of libraries.
Gwydion Dylan is a bit less polished, but it's still good enough that a team using it managed 2nd place this year in this year's ICFP 72 hour programming contest.
All previous winners at this contest have been written in either C or else one of the Hindley-Milner statically typed languages (SML/OCaml/Haskell), all of which have very fast execution speeds with a good compiler.
You don't necessarily have to have the best possible langauge to win at ICFP, but you must have no major weaknesses -- you have to have a language and compiler that lets you develop and debug complex code in a very short time, and the end result must run fast. Much like in the real work:-)
Common Lisp and Scheme have never yet won a prize here (though I believe Common Lisp could), and it seems that the large number of Java and Perl and Python entries produced every year simply don't run fast enough to do well. On the other hand, the vast majority of C and C++ programs get eliminated because of bugs (occasionally one gets through!).
Having said all that, the one-line summary is this: if you like the idea of Common Lisp but just can't stand all those parens, take a close look at Dylan instead.
Re:Other program
on
GPS Drawings
·
· Score: 4, Informative
In fact we glider pilots have been doing this for nearly a decade now. The world championships in New Zealand in 1995 were judged using GPS flight records (I was one of the scorers), as has every world champtionship since -- and most local and national contests too.
Here are the results of that contest. In the daily score sheets each flight is linked to the GPS log of that flight, so anyone can analyse the flying style and tactics of world champion pilots. You need a free program to view these files.
Here are some examples of good glider flights made in the USA, such as a 500 km flight at an average speed of 247 km/h (153 mph). Without an engine!
Not sure I completely understand the equivalence here. What perl code would be equivalent to the following Scheme code?
(define (foo n)
(lambda (m) (+ m n)))
(define bar (foo 1))
(define baz (foo 2))
(display (bar 5))
(display (baz 5))
OK, so just remember that I'm arguing the Lisp side of this debate, but since I *do* know my Perl:
sub foo {
my $n = shift;
sub {
my $m = shift;
$m + $n;
}
}
my $bar = foo(1);
my $baz = foo(2);
print &$bar(5);
print &$baz(5);
Ugly, isn't it? And when you start trying to translate real code instead of toy code it just gets uglier and uglier and more and more obscure...
Why do you imagine that I'm not a Perl "coder"? I unfortunately spend *way* more time programming in Perl than in Lisp because Perl has somehow become "cool" while much better languages have irrational prejudices against them.
If you need named parameters, use a hash or hashref.
At the cost of a bit more syntax, and a *whole* lot more inefficiency! Not that the standard "my ($a, $b, $c) = @_" is the model of efficiency!
These are the sorts of things that you can get away with when the atoms of your computation are calls out to Unix programs or pipelines. It just doesn't cut it when you're doing some AI-ish routine that requires millions of calls to functions.
There are even modules [cpan.org] that validate [cpan.org] parameters [cpan.org]
so you can have a call signature.
Yet *more* layers of inefficiency, just to buy you what real languages have built in from the start, usually with *no* runtime overhead!
As far as arrays not being lists, I don't get this one either. In what way are Perl arrays not lists? With functions like pop, push, shift and unshift, and array is treatable exactly as a list.
The point you're missing is that linear lists are just one special case of what Lisp programs build from cons cells. Lisp "lists" can share tails with each other, can be circular, can actually be trees or any other shape, and can have arbitrary stuff efficiently inserted or deleted in the middle.
You just can't fake this with a Perl array. The best you can do is use one Perl array for each node in the List.
It's true that perl is getting more and more of the capabilities of Lisp (as has Python) recently, but while it is becomeing *possible* to do many things, it's rather ugly. Perl doesn't even have a decent syntax for naming the arguments of a function, and Lisp programming is *full* of functions.
Perl datastructures (arrays and hashes) also aren't very well suited to implementing lists, which are likely to turn up in your tasks. Of course you r can *do* it, but it's likely to be more ugly in than in a proper Lisp.
But you before you despair in a maze of twisty little parens, you should realise that there is more than one language in the Lisp family. Common Lisp and Scheme do have lots of parens, but take a look at Dylan. It's a true member of the Lisp family, but looks and feels like a conventional langauge such as C or Pascal.
The link above is to an Open Source command-line compiler for Dylan which workes primarily on Un*x but also has ports to Mac and Windows.
If you happen to be using Windows then also check out Functional Developer, a compiler with a nice IDE and debugger and so forth. It's commercial but the basic edition (whcih is all you'll need) is free.
Dylan is quick to develop in and the programs run fast. A team using Dylan got second place in the recent ICFP Programming Contest.
Every year I see this contest and every year the results are impressive. But I still rarely, rarely see any open source programs of significance written in OCaml, Haskell, etc. Okay, there's a really nice webserver written in Erlang ("eddie"). But with all the frothing about how great these languages are, you'd expect to see the next great program written using one.
While designers of better languages like to spread the word far and wide, it seems that people actually using them often regard their choice of language as a competitive advantage and try to keep it a secret.
An excellent example is described by Paul Graham who got rich by writing what is now Yahoo! Store in Lisp but deliberately kept very quiet about that fact.
So if you notice that I'm suddenly not mentioning Dylan any more then you'll know what is happening:-)
Note, for example, that some of the top OCaml entries in the past were from the designers and implementers of the OCaml language and compiler. This year, the Judge's Prize, for a program written in Erlang, went to a team including the original architect of Erlang, plus the author of the Erlang compiler. So the poster is correct in that this is not a battle of languages, but rather a battle of top notch programmers, each using his or her pet language.
A serious C++ entry, for example, would be from a team headed by Bjarne Strousrup.
There is probably a little validity to this, but I don't think it's the whole story.
First, there are a lot more entries (171 this year) than there are languages used, so not *everyone* can be the designer of their language.
It probably is a slight advantage to be the designer or implementor of the language just because that means that you're probably pretty familar with it. You also get to be able to fix any compiler or library bugs that you find during the contest, but that applies to anyone using an Open Source compiler, not just the original author. We didn't make any changes to the Dylan compiler during this contest but we did note a couple of performance problems in the standard library when it was abused with huge inputs, and we'll be fixing those soon.
It's obviously not *necessary* to be the implementor of the language. The winning team (Haskell Carrots) didn't invent Haskell. The guy who wrote "Beamer" (which looked as if it might win until it failed on some later test files) certainly didn't design C++. And none of the Dylan Hackers invented Dylan. We weren't even the brilliant people at CMU who wrote the compiler we're using -- we're just running as hard as we can to prevent bitrot and make a few small enhancements to it.
For myself, I'm probably far more expert in C++ and Java than I am in Dylan (my current job is taking a 400,000 line Windows program written in C++ by a couple of Russian guys and figuring out how to port it to Mac and Linux) but I know enough Dylan to know that it's the far better language. It's far faster to write in, far simpler than C++ while still offering all the power, and it can generate extremely fast programs.
Some languages do have a reputation for requiring a PhD in order to understand them. I've tried writing programs in OCaml and Haskell and something about them just doesn't sit well with me. And I read the Haskell Carrots' scientific-paper writeup and my head spins about twice per paragraph. Did they really think about all that stuff during the 72 hours? We Dylan Hackers couldn't think of any "literature" to consult for algorithms, and didn't write any proofs -- I guess we were too busy hacking:-)
Another factor is that with a language that doesn't yet have many users it's far more likely that it will be the language designer using it. Who else is there? Languages such as Dylan, Erlang and OCaml are virtually unknown among the general programming community, not because they are bad languages but just because they are new and they don't have Sun's or Microsoft's billions of $$ behind them -- and those companies design and use programming languages as political weapons rather than as the best programming languages they can be.
Even if you still believe that this is really "a battle of top notch programmers" rather than a contest of languages, I think it's still pretty interesting to see what languages top programmers choose to use. Aren't they likely to choose pretty good languages?
I clicked on the Dylan link [pcai.com] in the main post and got to the PCAI Dylan site. The first thing I saw was: "Overview: Dylan is a new object-oriented dynamic language (OODL) being developed by Apple. " Then I had a lok around and found out that Apple pulled the plug on Dylan in late 1995.
I don't know why that particular link was used by whoever submitted the story. There are certainly more appropriate ones.
Dylan started out around 1990 at Apple's Advanced Technology Group, which wanted a single language that would meet all the needs of different groups then using Common Lisp, Smalltalk and C++. Apple worked closely with people at Harlequin (who were selling Lisp and ML development systems and consulting services as well as a popular PostScript RIP) and Carnegie Mellon University (who do major programming language research, and produced the Open Source CMUCL compiler for Lisp).
The three groups agreed on a spec and started implementing compilers for Windows (Harlequin), Macintosh (Apple) and Un*x (CMU).
The subsequent history is sad.
Apple started making big losses in its core business and cancelled projects and products all over: Dylan, Newton, OpenDoc... The Dylan group managed to get out an alpha-quality version and Apple sold it very cheaply ($30) for a while. Very very cool stuff, but still buggy:-( No doubt the source code for it all still exists somewhere within Apple. Maybe it will someday see the light of day.
The CMU "Gwydion" project lost some funding and changed direction a little, and stopped Dylan development. Fortunately, they released their work to the public domain and we "Dylan Hackers" have been able to pick it up and (too slowly:-( ) polish it towards finished form.
Harlequin hit some financial problems and were acquired by someone who wanted their PostScript technology. The language implementations were I think mostly closed down, but the Dylan team managed to get the rights to their work and formed a new company, Functional Objects, to continue it.
Does anyone know if the Dylan language is being actively developed by anyone?
Functional Objects has a very nice Windows IDE. Since getting the rights from Harlequin they have put out a 2.0 (and 2.01) version on Windows and just this month they have started an alpha test program for a Linux command-line compiler.
The open-source Gwydion Dylan is being actively improved, with a significant new release being issued roughly every six months over the last three years (hmm... I'm not even sure it that's deliberate... we tend to do a release shortly after someone checks in some major improvement rather than to a time schedule...). We've taken the original CMU implementation which ran mainly on HPUX and extended it in a number of ways.
It now runs on Linux, LinuxPPC, MacOS 9, MacOS X, BeOS, FreeBSD, Windows and goodness knows what other versions of Unix -- I believe it may have been running on Itanic for quite some time, somewhere deep inside Intel and/or HP...
Improved language conformance. We're just about 100% DRM-compliant now. We work closely with Functional Objects on language extensions and library issues, so that source code is portable.
Performance improvements. The guys at CMU did a wonderful job, but sometimes they just wanted to make things work rather than make them work fast. The generated code is mostly excellent, but the compiler itself takes too long. We've made big advances in this but there's still a way to go.
Interfaces to the real world. We're working on automatically generating interfaces to C code. It's always been possible to write interface functions manually, and people have done it for the Mac toolbox, GTK, OpenGL and other such large libraries of code but it's rather tedious to do it manually. Automatically divining the intent of C header files is not however all that easy a problem:-(
We're very pleased that Gwydion Dylan has recently become a standard package in the FreeBSD and Debian GNU/Linux distributions.
So, in summary: Yes, Dylan is being actively developed, by more than one group.
Just found this interesting analysis [hoult.org] by the captain of the highly-placed Dylan Hackers entry. He uses his own sensible-sounding criteria for rating the entries, obviously somewhat different from the real judges', but not so far off in final results.
Thanks for that.
BTW, after I earlier posted that this shouldn't be taken as a fair comparison between programming languages, this information shows exactly why. The top entry is written in C++, and didn't figure in the "big five" mentioned by the judges of the real contest. In other words, the languages coming out on top change significantly, based on two different, but both reasonable, methods of ranking the entries.
I'd been wondering what happened to "Beamer" myself, but it seems that it crashed&burned on several later input files by using too much VM and going into swapping and never terminating. A pity, because it was obviously a great effort, but it's those little correctness details that make or break an entry in a contest like this.
On the correctness topic, it's interesting that both our programs and the winning Haskell Carrots entry failed on the empty input file and the <PL></PL;> test. In the case of the Haskell program they had a shell script to catch the crash and output a fallback solution (the original input). I refuse to do such things as a matter of principle -- I think you should be able to handle it within your program itself. Both Dylan and Haskell (and OCaml, and others...) are supposed to be "safe" languages that can never segfault. Do we believe our own propaganda, or not?
So, these inputs caused an "array index out of bounds" exception in some part of our code that was making unwarranted assumptions about the input (that it actually contained at least one printable character!), and this exception was safely caught by a handler in the main program.
Before everyone runs out and says "Haskell is the best programming language", as seemed to happen with things like OCaml in the past
OCaml didn't happen to win this year, but there were a number of OCaml programs in the top 20 or 30 (out of 170) entries. It's still a great language and one that I admire a lot (but I still prefer Dylan...)
please bear in mind that the ICFP tasks are somewhat biased toward functional languages
In what way? I don't think that's true. With this year's task, for example, with a suitable amount of brains and understanding of the problem it turns out that you could write an *extremely* good entry quite simply in C -- using a technique called "Dynamic Programming" you could read the input and find its length (call it N), create an NxN array, and write a fairly simple 3-deep loop to iterate over the table to fill it in. I guggest you go and look at Tom Rokicki's excellent page to see how. If he'd got it finished in the 72 hours then he would have won the contest.
Of course that's the thing. He didn't get finished in time, which is the whole point of the contest. Tom was prototyping in Perl and then rewriting into C for speed. With Dylan we didn't need to do that. We could prototype in Dylan without worrying about declarations and types and fiddly things, and then when we found some part was too slow we could stay within Dylan and add a few declarations where they were most needed, rather than having to totally rewrite the program. That's the strength (by design) of Dylan.
It's entirely likely that nuclear-powered rockets are the way to go sometime in the future, but trust me on this: NASA has no intention of ever actually putting this into operation. All they want is to get lots of money to study the idea to death and employ engineers to create PowerPoint presentations.
Let's look at some of the claims in the article:
"Nuclear systems give you a chance to reduce your mass and so your overall costs to orbit," Adams says.
This is a missile-builder talking. He's clearly obsessed with one particular engineering measure of "goodness", which is called "ISP". There has been any amount of research in the last twenty to thirty years that shows that maximizing ISP does not necessarily reduce costs. If NASA's current rockets were operating at the lower end of what you can do with chemical engines then he might be correct, but they are in fact several orders of magnitude off.
Nuclear propulsion could allow single-stage rockets to reach orbit - cutting the need for expendable boosters and allowing what he calls "airline-like" access to space.
Chemical propulsion allows single-stage to orbit, if you do it correctly. In fact, NASA has already built several rockets capable of single-stage to orbit operation, but they just haven't used them that way. The second stage of the Saturn V was one of them. Launched by itself, it would have been capable of making orbit with a small payload. It had the necessary ratio of fuel to total mass.
It would also be lighter and be able to lift a bigger fraction of its starting mass into orbit - perhaps as much as 45 per cent. "With existing systems, it's more like 10 per cent," he says.
This is true, but it DOES NOT MATTER. The 90% of the mass that doesn't make it to orbit is fuel. Fuel is very cheap. The current Space Shuttle uses something like $20 million dollars of fuel to get to orbit (and the vast majority of that is the solid rockets, not the hydrogen). The total cost of a Shuttle mission is more like $1000 million. Even if you could make the fuel free it wouldn't make the shuttle any cheaper.
What is important to cheap access to space is to make the vehicles *totally* reusable, like an airliner, not throw-away like a missile. The Shuttle is partially reusable, but it still throws away a huge amount of itself each flight, and has to be totally refurbished -- a process that takes months. Space flight won't be cheap until you can fly, come back down, fill-her-up, and fly again the next day.
Even if that means that 98% of what you leave the ground with is fuel it doesn't matter until you've got total costs down to well under a tenth of what they are today, and maybe closer to a hundredth.
If you're interested in this then I highly recommend that you go and read what the Space Access Society has been writing about this stuff for more than five years now.
content when the participants can use any language? Why not just a "programming" contest?
Because it is run in conjunction with the International Conference on Functional Programming.
Yes, these are people who believe that functional languages are better, and they fully expect functional languages to win.
But from what I've seen from the past contests, the contest tasks are not inherently biased towards functional languages, and good programmers could well win using C or C++ etc. Or, at least, they could if they could manage to write fast and bug-free code quickly enough in those languages. In fact, some C programs have done quite well in previous years -- they just haven't managed to win.
Maybe that's only because the best C/C++ programmers haven't entered the contest in the past. Or maybe functional languages really are superior.
There's only one way to find out. Gentlemen, start your compilers!
This contest is actually a great counterpoint to things like the Great Programming Language Shootout which was discussed on/. a couple of days ago.
Some people there were complaining that the benchmarks were trivial and artificial and unrealistic, and lamented that it was impossible to get people to write real programs for a benchmark.
I think that's exactly what the ICFP contest is.
They use quite real tasks. Last year the task was to write a ray tracer with a build in programming language for building the scene models and implementing procedural textures. In 72 hours!
The resulting programs were generally several thousand lines of code, and the really interesting thing is that at least for the top entries (and I think for our Dylan entry as well:-), it is actually very interesting and high quality code.
The entries are not judged on the aesthetics of the code itself, but perhaps they should be. Or, perhaps, keping the code clean is the key to allowing a team of people to all work on the same code for 72 hours and complete a quite significant task in that time.
Those lam0rs have gcc-2.96 installed. Do they honestly expect me to install gcc-2.96 to test my program?
You don't have to use their gcc. They actually encourage you to submit a statically-linked binary, rather than build on their machine.
I encourage people to enter this contest. It's fun! Last year I put together a small team using Dylan and we had a ball even if we didn't win.
After being/.ed last year there were around 800 teams registered, but only about 5% of them actually submitted an entry. I think that's a pretty poor showing from the/. crowd.
The big problem of a vertical launch is that 80% of what you lift is fuel, and is spent on the way up. Why not put an
SSTO craft like the Venture Star as a second stage on the back of a big and fast aircraft, a modified 747, 777 or
Beluga for example? Simply fly that aircraft as high and as fast as it goes, maybe stick a rocket on it to gain some
extra height and velocity at its ceiling to launch the second stage.
It's a good idea, but it has problems. You're severely restricted in the size you can make the spacecraft by all sorts of things. You've got to be able to support the fully-fuelled spacecraft on top of an aircraft not originally designed for that, which means extensive modifications. Look at how much trouble NASA had to go to with the Shuttle transporter aircraft, and the Shuttle rides empty. As well as structure, that impacts takeoff speeds and runway lengths. Note also that tthe maximum takeoff weight of aircraft such as the 747 is far more than the maximum landing weight -- if they have to abort early in the flight then they normally have to dump lots of fuel. That's tricky if the weight is in a spacecraft.
There are also operational problems. It takes time and special equipment to mount the spacecraft on top of the carrier aircraft, which means expense. You've also got to be careful not to land the spacecraft anywhere that the carrier can't fly out of.
If you possibly can fly SSTO -- even with a very small payload -- then you're probably better off to do that than to use a piggyback carrier aircraft. See however Len Cormier's Space Van concept, which looks quite interesting.
Other alternatives for a 0th stage include KellySpace's concept for using a 747 to tow a spacecraft (already tested by towing a jet fighter), and Pioneer Rocketplane's concept of the spacecraft and a tanker taking off seperately (possibly from different locations) and doing aerial refuelling.
Both these concepts have advantages over a piggyback arrangement, through reducing the loading on the 0th stage aircraft's structure. I think the Pioneer proposal is the best. It allows a lightly-loaded spacecraft to take off from almost any commercial runway where the payload is, while the tanker takes off from a longer strip possibly hundreds of miles away. The undercarriage of the spacecraft doesn't have to carry the fully fuelled weight (giving a weight saving) and the wings only have to be big enough to carry the fully-fuelled vehicle when travelling at 500+ mph, not when at a 100 - 150 mph takeoff speed, for a huge weight saving.
Pioneer have done detailed design of their intitial aircraft, right down to the point of getting fixed price quotes from the likes of Boeing to actually build it. What they haven't been able to organise is the funding. I don't think anyone seriously doubts that their idea will work, the question is whether an investor will make money in the current environment, especially with Iridium having gone bust and Teledesic cutting back their plans drastically.
My analytical mechanics text claims "it is difficult to construct a rocket which even if it carries no payload, has a
mass ratio r = Minitial/Mfinal as large as 10.
It's difficult, but it was done in the 50's by the Atlas and the Titan II second stage, and again in the 1960's by the Saturn V second stage (which was hardly a delicate thing, having the third stage, the LM and the CM/SM sitting on top of it). With appropriate engines (lower thrust to limit the acceleration with a lower payload, and exhaust bells able to operate at sea-level pressure) any of those would be capable of being used as an SSTO with positive payload. They probably wouldn't be reusable but surely materials science has advanced that much in the last forty years?
Regardless of the material improvements, the multistage is going to be more effiecent.
There's your big mistake right there. Efficiency is useless if it costs too much. If you can build something ten times bigger, using ten times as much fuel, but it works out cheaper than the smaller, more "efficient" rocket then the big inefficient guy is what you want for commercial space. This is a different answer than you get if your interest is military space.
It might seem strange that using more fuel can be cheaper, but look at the figures. The fuel needed to provide the energy to lift a pound of stuff into orbit costs maybe $10. Current launch costs are around $10,000 per pound. Where's it all going? Not to fuel.
The X-33 was a risk, but not nearly such a stunt as the Delta Clipper, which had a marked tenedncy to explode.
The Delta Clipper was an orbital vehicle that was never built. Perhaps you're thinking of the DC-X? That was a subscale demonstrator of vertical landing and low-Mach terminal maneouvering. It was a near-perfect example of what a focussed research and development project *should* be. It tested one thing and one thing only, on a very small budget and short time-scale. And it worked perfectly. The only real thing wrong with it was that research projects should really build two or three, not one. It's only a little more expensive to build several copies than to build one, and it protects against losing the whole project if you crash the vehicle. If a research project is really a *research* project then it must be investigating something that you're not 100% sure you know how to do, which means that if you don't crash a vehicle then you probably weren't pushing hard enough.
The vehicle which burned was the DC-XA. The DC-X safely completed its test program with the Air Force/BMDO, and NASA took it over for a test program of their own devising. They put in a composite tank similar to (but simpler than) the one which is giving so much trouble on X-33 and then a technician forgot to reconnect a hydraulic hose to the landing gear before a flight, resulting in one leg failing to deploy and the vehicle tipping over, cracking the NASA tank and destroying the vehicle in a fire.
Think about vertical landing for a minute. Parachutes and gliders can be made stable much easier than the DC.
But DC-X showed how to do it. That's the whole reason for it to exist.
Vertical landers are also the least efficient of rockets. If it took a Saturn 5 to get to escape velocity, it will take a
Saturn 5 to stop a vertical lander at escape velocity.
This is not correct. All reentering rockets rely on friction with the atmosphere to get rid of 99% of their speed. Parachutes, wings, or rockets are used only for the last 1%. If you're bringing the engines back in the vehicle anyway then a little fuel for landing might weigh less than wings (and the extra fuel to lift them into space), or it might not. You need really detailed design work to find out, not just some halfbaked suposition.
I'm sorry, but there are *so* *many* things wrong in this that I hardly know where to start.
Part of the X33 design is to respond to the many threats NASA faced from private industry, over the past 8 years
or so, that promised to reduce the cost to orbit by a factor of 10
NASA doesn't face threats from industry. NASA's job is to explore space, not to build launchers. As long as no one else builds launchers commercially then NASA has no choice but to build their own, but they are required by US law to use commercial services where available.
The threats go in the opposite direction. As long as NASA can get near unlimited funds to build things that they will then provide (near enough) for free to those they judge to be worthy, no businessman in his right mind would invest in a private launcher. You can't compete with the government, even when they're worse.
They've done
some truly revolutionary work on the linier aero-spike engine
Aerospike engines are probably great, but no one actually knows for sure because none have ever been flown. There was a project called LASRE which was supposed to fly a small linear aerospike attached to an SR-71. This project got rolled into X-33 and killed. The X-33 engine looks quite good, but they've crippled its chances of ever flying by putting it into a vehicle with huge problems. They should have build something conventional and cheap and low-risk to test the aerospike engine in first, just as they should have build a dedicated vehicle to test the new thermal protection system, and a dedicated vehicle to test the aerodynamics and the multi-lobed tanks.
By rolling everything into a single high-risk vehicle they not only probably spent more money than they would have building specialised vehicles (because of the inter-dependencies and constant redesigns needed -- the DC-X cost $60m, the X-33 has eaten $1b already), but they have ensured that if any single part of the vehicle has problems then the other parts can't be tested at all.
The real issue is that many of the private sector solutions to low cost to orbit have either chosen the wrong launch
weight, run out of venture capitol, or just not proven to be as affordable and reliable as a NASA launch.
In what way has this been proven? X-33 doesn't fly at all, let alone affordably and reliably. Shuttle flys barely half a dozen times a year, at a cost of billions of dollars each year. All of the public money was put into one basket. The eggs are broken. For the same money, *all* of the private sector companies could have been funded. Surely one of them would have worked. In fact, probably all of them would have, because they are in general very low risk plans using off the shelf technology.
Wrong launch weight? There are very few large heavy payloads that need to go up in one go. Most of those are military. The shuttles fly twice a year each. A small, cheap, vehicle that could fly every day -- or even twice a week -- would lift in aggregate far more in a year than the shuttle fleet can, and far more flexibly. What is needed right now is a DC-3, not a 747. There is not yet anywhere for the 747 to go, and it will sit half a year waiting for enough cargo to make it worthwhile taking off. That's not good economics.
The other thing that needs to be considered about the X33 is that if you can afford to keep it feuled and on the pad,
it can be looking down on anywhere on the planet in less than one hour! That's revolutionary.
Actually, X33, if it ever flies, won't go anywhere near orbit. It was designed to get all the way from Nevada to Montana, but now looks as if it might only make it to Utah. VentureStar is the hypothetical orbital follow-on to X33, but NASA hmade it clear from the start that LockMart would be expected to finance VentureStar themselves. At this moment LockMart don't appear to even want to put up the money to finish X-33 -- why should they when it has been incredibly sucessful at its primary mission: preventing other companies from developing cheap, reusable, launch vehicles so that LockMart can continue to sell the government expensive throw-away rockets?
Even this "can afford to keep it fuelled and on the pad" shows the wrong attitude. Air New Zealand's B747's spend an average of more than 18 hours a day in the air, year round, not on the ground. (I'm sure it's the same for QANTAS or any other long-distance carrier) An aircraft on the ground is costing you money. An aircraft in the air is making you money. That's the difference between NASA and a for-profit company. NASA looks at the cost side of the equation. A private company looks at the difference between costs and revenues.
*Nowhere* in the article did they mention the complete *success* of NASA in deploying the ISS.
You're going to have to define "success" for me. Looks half a decade late and way over budget to me. No one has died, so far. But no one is living there, either, unlike the working space station the other guys deployed fifteen years ago which has had several hundred different people living in it to date.
NASA is attempting to solve hard problems that take time and money to solve and NASA should be given the
funding and time to succeed.
NASA has had hundreds of billions of dollars since the last moon rocket flew. There is precious little to show for it. Every indication is that NASA would rather work on solving hard problems and never fly than do things the easiest way they can find and actually put people into space.
I think the article is pretty much correct in saying that a major reason for contracts is too lock you into something that looks good new but might not in several years.
But they miss the other major reason for contracts: getting you in the door with subsidised equipment and then trying to make sure that you eventually pay for it. This is of course a major reason for contracts in the cellphone business where you can often get the phone for free if you sign up for three years (that's the sort of deal common here in NZ anyway), but it's also a big factor in internet technology for things such as cable modems, ADSL, and satellite dishes, all of which have hardware that costs a major chunk of change. The early adopters (like me:-) will pay the full cost of hardware upfront, but the average Joe won't. Subsidies and contracts are about the only way to grow into the Joe Sixpack market.
Slashdot Mirror
So I buy an X-BOX, buy the chip, and then install a linux based bios.... on what amounts to a shitty celeron based machine? I don't know... seems kind of weird.
... you're probably wrong.
When the machine first came out it was pretty good hardware for the price, and MS may well have been losing money on every unit sold.
By now though I'd bet that component prices have dropped enough that MS is making a profit on them.
If you think that you can buy one and make MS lose money
Well there's almost no meat in that book yet :-(
It would also be nice if the author and/or editor would learn the difference between "difference" and "dereference" which is wrong thoughout...
www.timecanada.com now redirects you to www.time.com, sans iMac story
Actually, I'd argue that the genericity of lisp's syntax is as much a hindrance as it is a help, emacs parenthesis-matching aside.
:-)
The above quoted lisp sexp could mean almost anything or nothing, depending on the context in which that sexp occurs. (Is it data? Is it code? In what evaluation context will it be processed?). Java, C, and most other languages at least give you more distinct contextual tokens to guide you in your understanding.
I like Lisp a lot, but I tend to agree with this point of view. I'm simply more comfortable infix-syntax for simple arithmetic. Prefix syntax is great for function calls -- and I don't really care whether the parens go around the whole thing (Lisp), after the function name and aroudn the arguments (most languages), or aren't there at all (ML/Haskell/Logo). Hell, I even cope happily with postfix function calls (Postscript/Forth/GML).
But when it comes to control structures I really, really prefer a keyword-rich syntax and explicit markers saying just what it is that you've just come to the end of. e.g. if/then/elseif/fi or any of a number of equally reasonable alternatives.
This is why I think that Dylan is currently the best language out there. It does pretty much everything that Common Lisp does, but in a more familiar syntax and with a lot of CLs historical cruft cleaned up. Dylan was designed by a bunch of Common Lisp gurus with the intention of designing the replacement for CL. And I think they suceeded technically.
Dylan currently has two implementations, one open source batch compiler for Unixy systems and one commercial IDE for Windows (with a free personal edition). Both systems compile to fast machine code and can compete with C in all but the most hardcore applications -- certainly far far better than Java or Perl or Python.
Functional Developer is a quite mature system with nice IDE and debugger and lots of libraries.
Gwydion Dylan is a bit less polished, but it's still good enough that a team using it managed 2nd place this year in this year's ICFP 72 hour programming contest.
All previous winners at this contest have been written in either C or else one of the Hindley-Milner statically typed languages (SML/OCaml/Haskell), all of which have very fast execution speeds with a good compiler.
You don't necessarily have to have the best possible langauge to win at ICFP, but you must have no major weaknesses -- you have to have a language and compiler that lets you develop and debug complex code in a very short time, and the end result must run fast. Much like in the real work
Common Lisp and Scheme have never yet won a prize here (though I believe Common Lisp could), and it seems that the large number of Java and Perl and Python entries produced every year simply don't run fast enough to do well. On the other hand, the vast majority of C and C++ programs get eliminated because of bugs (occasionally one gets through!).
Having said all that, the one-line summary is this: if you like the idea of Common Lisp but just can't stand all those parens, take a close look at Dylan instead.
Here are the results of that contest. In the daily score sheets each flight is linked to the GPS log of that flight, so anyone can analyse the flying style and tactics of world champion pilots. You need a free program to view these files.
Here are some examples of good glider flights made in the USA, such as a 500 km flight at an average speed of 247 km/h (153 mph). Without an engine!
Not sure I completely understand the equivalence here. What perl code would be equivalent to the following Scheme code?
(define (foo n)
(lambda (m) (+ m n)))
(define bar (foo 1))
(define baz (foo 2))
(display (bar 5))
(display (baz 5))
OK, so just remember that I'm arguing the Lisp side of this debate, but since I *do* know my Perl:
sub foo {
my $n = shift;
sub {
my $m = shift;
$m + $n;
}
}
my $bar = foo(1);
my $baz = foo(2);
print &$bar(5);
print &$baz(5);
Ugly, isn't it? And when you start trying to translate real code instead of toy code it just gets uglier and uglier and more and more obscure...
Perl coders use functions *all* the time.
Why do you imagine that I'm not a Perl "coder"? I unfortunately spend *way* more time programming in Perl than in Lisp because Perl has somehow become "cool" while much better languages have irrational prejudices against them.
If you need named parameters, use a hash or hashref.
At the cost of a bit more syntax, and a *whole* lot more inefficiency! Not that the standard "my ($a, $b, $c) = @_" is the model of efficiency!
These are the sorts of things that you can get away with when the atoms of your computation are calls out to Unix programs or pipelines. It just doesn't cut it when you're doing some AI-ish routine that requires millions of calls to functions.
There are even modules [cpan.org] that validate [cpan.org] parameters [cpan.org]
so you can have a call signature.
Yet *more* layers of inefficiency, just to buy you what real languages have built in from the start, usually with *no* runtime overhead!
As far as arrays not being lists, I don't get this one either. In what way are Perl arrays not lists? With functions like pop, push, shift and unshift, and array is treatable exactly as a list.
The point you're missing is that linear lists are just one special case of what Lisp programs build from cons cells. Lisp "lists" can share tails with each other, can be circular, can actually be trees or any other shape, and can have arbitrary stuff efficiently inserted or deleted in the middle.
You just can't fake this with a Perl array. The best you can do is use one Perl array for each node in the List.
It's true that perl is getting more and more of the capabilities of Lisp (as has Python) recently, but while it is becomeing *possible* to do many things, it's rather ugly. Perl doesn't even have a decent syntax for naming the arguments of a function, and Lisp programming is *full* of functions.
Perl datastructures (arrays and hashes) also aren't very well suited to implementing lists, which are likely to turn up in your tasks. Of course you r can *do* it, but it's likely to be more ugly in than in a proper Lisp.
But you before you despair in a maze of twisty little parens, you should realise that there is more than one language in the Lisp family. Common Lisp and Scheme do have lots of parens, but take a look at Dylan. It's a true member of the Lisp family, but looks and feels like a conventional langauge such as C or Pascal.
The link above is to an Open Source command-line compiler for Dylan which workes primarily on Un*x but also has ports to Mac and Windows.
If you happen to be using Windows then also check out Functional Developer, a compiler with a nice IDE and debugger and so forth. It's commercial but the basic edition (whcih is all you'll need) is free.
Dylan is quick to develop in and the programs run fast. A team using Dylan got second place in the recent ICFP Programming Contest.
Every year I see this contest and every year the results are impressive. But I still rarely, rarely see any open source programs of significance written in OCaml, Haskell, etc. Okay, there's a really nice webserver written in Erlang ("eddie"). But with all the frothing about how great these languages are, you'd expect to see the next great program written using one.
:-)
While designers of better languages like to spread the word far and wide, it seems that people actually using them often regard their choice of language as a competitive advantage and try to keep it a secret.
An excellent example is described by Paul Graham who got rich by writing what is now Yahoo! Store in Lisp but deliberately kept very quiet about that fact.
So if you notice that I'm suddenly not mentioning Dylan any more then you'll know what is happening
Note, for example, that some of the top OCaml entries in the past were from the designers and implementers of the OCaml language and compiler. This year, the Judge's Prize, for a program written in Erlang, went to a team including the original architect of Erlang, plus the author of the Erlang compiler. So the poster is correct in that this is not a battle of languages, but rather a battle of top notch programmers, each using his or her pet language.
:-)
A serious C++ entry, for example, would be from a team headed by Bjarne Strousrup.
There is probably a little validity to this, but I don't think it's the whole story.
First, there are a lot more entries (171 this year) than there are languages used, so not *everyone* can be the designer of their language.
It probably is a slight advantage to be the designer or implementor of the language just because that means that you're probably pretty familar with it. You also get to be able to fix any compiler or library bugs that you find during the contest, but that applies to anyone using an Open Source compiler, not just the original author. We didn't make any changes to the Dylan compiler during this contest but we did note a couple of performance problems in the standard library when it was abused with huge inputs, and we'll be fixing those soon.
It's obviously not *necessary* to be the implementor of the language. The winning team (Haskell Carrots) didn't invent Haskell. The guy who wrote "Beamer" (which looked as if it might win until it failed on some later test files) certainly didn't design C++. And none of the Dylan Hackers invented Dylan. We weren't even the brilliant people at CMU who wrote the compiler we're using -- we're just running as hard as we can to prevent bitrot and make a few small enhancements to it.
For myself, I'm probably far more expert in C++ and Java than I am in Dylan (my current job is taking a 400,000 line Windows program written in C++ by a couple of Russian guys and figuring out how to port it to Mac and Linux) but I know enough Dylan to know that it's the far better language. It's far faster to write in, far simpler than C++ while still offering all the power, and it can generate extremely fast programs.
Some languages do have a reputation for requiring a PhD in order to understand them. I've tried writing programs in OCaml and Haskell and something about them just doesn't sit well with me. And I read the Haskell Carrots' scientific-paper writeup and my head spins about twice per paragraph. Did they really think about all that stuff during the 72 hours? We Dylan Hackers couldn't think of any "literature" to consult for algorithms, and didn't write any proofs -- I guess we were too busy hacking
Another factor is that with a language that doesn't yet have many users it's far more likely that it will be the language designer using it. Who else is there? Languages such as Dylan, Erlang and OCaml are virtually unknown among the general programming community, not because they are bad languages but just because they are new and they don't have Sun's or Microsoft's billions of $$ behind them -- and those companies design and use programming languages as political weapons rather than as the best programming languages they can be.
Even if you still believe that this is really "a battle of top notch programmers" rather than a contest of languages, I think it's still pretty interesting to see what languages top programmers choose to use. Aren't they likely to choose pretty good languages?
I don't know why that particular link was used by whoever submitted the story. There are certainly more appropriate ones.
Dylan started out around 1990 at Apple's Advanced Technology Group, which wanted a single language that would meet all the needs of different groups then using Common Lisp, Smalltalk and C++. Apple worked closely with people at Harlequin (who were selling Lisp and ML development systems and consulting services as well as a popular PostScript RIP) and Carnegie Mellon University (who do major programming language research, and produced the Open Source CMUCL compiler for Lisp).
The three groups agreed on a spec and started implementing compilers for Windows (Harlequin), Macintosh (Apple) and Un*x (CMU).
The subsequent history is sad.
Apple started making big losses in its core business and cancelled projects and products all over: Dylan, Newton, OpenDoc... The Dylan group managed to get out an alpha-quality version and Apple sold it very cheaply ($30) for a while. Very very cool stuff, but still buggy
The CMU "Gwydion" project lost some funding and changed direction a little, and stopped Dylan development. Fortunately, they released their work to the public domain and we "Dylan Hackers" have been able to pick it up and (too slowly
Harlequin hit some financial problems and were acquired by someone who wanted their PostScript technology. The language implementations were I think mostly closed down, but the Dylan team managed to get the rights to their work and formed a new company, Functional Objects, to continue it.
Does anyone know if the Dylan language is being actively developed by anyone?
Functional Objects has a very nice Windows IDE. Since getting the rights from Harlequin they have put out a 2.0 (and 2.01) version on Windows and just this month they have started an alpha test program for a Linux command-line compiler.
The open-source Gwydion Dylan is being actively improved, with a significant new release being issued roughly every six months over the last three years (hmm
We're very pleased that Gwydion Dylan has recently become a standard package in the FreeBSD and Debian GNU/Linux distributions.
So, in summary: Yes, Dylan is being actively developed, by more than one group.
Just found this interesting analysis [hoult.org] by the captain of the highly-placed Dylan Hackers entry. He uses his own sensible-sounding criteria for rating the entries, obviously somewhat different from the real judges', but not so far off in final results.
Thanks for that.
BTW, after I earlier posted that this shouldn't be taken as a fair comparison between programming languages, this information shows exactly why. The top entry is written in C++, and didn't figure in the "big five" mentioned by the judges of the real contest. In other words, the languages coming out on top change significantly, based on two different, but both reasonable, methods of ranking the entries.
I'd been wondering what happened to "Beamer" myself, but it seems that it crashed&burned on several later input files by using too much VM and going into swapping and never terminating. A pity, because it was obviously a great effort, but it's those little correctness details that make or break an entry in a contest like this.
On the correctness topic, it's interesting that both our programs and the winning Haskell Carrots entry failed on the empty input file and the <PL></PL;> test. In the case of the Haskell program they had a shell script to catch the crash and output a fallback solution (the original input). I refuse to do such things as a matter of principle -- I think you should be able to handle it within your program itself. Both Dylan and Haskell (and OCaml, and others...) are supposed to be "safe" languages that can never segfault. Do we believe our own propaganda, or not?
So, these inputs caused an "array index out of bounds" exception in some part of our code that was making unwarranted assumptions about the input (that it actually contained at least one printable character!), and this exception was safely caught by a handler in the main program.
OCaml didn't happen to win this year, but there were a number of OCaml programs in the top 20 or 30 (out of 170) entries. It's still a great language and one that I admire a lot (but I still prefer Dylan...)
please bear in mind that the ICFP tasks are somewhat biased toward functional languages
In what way? I don't think that's true. With this year's task, for example, with a suitable amount of brains and understanding of the problem it turns out that you could write an *extremely* good entry quite simply in C -- using a technique called "Dynamic Programming" you could read the input and find its length (call it N), create an NxN array, and write a fairly simple 3-deep loop to iterate over the table to fill it in. I guggest you go and look at Tom Rokicki's excellent page to see how. If he'd got it finished in the 72 hours then he would have won the contest.
Of course that's the thing. He didn't get finished in time, which is the whole point of the contest. Tom was prototyping in Perl and then rewriting into C for speed. With Dylan we didn't need to do that. We could prototype in Dylan without worrying about declarations and types and fiddly things, and then when we found some part was too slow we could stay within Dylan and add a few declarations where they were most needed, rather than having to totally rewrite the program. That's the strength (by design) of Dylan.
Let's look at some of the claims in the article:
"Nuclear systems give you a chance to reduce your mass and so your overall costs to orbit," Adams says.
This is a missile-builder talking. He's clearly obsessed with one particular engineering measure of "goodness", which is called "ISP". There has been any amount of research in the last twenty to thirty years that shows that maximizing ISP does not necessarily reduce costs. If NASA's current rockets were operating at the lower end of what you can do with chemical engines then he might be correct, but they are in fact several orders of magnitude off.
Nuclear propulsion could allow single-stage rockets to reach orbit - cutting the need for expendable boosters and allowing what he calls "airline-like" access to space.
Chemical propulsion allows single-stage to orbit, if you do it correctly. In fact, NASA has already built several rockets capable of single-stage to orbit operation, but they just haven't used them that way. The second stage of the Saturn V was one of them. Launched by itself, it would have been capable of making orbit with a small payload. It had the necessary ratio of fuel to total mass.
It would also be lighter and be able to lift a bigger fraction of its starting mass into orbit - perhaps as much as 45 per cent. "With existing systems, it's more like 10 per cent," he says.
This is true, but it DOES NOT MATTER. The 90% of the mass that doesn't make it to orbit is fuel. Fuel is very cheap. The current Space Shuttle uses something like $20 million dollars of fuel to get to orbit (and the vast majority of that is the solid rockets, not the hydrogen). The total cost of a Shuttle mission is more like $1000 million. Even if you could make the fuel free it wouldn't make the shuttle any cheaper.
What is important to cheap access to space is to make the vehicles *totally* reusable, like an airliner, not throw-away like a missile. The Shuttle is partially reusable, but it still throws away a huge amount of itself each flight, and has to be totally refurbished -- a process that takes months. Space flight won't be cheap until you can fly, come back down, fill-her-up, and fly again the next day.
Even if that means that 98% of what you leave the ground with is fuel it doesn't matter until you've got total costs down to well under a tenth of what they are today, and maybe closer to a hundredth.
If you're interested in this then I highly recommend that you go and read what the Space Access Society has been writing about this stuff for more than five years now.
Because it is run in conjunction with the International Conference on Functional Programming.
Yes, these are people who believe that functional languages are better, and they fully expect functional languages to win.
But from what I've seen from the past contests, the contest tasks are not inherently biased towards functional languages, and good programmers could well win using C or C++ etc. Or, at least, they could if they could manage to write fast and bug-free code quickly enough in those languages. In fact, some C programs have done quite well in previous years -- they just haven't managed to win.
Maybe that's only because the best C/C++ programmers haven't entered the contest in the past. Or maybe functional languages really are superior.
There's only one way to find out. Gentlemen, start your compilers!
Some people there were complaining that the benchmarks were trivial and artificial and unrealistic, and lamented that it was impossible to get people to write real programs for a benchmark.
I think that's exactly what the ICFP contest is.
They use quite real tasks. Last year the task was to write a ray tracer with a build in programming language for building the scene models and implementing procedural textures. In 72 hours!
The resulting programs were generally several thousand lines of code, and the really interesting thing is that at least for the top entries (and I think for our Dylan entry as well :-), it is actually very interesting and high quality code.
The entries are not judged on the aesthetics of the code itself, but perhaps they should be. Or, perhaps, keping the code clean is the key to allowing a team of people to all work on the same code for 72 hours and complete a quite significant task in that time.
You don't have to use their gcc. They actually encourage you to submit a statically-linked binary, rather than build on their machine.
I encourage people to enter this contest. It's fun! Last year I put together a small team using Dylan and we had a ball even if we didn't win.
After being /.ed last year there were around 800 teams registered, but only about 5% of them actually submitted an entry. I think that's a pretty poor showing from the /. crowd.
Point of fact: at 300,000, there are more Maori now than there were before the European Devils arrived.
It's a good idea, but it has problems. You're severely restricted in the size you can make the spacecraft by all sorts of things. You've got to be able to support the fully-fuelled spacecraft on top of an aircraft not originally designed for that, which means extensive modifications. Look at how much trouble NASA had to go to with the Shuttle transporter aircraft, and the Shuttle rides empty. As well as structure, that impacts takeoff speeds and runway lengths. Note also that tthe maximum takeoff weight of aircraft such as the 747 is far more than the maximum landing weight -- if they have to abort early in the flight then they normally have to dump lots of fuel. That's tricky if the weight is in a spacecraft.
There are also operational problems. It takes time and special equipment to mount the spacecraft on top of the carrier aircraft, which means expense. You've also got to be careful not to land the spacecraft anywhere that the carrier can't fly out of.
If you possibly can fly SSTO -- even with a very small payload -- then you're probably better off to do that than to use a piggyback carrier aircraft. See however Len Cormier's Space Van concept, which looks quite interesting.
Other alternatives for a 0th stage include KellySpace's concept for using a 747 to tow a spacecraft (already tested by towing a jet fighter), and Pioneer Rocketplane's concept of the spacecraft and a tanker taking off seperately (possibly from different locations) and doing aerial refuelling.
Both these concepts have advantages over a piggyback arrangement, through reducing the loading on the 0th stage aircraft's structure. I think the Pioneer proposal is the best. It allows a lightly-loaded spacecraft to take off from almost any commercial runway where the payload is, while the tanker takes off from a longer strip possibly hundreds of miles away. The undercarriage of the spacecraft doesn't have to carry the fully fuelled weight (giving a weight saving) and the wings only have to be big enough to carry the fully-fuelled vehicle when travelling at 500+ mph, not when at a 100 - 150 mph takeoff speed, for a huge weight saving.
Pioneer have done detailed design of their intitial aircraft, right down to the point of getting fixed price quotes from the likes of Boeing to actually build it. What they haven't been able to organise is the funding. I don't think anyone seriously doubts that their idea will work, the question is whether an investor will make money in the current environment, especially with Iridium having gone bust and Teledesic cutting back their plans drastically.
It's difficult, but it was done in the 50's by the Atlas and the Titan II second stage, and again in the 1960's by the Saturn V second stage (which was hardly a delicate thing, having the third stage, the LM and the CM/SM sitting on top of it). With appropriate engines (lower thrust to limit the acceleration with a lower payload, and exhaust bells able to operate at sea-level pressure) any of those would be capable of being used as an SSTO with positive payload. They probably wouldn't be reusable but surely materials science has advanced that much in the last forty years?
Regardless of the material improvements, the multistage is going to be more effiecent.
There's your big mistake right there. Efficiency is useless if it costs too much. If you can build something ten times bigger, using ten times as much fuel, but it works out cheaper than the smaller, more "efficient" rocket then the big inefficient guy is what you want for commercial space. This is a different answer than you get if your interest is military space.
It might seem strange that using more fuel can be cheaper, but look at the figures. The fuel needed to provide the energy to lift a pound of stuff into orbit costs maybe $10. Current launch costs are around $10,000 per pound. Where's it all going? Not to fuel.
The Delta Clipper was an orbital vehicle that was never built. Perhaps you're thinking of the DC-X? That was a subscale demonstrator of vertical landing and low-Mach terminal maneouvering. It was a near-perfect example of what a focussed research and development project *should* be. It tested one thing and one thing only, on a very small budget and short time-scale. And it worked perfectly. The only real thing wrong with it was that research projects should really build two or three, not one. It's only a little more expensive to build several copies than to build one, and it protects against losing the whole project if you crash the vehicle. If a research project is really a *research* project then it must be investigating something that you're not 100% sure you know how to do, which means that if you don't crash a vehicle then you probably weren't pushing hard enough.
The vehicle which burned was the DC-XA. The DC-X safely completed its test program with the Air Force/BMDO, and NASA took it over for a test program of their own devising. They put in a composite tank similar to (but simpler than) the one which is giving so much trouble on X-33 and then a technician forgot to reconnect a hydraulic hose to the landing gear before a flight, resulting in one leg failing to deploy and the vehicle tipping over, cracking the NASA tank and destroying the vehicle in a fire.
Think about vertical landing for a minute. Parachutes and gliders can be made stable much easier than the DC.
But DC-X showed how to do it. That's the whole reason for it to exist.
Vertical landers are also the least efficient of rockets. If it took a Saturn 5 to get to escape velocity, it will take a Saturn 5 to stop a vertical lander at escape velocity.
This is not correct. All reentering rockets rely on friction with the atmosphere to get rid of 99% of their speed. Parachutes, wings, or rockets are used only for the last 1%. If you're bringing the engines back in the vehicle anyway then a little fuel for landing might weigh less than wings (and the extra fuel to lift them into space), or it might not. You need really detailed design work to find out, not just some halfbaked suposition.
Yes, quite intelligent and well-informed, it appears, restoring my faith in /. moderation.
The NASP was the X-30, not the X-33.
Part of the X33 design is to respond to the many threats NASA faced from private industry, over the past 8 years or so, that promised to reduce the cost to orbit by a factor of 10
NASA doesn't face threats from industry. NASA's job is to explore space, not to build launchers. As long as no one else builds launchers commercially then NASA has no choice but to build their own, but they are required by US law to use commercial services where available.
The threats go in the opposite direction. As long as NASA can get near unlimited funds to build things that they will then provide (near enough) for free to those they judge to be worthy, no businessman in his right mind would invest in a private launcher. You can't compete with the government, even when they're worse.
They've done some truly revolutionary work on the linier aero-spike engine
Aerospike engines are probably great, but no one actually knows for sure because none have ever been flown. There was a project called LASRE which was supposed to fly a small linear aerospike attached to an SR-71. This project got rolled into X-33 and killed. The X-33 engine looks quite good, but they've crippled its chances of ever flying by putting it into a vehicle with huge problems. They should have build something conventional and cheap and low-risk to test the aerospike engine in first, just as they should have build a dedicated vehicle to test the new thermal protection system, and a dedicated vehicle to test the aerodynamics and the multi-lobed tanks.
By rolling everything into a single high-risk vehicle they not only probably spent more money than they would have building specialised vehicles (because of the inter-dependencies and constant redesigns needed -- the DC-X cost $60m, the X-33 has eaten $1b already), but they have ensured that if any single part of the vehicle has problems then the other parts can't be tested at all.
The real issue is that many of the private sector solutions to low cost to orbit have either chosen the wrong launch weight, run out of venture capitol, or just not proven to be as affordable and reliable as a NASA launch.
In what way has this been proven? X-33 doesn't fly at all, let alone affordably and reliably. Shuttle flys barely half a dozen times a year, at a cost of billions of dollars each year. All of the public money was put into one basket. The eggs are broken. For the same money, *all* of the private sector companies could have been funded. Surely one of them would have worked. In fact, probably all of them would have, because they are in general very low risk plans using off the shelf technology.
Wrong launch weight? There are very few large heavy payloads that need to go up in one go. Most of those are military. The shuttles fly twice a year each. A small, cheap, vehicle that could fly every day -- or even twice a week -- would lift in aggregate far more in a year than the shuttle fleet can, and far more flexibly. What is needed right now is a DC-3, not a 747. There is not yet anywhere for the 747 to go, and it will sit half a year waiting for enough cargo to make it worthwhile taking off. That's not good economics.
The other thing that needs to be considered about the X33 is that if you can afford to keep it feuled and on the pad, it can be looking down on anywhere on the planet in less than one hour! That's revolutionary.
Actually, X33, if it ever flies, won't go anywhere near orbit. It was designed to get all the way from Nevada to Montana, but now looks as if it might only make it to Utah. VentureStar is the hypothetical orbital follow-on to X33, but NASA hmade it clear from the start that LockMart would be expected to finance VentureStar themselves. At this moment LockMart don't appear to even want to put up the money to finish X-33 -- why should they when it has been incredibly sucessful at its primary mission: preventing other companies from developing cheap, reusable, launch vehicles so that LockMart can continue to sell the government expensive throw-away rockets?
Even this "can afford to keep it fuelled and on the pad" shows the wrong attitude. Air New Zealand's B747's spend an average of more than 18 hours a day in the air, year round, not on the ground. (I'm sure it's the same for QANTAS or any other long-distance carrier) An aircraft on the ground is costing you money. An aircraft in the air is making you money. That's the difference between NASA and a for-profit company. NASA looks at the cost side of the equation. A private company looks at the difference between costs and revenues.
*Nowhere* in the article did they mention the complete *success* of NASA in deploying the ISS.
You're going to have to define "success" for me. Looks half a decade late and way over budget to me. No one has died, so far. But no one is living there, either, unlike the working space station the other guys deployed fifteen years ago which has had several hundred different people living in it to date.
NASA is attempting to solve hard problems that take time and money to solve and NASA should be given the funding and time to succeed.
NASA has had hundreds of billions of dollars since the last moon rocket flew. There is precious little to show for it. Every indication is that NASA would rather work on solving hard problems and never fly than do things the easiest way they can find and actually put people into space.
But they miss the other major reason for contracts: getting you in the door with subsidised equipment and then trying to make sure that you eventually pay for it. This is of course a major reason for contracts in the cellphone business where you can often get the phone for free if you sign up for three years (that's the sort of deal common here in NZ anyway), but it's also a big factor in internet technology for things such as cable modems, ADSL, and satellite dishes, all of which have hardware that costs a major chunk of change. The early adopters (like me :-) will pay the full cost of hardware upfront, but the average Joe won't. Subsidies and contracts are about the only way to grow into the Joe Sixpack market.