But laws regulate the maximum wattage of electric motors for bicycles and their maximum speeds.

In many places you can ride a bicycle legally on a sidewalk. You don't want power-assisted bikes going 30 MPH on sidewalks mixed with pedestrians and you don't want people "sneaking around the laws" in order to enable this.

"bike lanes or other gov-assisted options spend $/time on the 1% who bike."

Are car lanes a "government assisted option" for driving?

Spending money on "the 1% who bike" provides benefits for all of society. You might want to think about someone other than yourself.

"I'd rather have a hub motor but have a small battery pack affixed elsewhere, maybe in a bottle cage, where it doesn't have to rotate."

It's not as big a penalty as you think. The weight is nearer the center of the wheel. This design has real packaging advantages over what you describe. It's also not new.

"20 MPH can be sustained by a fit rider who isn't elderly."

20 MPH can be sustained by a fit rider who is elderly.

Electric assist isn't needed for fit riders and bumping the speed to 25 MPH wouldn't make it better for its purpose. Bike commuters are not well served by devices designed to increase their riding speeds, they are well served by devices that expand the range for which cycling is practical. When commuting the goal isn't to ride as fast as you can, it is to arrive safely while interacting appropriately with traffic and hopefully not flat constantly while doing so.

I am also 52 years old and I have no problem sustaining 20 MPH in the flats. On my 9 mile one way commute, it is simply not possible for me to complete the ride in less than 30 minutes without a big tailwind. I do not need electric assist at my distances but others might. I could consider longer distances with assist, though, and my average speeds would improve even with the 20 MPH limitation. I have no desire to ride at high speeds on the shoulders with cars coming at me oblivious to my existence. I am forced to take emergency measures once every couple hundred miles typically. Safety is a far bigger issue than top speed.

We need electronic sensors in order to avoid having to wear "skintight spandex" when we bicycle commute?

There's a big difference between "portable binaries" and binaries you've chosen (compiled for x86) that are specifically not portable.

There is such a thing as a portable binary. What do you think a p-code machine is?

I recently had to rewrite a modestly sized embedded project from C++ to C because it became clear that I could not afford the space for the mandatory libraries in the binary.

I did so by retaining the organizational concepts imposed by methods but made the implied "this" pointers explicit. I had to reorganize to undo the damage done by losing inheritance, virtual functions, etc. In a way, my biggest loss was losing overloading and templates. Those afforded elegant solutions that C doesn't match.

When I was done my source code actually shrank and my output binary size was cut in half. In no way could anyone argue that the code became less maintainable or less readable. Execution was notably faster and there was none of the god-awful unknown code executing that I had no control of. Exception handling is gone as is RTTI. Good riddance. I love some things in C++ but, on the whole, it is very burdensome.

You realize this is irrelevant to kernel programming, right? Device drivers are not applications.

It's sad that so many people think that memory leaks are the end-all definition of code maintainability.

Abstractions aren't ever given to you. All code is written and abstractions can be accomplished in C just fine, thank you.

People seem to forget that C++ was originally developed as a preprocessor for C. Anyone who says things can be done in C++ but not in C has an existence proof to the contrary.

It's not just easy to follow standards, your tools have to follow them as well. Unlike C, C++ typically requires linking with mandatory libraries and those libraries mandate things like exception handling. Not everyone has the luxury or resources to fight such problems.

Wow, what horrible observations.

Good thing C++ solved #define's, compiler optimizations, concurrency, interrupts and memory-mapped I/O! Such a difference that language makes.

Hidden mallocs, RTTI, exceptions, these are things that kernel programmers dream of...only not in a good way. ;)

The 39" Seiki is two panels side by side, not one panel. There are defects easily exposed when using this TV as a monitor. It is truly horrible in that application.

"The vehicle is purely electrically driven. It does have a petrol driven generator to top up the battery, but the engine is not involved in driving the wheels, so could easily be described as all-electric as you can rip out the engine and the car still drives."

Well you could rip out the batteries of a hybrid and it would still drive as well. Does that mean you could call a hybrid "all-gas"?

An electric drivetrain with a gas generator is a hybrid, not all-electric. It differs from other hybrid designs but that doesn't mean it isn't one.

Sorry, Dad, you don't know how digital cameras work. Pixels ARE 14 bits each in 14 bit RAW.

"Any competent C programmer can maintain any C code..."

In my experience, this is far from true. Depends on the definition of "competent", but then that's true for C++ as well.

"If you don't have coding standards and a firm code review process to enforce them, you have already lost."

Haha. Processes are only as good as the people who implement them. Good code is the result of effort, not policy, and I've seen plenty of "lost" that came out of thorough coding standards and firm code review processes. Nothing overcomes crappy programmers.

"It's tempting to imagine the internet as a giant blob of fungible bandwidth, but in reality it's just a big mess of cables some of which are higher capacity than others."

No, it's a giant blob of fungible bandwidth when you are talking about large ISPs and major media sites. It's not the dark ages.