The GM Sunraycer was only the winner of the 1st World Solar Challenge in 1987, but there's have been 100's of cars built like it for solar challenges around the world since then, including 16 different ones built just by my alma mater, the University of Michigan. Many have competed in the 15 World Solar Challenges that have happened since that 1st one, as well as multiple American, South African, and European Solar Challenges, among quite a few others.

Keep in mind, all of these cars, including Sunraycer, are race cars first. They are designed to be the most efficient vehicles possible because the amount of power available is still quite small. Modern solar powered race cars don't look quite like Sunraycer due to changes in race regulations and rules, but they are still the same in that they are basic ultra-efficient electric cars, with a battery, that just happens to also be charged with solar cells. All of them start a race with a full battery (normally about 5kWh), charged from a normal electric source, and then run the race purely on solar power.

There are challenges that aim the regulations at making more "practical" solar powered race cars (including a class within the World Solar Challenge) that hold multiple passengers or cargo. But these are still race cars, with specific usage scenarios for charging and no attempts at crash protection or other regulated features that are needed for a production car.

As much as I love solar powered car racing, I will be one of the first to say there will never be a practical solar powered car that the general public can use. Between the lack of power, the fragility of solar cells in general, the limits on weight due to crash protection regulations (among other regulations), and general usage scenarios that don't lend themselves to what solar powered car needs, it's just never going to be realistic.

As a former Scaled engineer, I can tell you, the plane is almost purely mechanical. SS1 was completely mechanical, except for an electric trim mechanism for the horizontal stabilizer. SS2 was identical, except the horizontal stabilizer was boosted by a self-contained electromechanical system that took a long time to design with failure modes that were controllable. That means pushrods and cables/pulleys to the control surfaces, large springs for gear extension, and mechanical actuators for the feather and feather locks. Aside from the avionics, one of the few electrical flight controls was the switch to arm and ignite the rocket.

They do have precise procedures about this. Its called the flight test card. The test pilot flies the procedures exactly as they are written on the card. They do nothing else unless some other anomaly during the flight requires them to fall back to basic flight training and just fly the airplane. They brief to that card before the test flight. The practice and train to that card on the simulator. If you know that the cockpit environment is going to be busy, you train your muscle memory to follow that card even if you can't look at it to check off each step.

We've all had things we've done a hundred times in a row, and for no particular reason, that one time, we forgot a step. Mike's muscle memory may have failed him this time and he ended up doing a procedure on the card out of order.

Like every test pilot at Scaled, Mike was a competent engineer in his own right, in addition to being a test pilot. I guarantee that everyone knew that if the loads were high enough the feather would move if it was unlocked, including the pilots. Like I said in another comment, I also guarantee that Mike flew the procedures on that test card plenty of times on the simulator and threw the feather unlock at the Mach 1.4 callout correctly every time. But in a high workload environment, no matter how much training you go through, sometimes the muscle memory that you're trying to train can fail you and you end up doing steps out of order.

You can't design out *all* the failure modes. If you try to, you end up with computer flying the plane and you still end up with some failure modes you can't work around. You can argue that's why spacecraft shouldn't be human piloted, but in this case, there were pilots there for a reason. Developing all that software for the computers takes time and money to write and to design out those failure modes. Scaled is good at flying experimental planes, and good at training pilots to do so. They applied that experience to spacecraft pretty successfully over the course of 17 flights for SpaceShipOne and 54 flights for SpaceShipTwo and did so much more quickly and cheaper than it would have been done if it were all controlled by computers.

As a friend of Mike, a former Scaled Engineer, and one that was directly involved in a previous Scaled accident, I have to completely disagree with your statements.

The culture at Scaled has been and will continue to be focused on nothing but safety. This was the first flight accident that Scaled ever had in its existence since 1982, with dozens of first flights of new aircraft designs and hundreds of follow up test flights. There had been engineering mistakes on many flights previously (I certainly made some), but the safety culture that Burt Rutan instilled in everyone focusing on "Question, Never Defend" was prevalent and always managed to get the aircraft home. The report mentions that no one ever thought about what would happen if a pilot pulled the unlock lever early. I guarantee you, everyone did. But just like a pilot knows not to put the gear down above max gear speed, or do full control movements when faster than the max maneuvering speed because things will break (and there are no interlocks on those things either), it could easily be expected that a pilot would never throw the feather unlock except when they are supposed to. Test pilots fly the test card and nothing but the test card. They are highly trained to follow the procedure on the test card. I'm certain Mike did that card over and over on the simulator and threw the feather unlock at the Mach 1.4 callout correctly every time. For some reason he uncharacteristically did the steps out of order on this flight. The result was catastrophic.

Your analogies don't hold up. If I'm in a car at 60mph and I turn a little too early, directly into a tree instead of on to a highway exit ramp, it can be pretty catastrophic to the car and its occupants. Until our autonomous cars show up, you can't design out the steering wheel. If you don't have time to look at the checklist for your next step because of the environment or because the workload is high and your muscle memory fails and you end up doing steps a little too early, it might also be catastrophic. If the procedure or checklist isn't followed exactly, catastrophic things can happen even on highly automated airlines.

Similarly, since a car's crumple zone, seat belt or airbag probably won't save an occupant that crashes into a tree at 200mph (lets up the speed since Mach 1+ is quite a bit higher than most average planes), you can probably understand that at certain speeds, you can't design in similar safety systems. This is called tradeoff analysis and is part of engineering, not malpractice.

Spaces work better than tabs because the code is always formatted properly. Code that is formatted improperly does not do what you think it does. This matters a lot when you have projects developed by 200+ developers with multiple millions of LOC. It matters even more when you have 3000+ developers working on many such code bases and they move between said projects with high frequency.

You cannot have your indent be two and me with 8 and have the code line up properly, especially when lining up complex if or math statements (where you may be using the level of indent to help with showing how the parens or operators nest). While you could argue "then split into multiple statements", I could argue "it's actually more readable as is". Subjective is neat that way.

Files that are being constantly updated because someone doesn't like someone elses formatting is dumb. Have a standard, stick to it. Fire the offender who refuses to play ball, problem solved.

Who prints code? Fine, let's say you do. Modifying the number of spaces per tab causes the issue I pointed out at phase 1.

Relationship argument makes no sense to me, sorry. Where the code lines up is what matters to me, not how many invisible characters appear between the beginning of the line and the first character.

Read his post again, it was clearly written sarcastically.

Citation needed.

The reason it's the number 80 was rather arbitrary, but a throwback to old punch-card systems.

I say this in a slightly different, but more concise way:

Comments (and self-documenting code) should tell you "what" and "why", because the code is telling you "how".