Nah, I think the goal can be a bit broader than just that.

The larger goal is getting people and cargo to and from space cheaply, reliably, and downright commonplace. Getting the private sector involved is almost certainly a key to making that happen.

In the short term it might have a lot to do with low-orbit tourism and profits and losses, but that's ok. That's part of what it takes to get the money spent, that's part of what will lead to making it economically feasible, it's what will (hopefully) lead to greater interest by the public, and a lot of the technology and discoveries that make it all work well will move things forward towards the big picture goal.

Taking the reference to the Empire State Building: you can look at the construction of that building purely in terms of the economics and the time period or whatever. But regardless of whatever motives caused it to be built, it pushed the envelope of large scale construction and now, nearly a century later, a new building of that size is hardly noteworthy because now there are structures over twice as tall. Similarly, I hope companies like Virgin Galactic do the same thing for the space travel industry, regardless of what their publicly stated goals are.

Also, I'm betting that many (most?) of the people involved aren't putting their lives on the line just because of a paycheck, but because they really want to advance the space travel industry.

This whole field is interesting to me and so I'm glad to see research being done. That said, for me the place where I most want driverless cars is on the open highway. The problem with driving on the open highway is that it's just complex enough to require some of your attention, but not interesting enough to keep you mentally engaged, so it's really easy to get bored or sleepy or just plain distracted. In other words, it's a perfect candidate for automation.

In an urban environment I have no problem staying focused /because of/ all the chaos these researchers are dealing with. It seems like all of the times I've come close to a serious auto accident have been on freeway / high speed roads and have let myself lose focus. In urban environments I've rarely come close to a major accident both because I'm so much more focused on driving and because the speeds are significantly lower.

Long term I hope we get to driverless cars in all environments, but I hope that sometime sooner we can get driverless cars on the freeway that switch over to human control as you approach the off-ramp or enter a more urban area.

Weird - works on my Note 2. Playback stutters some so far but not too bad.

Maybe, but I read it it slightly differently. 'Disproportionate' means 'too large or too small in comparison with something else'.

So I took it to mean that someone who got two percentage points higher on their test ended up being promoted at a much higher rate than would generally be expected for that small of a difference in scores.

As a made up example, if you scored two percentage points higher on your final than me, and all else equal, as a result over the course of your career that single test caused you to get promoted at a rate that was double the rate at which I got promoted, then one could realistically say that the rate of promotion is disproportionately higher than expected because in many cases a two percentage point difference would not be statistically significant while a doubling would be. The two are so different that it doesn't seem unreasonable to call them disproportionate. To be clear, those aren't the numbers from the article, but the article was just suggesting that there was that type of mismatch - small test score difference leading to a large, long term difference.

And that long term effect is key because it magnifies the issue: a very small difference in a score on one test you take early in your career has large ramifications for potentially decades? That creates a large incentive to cheat. And that's just it - I'm not arguing what's fair or unfair or what's right or wrong in this scenario, just saying that it sounds like there were some pretty big incentives to cheat.

L3's blog still has a summary blurb, but the link to the actual post gets a 404 - did they take it down or did they just link it wrong? Anybody have a cached copy?

No thanks. The watch is just another device on the long list of separate things that got consolidated into my phone (mp3 player, camera, calendar, ebook reader, flashlight, GPS, alarm clock, etc.). As with all those other things, the version on my phone is so far into the "good enough" range that having a separate device for the same functionality just doesn't offer much appeal.

Too many of the smart watches seem to try to move functionality back off the phone, which seems pretty pointless (until at such time as it could completely replace everything on my phone, which case I might be interested. You know, some sort of holographic magic screen that replaces the need for a large physical screen, or maybe interfaces with some futuristic contact lenses that project a HUD that only I can see).

Anyway, that seems to be the core problem - these watches just don't do anything worthwhile compared to what I'll already be carrying with me. I don't want a watch as a status symbol, I don't need a watch to just tell time, and I don't need/want a watch to do a bunch of stuff my phone already does.

An exception would be for highly niche purposes. I have a kid with type I diabetes. If he could have a watch that could monitor is blood sugar levels and dispense insulin, I'd buy it.

Actually I /do/ get it. I'm really quite familiar with how Python works, as well as how C, assembly, and machine language work. I'm not debating one is the other, nor that VM vs not is better than the other. What I *am* saying, however, is that the thing you're talking about is not the same thing as a processor supporting such and such a language natively. "Natively" means something specific, and what you're talking about isn't it.

