Just as a bit of advice, if your wife really gets the knitting bug, you might want to look at online yarn suppliers. You can usually get superior prices for nice, high quality stuff.
Oh, and if she's not already a member, send her over to Ravelry. Best knitting resource *ever*.
Hmm... that depends. It's easy to find cheap hobbies: knitting,
ROFL, spoken like a true non-knitter.
Sure, getting started is easy. But then you realize you need half a dozen different straight kneedle sizes, plus some circs and dpns. Oh, and then there's cable kneedles and stitch holders and pins and so forth. And we haven't even gotten to the yarn. Honestly, have you ever actually looked at the price of a ball of yarn? For your average scarf, you're looking at $15-20 on average, and that's for the cheap stuff... if you want real fibres, you're probably looking at nearly double that. For one scarf! And then there's the pattern books (yeah, you can find free patterns online, but the truth of the matter is, the best designers charge, and they charge for a reason)...
Mars may well have had a thicker warmer atmosphere but without the protection of a strong magnetosphere (like earth has) the solar wind 'blew' the atmosphere off of the planet.
Well, that and it has 1/10th the mass of earth, and thus just 1/3rd the gravity with which it can hold down an atmosphere. Taken together, it's hardly surprising that Mars has such a tenuous atmosphere.
My idea is that a good duct tape coder does mostly procedural code
So suddenly people who favour an OO or functional approach can't be "duct tape" coders? Interesting, particularly since a good procedural coder does the exact same thing as a good functional or OO programmer: the break the code down into small, testable, reuseable modules that are highly cohesive and weakly coupled. Whether you do that with procedural modules, objects, or functions is entirely irrelevant (though some paradigms make certain types of design simpler, eg high-order functional reuse, etc).
that is well named
WTF does that have to do with "duct tape" coding? That's just good coding practice in general, whether or not you're over- or under-designing.
strongly typed
So now we can't even use Perl or Python? The duct tape of the programming world? Jebus...
designed by contract
Once again, that's just a good idea in general.
Frankly, looking at your list, they're either just good ideas, or baseless prejudices, nothing more.
Exactly. Many posts will go on about how having a good architecture will make it easier to maintain in the long run, and other such things, but it all comes down to one thing:
TIME
While that's certainly true, let's face it: if people put even a *little* thought into longer-term design and extensibility, software would be far easier to maintain.
Here, a simple example: at our organization, we needed a very simple reporting solution very quickly... like, 3-4 calendar weeks from conception to release to QA. Of course, we initially looked at pre-packaged solutions, but after an initial evaluation, it was clear that we could roll a basic solution in less time than it would take to develop the in-house expertise to use those tools.
Now, with that decision made, we could've easily gone forward and hacked something extremely simplistic very simply. But instead, the first thing we did was step back, consider a few additional use cases, and then we proceeded to design something that, while a bit overly flexible given our initial requirements, we knew would be able to grow as our requirements grew. That done, myself and another developer put together the initial implementation, from zero to completed product, in around three weeks, give or take.
A year later, and that design has held up exceedingly well. We've easily added new features as new requirements have popped up, refactoring and reworking as we go, and never has it felt like we've had to use this "duct-tape" approach. And why? Because we put just a couple days of extra thought into our approach before we marched ahead.
Long story short, the lesson here is simple: over-engineering is bad, yes, but under-engineering is just as bad, if not worse, and it takes very little effort to put together a simple design that will hold up well over time.
As an aside, another interesting point: having more than one person work on a given project is a great way to ensure that your software is at least somewhat modularized, as you're absolutely forced to break the project out into independent modules that can be developed and tested separately. As such, I'd also say that, along with a modicum of up-front design, having at least two people work on any given project is better than having a single, lone gunman hack away until he/she has something that works.
Regressive taxes such as sales tax will hit much harder on the poor. When you have to spend 90% of your income on housing & food you'll pay taxes on at least 90% of you're income with a sales tax.
Well, unless you do the smart thing, and exclude those items from the consumption tax that would overly affect the poor, such as basic groceries, fuel, and so forth.
Now, that's not to say consumption taxes aren't regressive. But they need not be egregiously so.
This is happening because your "admin" is an inexperienced idiot. He is refusing the upgrade because he is afraid that it is going to make him look foolish when he doesn't "know" the new system.
Well, or, to be fair, he may be concerned the cure may be worse than the disease. Upgrading to a new major revision of a core system component has non-trivial risks. Now, if the admin isn't communicating those risks, that's a different problem. But it's not fair to immediately assume that he just doesn't know what he's doing.
Frankly, you sound like somebody who has done a CS course but not written much real world, shipping software.
Think again, bucko.
How many desktop apps does the average person use that are written in Java? The answer is.... none. If you attempt to write a useful desktop app in Java you will soon understand why.
Agreed. Because it's tough to deploy (not everyone has a modern JVM installed), the GUI is non-native and rather ugly (this is fixed in later versions, but alas, Java's legacy lives on), and there's no clean way to install/uninstall apps such that it integrates with the OS.
'course, that doesn't stop Azureus and Eclipse from shipping, but they're certainly in the minority.
Wait... you don't actually think it's because of performance issues, do you? Because it's 2009 now, not 1999. The "Java is slow" meme is rather old.
The previous version was impossible to work on: a combination of terrible performance and weak/loose typing meant that if there was a typo near the end of the algorithm, I might only find out about it 6 hours later. This is clearly impractical.
Absolutely. That's why real software engineers test with small data sets first before firing up a 6 hour run. You *did* test with small data sets first, right?
However its runtime was measured in hours. I rewrote it in C++ and it now completes in around five minutes.
Then you did something wrong. No offense, but if the difference in implementation is that massive, you clearly fucked something up.
And let's say for a minute that, no, you did everything you could and, somehow, Python introduce a 100-times speed penalty. Big deal, write the performant bits in C++ and use Python for everything else. The software development world invented profilers for a reason. Use them!
This is death by a thousand cuts.... it really doesn't matter how smart your algorithms are if every time you want to do some non-trivial thing your gui stops responding for a few seconds.
And that's a completely separate issue. Have you never heard of threads? Or forking?
Oh come on, give haggis a break already! It's really not that bad, and in fact has been described as having "an excellent nutty texture and delicious savoury flavour" (source of source)... 'course, as with all foods, it'll vary based on who made it.
I urge you, give haggis a chance! I actually rather like it! Black pudding, OTOH... *shudder*
The rest of us who live in the nonacademic world will say it's not "capable".
And the rest of us who live in the non-dogmatic world realize that most languages are basically equivalent these days (hence my tongue-in-cheek comment about turing completeness), and that performance is determined primarily by algorithic and architectural decisions, and not the choice of toolkit.
The truth is, when it comes right down to it, Ruby, Perl, Python, C, C++, Lisp... given a well-architected and designed solution will do just fine meeting the requirements of your average application. Now, if you're out on the fringes, doing high performance stuff, or extreme scaling, then yeah, Ruby or Python is probably out... that said, <some large percentage> of the time, even in those cases, you can probably use <insert language here> for most of the application logic, and then drop down into a lower-level language when things get tight.
The point is, being dogmatic about language is a great way to completely miss the fucking point. The real issue is design and architecture. Doing those things right will do far more for improving performance than whether you pick C or Python.
And you *really* believe that was because of the toolset they chose, as opposed to the scaling architecture and software design? Please.
Once again: the *vast* majority of performance is determined at the architecture- and design-level stages of a project. The right choice of algorithm can result in an order of magnitude difference in performance, while fine tuning a hot spot might give you a small multiple, in the very best of cases.
The real problem is that most people don't know how to design for performance and scaling. But that's an entirely separate problem.
Again, unless we're talking an HPC application, I'm calling bullshit. I can't think of a language these days that won't produce sufficient performance for most applications. After all, the vast majority of performance for any application comes from the selection of appropriate algorithms/data structures. And for those few cases where performance needs to be carefully tuned, most languages provide an FFI that can be used to call out to C or some other lower-level language.
Define "direct evidence". There's no "direct evidence" that the wind exists, but you accept it does because you see it's effects. The Bullet Cluster results provide equivalent evidence for the existence of Dark Matter. I mean, you *did* look up the BC results, didn't you?
Similarly, the expansion rate of the universe is accelerating. Period. Of this there is absolutely no doubt, as we actually do have direct evidence demonstrating it. What's causing it? No one knows. So DE is the term that's used as a placeholder.
Either way, we don't have scientists just making shit up and refusing to believe their theories are wrong. We have data which fits certain theories, but not others. For example, the BC results disprove any theory that *doesn't* include some sort of weakly interacting matter (such as pure MOND-style theories).
I can globally scope a variable in JS, let's call it foo. If I am a sloppy programmer and write a function accessing a variable named foo without var'ing it within that function, it will access the global var unless foo is an argument for my function.
Uhh... wtf... that's exactly the way virtually every other language works, as well, include good ol' fashioned C (Perl is another excellent example). I fail to see how this is even remotely surprising.
So i can have a function foo() and a variable foo as properties of the same class and just have to be careful which one i mean in which context. And then, I can always assign the function foo() to the variable foo, and if i still have it declared globally, i have to make sure and use the right context.
So what? Lisp has separate namespaces for various things. So does Perl. Again, this is hardly unique, and it's really not a big deal, IMHO.
yes yes, python has libraries too, and they have this fantastic feature called namespace. check it out sometime. If you have two or more third-party libraries loaded in python it's extremely unlikely that they conflict, because of namespaces. in JS, unless you enable compatibility mode with jQuery, you're up a creek, as you're just going to get whichever meaning of whichever function is defined last in parse order. it's insanity.
Yup, I totally agree... namespaces and modules are both major issues with Javascript. But adding that functionality would be trivial enough... it just hasn't been done yet.
You said the Entrepreneur idea was flawed, because it was based on lying. I merely pointed-out the government-run system has the exact same flaw - they lie. So if you want to reject one on the basis of lying, then you must reject the other for the same cause.
Uh, no I don't.
The point isn't just that the entrepreneur had to lie. It's that, in order to interest business, in order to get the private sector involved in space exploration, he had to lie about profitability. Government has no such requirement. They don't need to tell the public that they're going to find magic moon diamonds because the government has no requirement for profit. Business does.
So, sure, you can get government out of space exploration. Go nuts. My point is that business will *not* step in, as there's precisely zero (0) reason for them to do so. There's absolutely no money in it. Period.
Yeah, and how many people could afford that? Sorry, there's no way you're going to build an interplanetary space travel business out of tourism (*maybe* orbital tourism, ala Bigalow).
- Mining raw materials.
There's nothing on the moon or Mars we can't already get here.
- Services for the tourists/miners like housing, restaurants, and entertainment.
Absolutely brilliant! Too bad you posted anonymous, you deserve the kudos. This is the perfect approach to take... people simply won't take a talk like this seriously unless you give them a good reason to.
People who keep making this argument need to face the fact that there's a reason that private companies aren't going to the moon (or into space in general). It's not because the government is stopping them - if there was money to be made, big companies would route around the government. The problem is that there's no money in it.
The point, here, was to argue against the idea that government should get out of the space industry and let business take over. You followed up with:
There was no money in the internet either until the 1990s. I guess building it before then was a waste of time and money.
This comment seems to clearly defend the idea that business would get into space travel if the government would just let them. Now, if that wasn't your intent, my apologies, but that's certainly how I (and others, it seems) read your response.
If, however, your position is that the government should fund and develop space travel until such time as profitability can be established, then I absolutely agree with you. Much like any number of fundamental technologies, government can take the long view to get the industry established, at which point business can get involved (and possibly take over).
Well that's absurd, of course you do. You should not rely on RAID to the exclusion of other approaches (like proper backups, off-site mirroring, etc), but the whole point of RAID is to provide a first-line defense against catastrophic data loss.
Good try, shifting the discussion onto a topic where you feel you might have a stronger footing, but it's a pretty weak tactic when you can't win an argument.
Once again: In Heinlein's book, the only way the main character could convince business to fund a space venture was to *lie to them*, telling them there were diamonds on the moon when he new full well that there wasn't.
Once again, the lesson is simple: going to the moon is completely, utterly pointless as far as businesses are concerned, as there's nothing there worth getting. Put simply, there is no profit motive, and without that, no sane business will bother getting into the space (despite what your little wet dreams about commercialized space travel might tell you).
Either way, I think it's in our long term interest to do everything we can to develop space flight technologies and to study the effect that space flight has on the human body.
Wait... so you *do* think government should be involved in space flight? Because your original post in this thread suggested precisely the opposite.
Slashdot Mirror
Just as a bit of advice, if your wife really gets the knitting bug, you might want to look at online yarn suppliers. You can usually get superior prices for nice, high quality stuff.
Oh, and if she's not already a member, send her over to Ravelry. Best knitting resource *ever*.
Hmm... that depends. It's easy to find cheap hobbies: knitting,
ROFL, spoken like a true non-knitter.
Sure, getting started is easy. But then you realize you need half a dozen different straight kneedle sizes, plus some circs and dpns. Oh, and then there's cable kneedles and stitch holders and pins and so forth. And we haven't even gotten to the yarn. Honestly, have you ever actually looked at the price of a ball of yarn? For your average scarf, you're looking at $15-20 on average, and that's for the cheap stuff... if you want real fibres, you're probably looking at nearly double that. For one scarf! And then there's the pattern books (yeah, you can find free patterns online, but the truth of the matter is, the best designers charge, and they charge for a reason)...
Knitting cheap... hah!
Mars may well have had a thicker warmer atmosphere but without the protection of a strong magnetosphere (like earth has) the solar wind 'blew' the atmosphere off of the planet.
Well, that and it has 1/10th the mass of earth, and thus just 1/3rd the gravity with which it can hold down an atmosphere. Taken together, it's hardly surprising that Mars has such a tenuous atmosphere.
My idea is that a good duct tape coder does mostly procedural code
So suddenly people who favour an OO or functional approach can't be "duct tape" coders? Interesting, particularly since a good procedural coder does the exact same thing as a good functional or OO programmer: the break the code down into small, testable, reuseable modules that are highly cohesive and weakly coupled. Whether you do that with procedural modules, objects, or functions is entirely irrelevant (though some paradigms make certain types of design simpler, eg high-order functional reuse, etc).
that is well named
WTF does that have to do with "duct tape" coding? That's just good coding practice in general, whether or not you're over- or under-designing.
strongly typed
So now we can't even use Perl or Python? The duct tape of the programming world? Jebus...
designed by contract
Once again, that's just a good idea in general.
Frankly, looking at your list, they're either just good ideas, or baseless prejudices, nothing more.
Exactly. Many posts will go on about how having a good architecture will make it easier to maintain in the long run, and other such things, but it all comes down to one thing:
TIME
While that's certainly true, let's face it: if people put even a *little* thought into longer-term design and extensibility, software would be far easier to maintain.
Here, a simple example: at our organization, we needed a very simple reporting solution very quickly... like, 3-4 calendar weeks from conception to release to QA. Of course, we initially looked at pre-packaged solutions, but after an initial evaluation, it was clear that we could roll a basic solution in less time than it would take to develop the in-house expertise to use those tools.
Now, with that decision made, we could've easily gone forward and hacked something extremely simplistic very simply. But instead, the first thing we did was step back, consider a few additional use cases, and then we proceeded to design something that, while a bit overly flexible given our initial requirements, we knew would be able to grow as our requirements grew. That done, myself and another developer put together the initial implementation, from zero to completed product, in around three weeks, give or take.
A year later, and that design has held up exceedingly well. We've easily added new features as new requirements have popped up, refactoring and reworking as we go, and never has it felt like we've had to use this "duct-tape" approach. And why? Because we put just a couple days of extra thought into our approach before we marched ahead.
Long story short, the lesson here is simple: over-engineering is bad, yes, but under-engineering is just as bad, if not worse, and it takes very little effort to put together a simple design that will hold up well over time.
As an aside, another interesting point: having more than one person work on a given project is a great way to ensure that your software is at least somewhat modularized, as you're absolutely forced to break the project out into independent modules that can be developed and tested separately. As such, I'd also say that, along with a modicum of up-front design, having at least two people work on any given project is better than having a single, lone gunman hack away until he/she has something that works.
Regressive taxes such as sales tax will hit much harder on the poor. When you have to spend 90% of your income on housing & food you'll pay taxes on at least 90% of you're income with a sales tax.
Well, unless you do the smart thing, and exclude those items from the consumption tax that would overly affect the poor, such as basic groceries, fuel, and so forth.
Now, that's not to say consumption taxes aren't regressive. But they need not be egregiously so.
Unless, that is, you don't have erodeproof equipment, in which case you just trash your stuff. Stupid things...
This is happening because your "admin" is an inexperienced idiot. He is refusing the upgrade because he is afraid that it is going to make him look foolish when he doesn't "know" the new system.
Well, or, to be fair, he may be concerned the cure may be worse than the disease. Upgrading to a new major revision of a core system component has non-trivial risks. Now, if the admin isn't communicating those risks, that's a different problem. But it's not fair to immediately assume that he just doesn't know what he's doing.
Heh, fair enough... I just find the idea of eating congealed blood + fillers a little... disturbing. But, hey, I'll eat (nearly) anything once. :)
Frankly, you sound like somebody who has done a CS course but not written much real world, shipping software.
Think again, bucko.
How many desktop apps does the average person use that are written in Java? The answer is .... none. If you attempt to write a useful desktop app in Java you will soon understand why.
Agreed. Because it's tough to deploy (not everyone has a modern JVM installed), the GUI is non-native and rather ugly (this is fixed in later versions, but alas, Java's legacy lives on), and there's no clean way to install/uninstall apps such that it integrates with the OS.
'course, that doesn't stop Azureus and Eclipse from shipping, but they're certainly in the minority.
Wait... you don't actually think it's because of performance issues, do you? Because it's 2009 now, not 1999. The "Java is slow" meme is rather old.
The previous version was impossible to work on: a combination of terrible performance and weak/loose typing meant that if there was a typo near the end of the algorithm, I might only find out about it 6 hours later. This is clearly impractical.
Absolutely. That's why real software engineers test with small data sets first before firing up a 6 hour run. You *did* test with small data sets first, right?
However its runtime was measured in hours. I rewrote it in C++ and it now completes in around five minutes.
Then you did something wrong. No offense, but if the difference in implementation is that massive, you clearly fucked something up.
And let's say for a minute that, no, you did everything you could and, somehow, Python introduce a 100-times speed penalty. Big deal, write the performant bits in C++ and use Python for everything else. The software development world invented profilers for a reason. Use them!
This is death by a thousand cuts .... it really doesn't matter how smart your algorithms are if every time you want to do some non-trivial thing your gui stops responding for a few seconds.
And that's a completely separate issue. Have you never heard of threads? Or forking?
To be fair, there's probably plenty of perfectly fine foods that COE schools turned people off of. :)
Oh come on, give haggis a break already! It's really not that bad, and in fact has been described as having "an excellent nutty texture and delicious savoury flavour" (source of source)... 'course, as with all foods, it'll vary based on who made it.
I urge you, give haggis a chance! I actually rather like it! Black pudding, OTOH... *shudder*
The rest of us who live in the nonacademic world will say it's not "capable".
And the rest of us who live in the non-dogmatic world realize that most languages are basically equivalent these days (hence my tongue-in-cheek comment about turing completeness), and that performance is determined primarily by algorithic and architectural decisions, and not the choice of toolkit.
The truth is, when it comes right down to it, Ruby, Perl, Python, C, C++, Lisp... given a well-architected and designed solution will do just fine meeting the requirements of your average application. Now, if you're out on the fringes, doing high performance stuff, or extreme scaling, then yeah, Ruby or Python is probably out... that said, <some large percentage> of the time, even in those cases, you can probably use <insert language here> for most of the application logic, and then drop down into a lower-level language when things get tight.
The point is, being dogmatic about language is a great way to completely miss the fucking point. The real issue is design and architecture. Doing those things right will do far more for improving performance than whether you pick C or Python.
And you *really* believe that was because of the toolset they chose, as opposed to the scaling architecture and software design? Please.
Once again: the *vast* majority of performance is determined at the architecture- and design-level stages of a project. The right choice of algorithm can result in an order of magnitude difference in performance, while fine tuning a hot spot might give you a small multiple, in the very best of cases.
The real problem is that most people don't know how to design for performance and scaling. But that's an entirely separate problem.
Again, unless we're talking an HPC application, I'm calling bullshit. I can't think of a language these days that won't produce sufficient performance for most applications. After all, the vast majority of performance for any application comes from the selection of appropriate algorithms/data structures. And for those few cases where performance needs to be carefully tuned, most languages provide an FFI that can be used to call out to C or some other lower-level language.
which is now rebuilding that part in a language that is not capable of getting the same result
Unless that language isn't Turing complete, I'm gonna have to call bullshit, here.
We have absolutely no direct evidence of either.
Define "direct evidence". There's no "direct evidence" that the wind exists, but you accept it does because you see it's effects. The Bullet Cluster results provide equivalent evidence for the existence of Dark Matter. I mean, you *did* look up the BC results, didn't you?
Similarly, the expansion rate of the universe is accelerating. Period. Of this there is absolutely no doubt, as we actually do have direct evidence demonstrating it. What's causing it? No one knows. So DE is the term that's used as a placeholder.
Either way, we don't have scientists just making shit up and refusing to believe their theories are wrong. We have data which fits certain theories, but not others. For example, the BC results disprove any theory that *doesn't* include some sort of weakly interacting matter (such as pure MOND-style theories).
I can globally scope a variable in JS, let's call it foo. If I am a sloppy programmer and write a function accessing a variable named foo without var'ing it within that function, it will access the global var unless foo is an argument for my function.
Uhh... wtf... that's exactly the way virtually every other language works, as well, include good ol' fashioned C (Perl is another excellent example). I fail to see how this is even remotely surprising.
So i can have a function foo() and a variable foo as properties of the same class and just have to be careful which one i mean in which context. And then, I can always assign the function foo() to the variable foo, and if i still have it declared globally, i have to make sure and use the right context.
So what? Lisp has separate namespaces for various things. So does Perl. Again, this is hardly unique, and it's really not a big deal, IMHO.
yes yes, python has libraries too, and they have this fantastic feature called namespace. check it out sometime. If you have two or more third-party libraries loaded in python it's extremely unlikely that they conflict, because of namespaces. in JS, unless you enable compatibility mode with jQuery, you're up a creek, as you're just going to get whichever meaning of whichever function is defined last in parse order. it's insanity.
Yup, I totally agree... namespaces and modules are both major issues with Javascript. But adding that functionality would be trivial enough... it just hasn't been done yet.
You said the Entrepreneur idea was flawed, because it was based on lying. I merely pointed-out the government-run system has the exact same flaw - they lie. So if you want to reject one on the basis of lying, then you must reject the other for the same cause.
Uh, no I don't.
The point isn't just that the entrepreneur had to lie. It's that, in order to interest business, in order to get the private sector involved in space exploration, he had to lie about profitability. Government has no such requirement. They don't need to tell the public that they're going to find magic moon diamonds because the government has no requirement for profit. Business does.
So, sure, you can get government out of space exploration. Go nuts. My point is that business will *not* step in, as there's precisely zero (0) reason for them to do so. There's absolutely no money in it. Period.
- Tourism (vacation on the moon or mars!)
Yeah, and how many people could afford that? Sorry, there's no way you're going to build an interplanetary space travel business out of tourism (*maybe* orbital tourism, ala Bigalow).
- Mining raw materials.
There's nothing on the moon or Mars we can't already get here.
- Services for the tourists/miners like housing, restaurants, and entertainment.
ROFL, see #1.
Absolutely brilliant! Too bad you posted anonymous, you deserve the kudos. This is the perfect approach to take... people simply won't take a talk like this seriously unless you give them a good reason to.
The OP said this:
The point, here, was to argue against the idea that government should get out of the space industry and let business take over. You followed up with:
This comment seems to clearly defend the idea that business would get into space travel if the government would just let them. Now, if that wasn't your intent, my apologies, but that's certainly how I (and others, it seems) read your response.
If, however, your position is that the government should fund and develop space travel until such time as profitability can be established, then I absolutely agree with you. Much like any number of fundamental technologies, government can take the long view to get the industry established, at which point business can get involved (and possibly take over).
You don't rely on RAID to avoid data loss
Well that's absurd, of course you do. You should not rely on RAID to the exclusion of other approaches (like proper backups, off-site mirroring, etc), but the whole point of RAID is to provide a first-line defense against catastrophic data loss.
Good try, shifting the discussion onto a topic where you feel you might have a stronger footing, but it's a pretty weak tactic when you can't win an argument.
Once again: In Heinlein's book, the only way the main character could convince business to fund a space venture was to *lie to them*, telling them there were diamonds on the moon when he new full well that there wasn't.
Once again, the lesson is simple: going to the moon is completely, utterly pointless as far as businesses are concerned, as there's nothing there worth getting. Put simply, there is no profit motive, and without that, no sane business will bother getting into the space (despite what your little wet dreams about commercialized space travel might tell you).
Either way, I think it's in our long term interest to do everything we can to develop space flight technologies and to study the effect that space flight has on the human body.
Wait... so you *do* think government should be involved in space flight? Because your original post in this thread suggested precisely the opposite.