I figured they'd tackle something more ambitious than that with their drone offerings - a drone that (barring instructions to do otherwise) follows you around whatever you're doing and keeps the camera on you, trying to get the most epic shots. E.g., you bungee jump off a bridge, it races you to the bottom, keeping whatever distance and filming style you told it to.

But maybe it's just another remote control drone.

So you mean get rid of wide-character encodings and only use UTF-8 where unicode characters are needed? I agree. :)

Is that Dice? Little Registry Cleaner now installs a ton of crap by default. Look at the latest reviews. You can still get a clean install by reading each of the dialog boxes but the point is it comes bundled with crap in the first place.

Use what makes sense for the application. I'd never try to run my *entire* house on DC. But between my modem, router, access point and VOIP box I have 5 separate 120V -> 12V rectifiers. I would love if I could just plug them into a separate 12V plug.

I have a 8 port USB charger to charge all the different things in my house that run on 5V. I've replaced a few outlets in my house with 4-Port USB outlets. I've seen bars and restaurants put them in because people charge things with 5V these days.

I'd say half of my house could run on DC without a problem. AC Generation->AC->DC->Use is still more efficient than AC Generation->AC->DC->AC->DC-> Use. And for people off grid you can get by with DC Generation-> Use

But that's the point. If it slams into an immobile object of course. But we're not talking about anything slamming into an immobile object. From the perspective of a molecule in the gas stream, it's going about the same speed as its neighbors. It's quite cool.

As for the boundary region, even at the "pinched" funnel outlet one could be talking dozens of kilometers here. A dozen kilometers between going from zero velocity and 25 kilometers per second is roughly the same as a dozen meters between going from zero velocity and 25 meters per second. Aka, a virtually insignificant gradient.

UTF-8 is an encoding of unicode, so I'm totally not getting your "Actually I think "Unicode strings" should be avoided completely."

Right now I program 6 figure machines with block diagrams.

I make my living by addressing the hard parts of getting processes automated. I've only been in industry for 10 years and I've already automated away a few internships. I'm learning Python explicitly for the purpose of automating dSpace + Matlab + hardware and reducing the need for 2-3 full time people.

Programming is a tool. Engineers use programming to automate away their engineering. Photographers use programming to automate away their photography. Farmers use programming to automate away their farming.

Your job isn't programming, it is automating what ever task you are trying to complete. What would have taken Hugin a few minutes to complete can now be done in a cell phone.

I like that idea. You're right, it should be pretty efficient to implement, regardless of the string's backend encoding. And the value represented by the iterator will, by nature of being implemented as a pointer to a certain part in the string, be able to point to a glyph of arbitrary length (unlike a getter function with a fixed-length return type). Being an iterator it'll fit into all standard c++ libraries that take iterators.

It would be nice to have it be a random-access iterator so that you can jump to an arbitrary offset. There's a lot of optimizations they could do internally to help facilitate that. But obviously you still want to let programmers choose - by some means or another - whether they want such unicode optimizations (or unicode iteration, or so forth). Because while the overhead they'd impose wouldn't be huge, there still would be overhead.

We have to have something, though. Not everybody writes in English.

Except wait - we've got a phase change from gas to plasma in there, which almost certainly breaks their calculations badly.

Again, no, you don't. All of the particles are moving in the same direction. They're not hot. They're not slamming into each other and kicking electrons off.

Do you think if you had a spacecraft moving at 25.4 kilometers per second it would be plasma too?

Russia would like for us to continue gifting them with cash for 40-year-old missle motors, it's our own government that doesn't want them any longer. For good reason. That did not cause SpaceX to enter the competitive process, they want the U.S. military as a customer. But it probably did make it go faster.

Also, ULA is flying 1960 technology, stuff that Mercury astronauts used, and only recently came up with concept drawings for something new due to competitive pressure from SpaceX. So, I am sure that folks within the Air Force wished for a better vendor but had no choice.

First off, you're misusing temperature. You don't call it heat if all of the particles are moving in the same direction and unionized, you just call it "wind". It only becomes heat if that windstream suddenly slams into a non-moving solid surface and becomes instantly thermalized (but of course even then that would be a very short-lived event as it would correspond with a pressure rise and the deflection of the stream behind the high-pressure zone). Additionally, nor would that be the windspeed touching the surface as, obviously, wind forms boundary layers.

Secondly, hundreds of km/s from Venus escape to Mars intercept? That doesn't at all correspond to any delta-V chart I've ever seen.

And it's important for new programmers to learn them - more important than learning syntax.

  For C++ for example I'd warn about classes containing pointer member variables with implicitly-defined assignment operators / copy constructors. You have Foo a and Foo b, where Foobar has a member variable "int* bar". So the newbie does "a.bar = new int[100];" then later "b = a;" then later b goes out of scope, then they try to use a.bar and the program crashes. Seems to be a very common C++ newbie mistake. Eventually they learn to see pointers in class definitions as having big "DANGER" signs over them calling their attention, and/or rely on smart pointers.

Any others that people can think of that are common?

Oh, here's one more: iterator invalidation. A newbie who's not warned about this in advance will likely get bitten by it several times before the point gets driven into their head: "if you're using a class to manage memory for you, it's going to manage memory for you, including moving things around as needed."

Yep, they have been UTF-16 for a long time. And Unicode has been widely broken for a long time. It's not a coincidence.

Someone on StackExchange did some tests last year, adding in 4-byte unicode characters in common applications and seeing how they behaved. The results were really bad:

Opera has problem with editing them (delete required 2 presses on backspace)
        Notepad can't deal with them correctly (delete required 2 presses on backspace)
        File names editing in Window dialogs in broken (delete required 2 presses on backspace)
        All QT3 applications can't deal with them - show two empty squares instead of one symbol.
        Python encodes such characters incorrectly when used directly u'X'!=unicode('X','utf-16') on some platforms when X in character outside of BMP.
        Python 2.5 unicodedata fails to get properties on such characters when python compiled with UTF-16 Unicode strings.
        StackOverflow seems to remove these characters from the text if edited directly in as Unicode characters (these characters are shown using HTML Unicode escapes).
        WinForms TextBox may generate invalid string when limited with MaxLength.

I've had more than my share of these sort of experiences too.

UTF-16 is dangerous, and should be phased out as much as possible. Where absolutely needed for performance reasons, it should be an internal representation only, hidden from the developer as much as possible. In particular, "length" functions should return the actual string length in characters, not code units; indexing functions should take character offsets; not code unit offsets; and returned "single characters" exposed to the developer should be of a format capable of handling multi-code-unit glyphs. Anything involving working with actual singular UTF-16 code units should only be available as a "for advanced users only, use at your own risk" functionality.