I'm not saying that Python does or doesn't require a runtime, a virtual machine, etc. (even though there are some versions that don't). What I /am/ saying is that I don't know of any processor that runs C natively. Make up a different term for the concept you're talking about, because "natively" already has a meaning in this context, and how C works is definitely not native.

So, by your definition, most modern machines run Pascal natively? All I'm pointing out is that this is a pretty atypical use of the term "natively". Native code, for example, refers to code in its binary (processor-specific) form. No processor that I'm aware of knows how to run C code natively - it has to first be taken from its portable format and translated into native (assembly and then machine) code. It's not a matter of when or how that translation happens; processors simply don't speak C.

The abstraction of a virtual machine is definitely interesting, it just has nothing to do with whether or not processors can run C natively.

I haven't kept up on what the latest and greatest things are in this area, but last time I checked Shedskin seemed the most mature and had a relatively small set of restrictions (in most cases, converting Python to a statically-compiled language involves either giving up some of Python's dynamicness to make it "fit" into the more static language or adding some sort of layer on top of the static language to support more dynamic functionality - Python is strongly but dynamically typed).

Anyway, py2c and Nuitka both seem to be in the same space as Shedskin but I haven't used either.

Cython bills itself as an "optimizing static compiler" for Python, although I think it's geared more towards writing Python extensions in C as opposed to trying to convert your entire program away from Python (i.e. it's a good fit if you're writing in Python but want to statically compile some performance critical parts of your app in C, or if you are calling some C library and don't want to use ctypes or cffi).

I believe that for awhile rpython (from the pypy project) optionally targeted the LLVM; not sure if that ever went anywhere.

The above are just the ones I've heard about; don't know if there are others.

Agree to disagree on what he's implying - the context was talking about C and Python and mentioning that he's no familiar with hardware that runs Python natively. If he wasn't implying that C on other hand does run natively, then the comment seems to have no meaning.

And yes, there /are/ versions of Python that compile to native code, but most people use the interpreter flavors as they give the most flexibility or have the fewest restrictions. Similarly, there are interpreted versions of C, but most people use the compiled flavor.

JIT-compiled languages sometimes in fact exceed statically-compiled languages as far as performance goes, but in general don't yet.

My point(s)? To recap: hardware doesn't run C natively. Python is not a language-of-the-day or some passing fad. The fact that the main version of Python is written in C is mostly irrelevant (as in, I'm still not sure why it was mentioned and it does not mean Python is not useful or not worth learning). Raw performance of a language is rarely as important as developer productivity, and languages like Python regularly yield higher developer productivity than lower level languages like C. More and more people moved to C from assembly as the benefits exceeded the costs more and more, but assembly of course didn't go away. More and more people move to higher level languages like Python from C as the benefits exceed the costs more and more, but C of course won't go away. The trend will likely continue, with lower level languages becoming more and more niche because progressively powerful and higher level languages will continue to provide benefits that outweigh the costs, while the lower level languages will not warrant as much use because of the relatively lower productivity.

I wasn't replying to the OP, nor (AFAICT) were any Python developers claiming C is inherently flawed. I was responding to the "Python is just Perl for the hipsters" nonsense as well as the weird statement that implied hardware ran C natively.

*Some* versions of Python are written in C, but not all of them. In fact, the version you're referring to is officially known as CPython to differentiate it from the others.

Claiming that hardware can run C natively is quite a reach. Your definition of what it means to run a language natively is so broad that it encompasses a large number of programming languages (if not all of them). Even before abstractions like LLVM were introduced, going from C to hardware involved translating to assembly and then machine language - multiple steps.

And "language-of-the-day"... really? Python is over 20 years old. I think it's beyond the passing fad stage.

Finally, it's not about getting rid of C, but people use higher level languages like Python over C for the same reason we generally stopped using assembly in favor of C back in the day - the costs vs benefits made it worth it in many cases. C's a good language in many ways and I still use it where it's the right fit, but these days it's realistic to get anywhere between 2x and 10x the productivity by using a higher level language than C. And if the cost is very little in practical terms, it's hard to justify not using a higher level language for many projects. Just like assembly, C probably won't go away anytime soon, if ever. But just like with assembly, these days there are many, many, many scenarios in which the cost vs the benefit isn't worth it.

Sorry, I'm struggling to understand the point you're trying to make, as well as correcting the implication that there's generally available hardware that runs C natively.

The fact that Python was originally written in C is an argument for not using Python? I don't get it.

Oh c'mon, "No company uses python outside of scientific use" is wildly incorrect.

I started using Python about 15 years ago and, at the time, Python was obscure and it took some convincing to get others to use it for any "real" (i.e. customer-facing) projects. But it's so widely used now that I haven't had to make that argument for at least a decade, and I've used it at many different (and successful) companies.

I work for a Fortune 100 company currently and we primarily use Python for our whole sytem. Not by mandate - it's just a really great language in so many areas. Our whole web stack is written in Python and we handle hundreds of millions of transactions each month (yes, there are companies doing more, that's not my point, just trying to convey that it's not some toy web app or something).

And for large scale web apps, pypy+gevent packs a nice one-two punch. We've even started using Python on Android (via Kivy) lately, but at this stage it /is/ just for toy apps - for now.

No language is perfect for everything, but Python is really great in a lot of scenarios. Honestly, at this point PHP qualifies for the title of "odd language" than Python does. The fact that so many companies still use PHP is a historical artifact more than anything.

Most hardware doesn't run C natively either. ;-)