Worse, it was fucking boring. The Hobbit would have made a fine two hour movie, maybe two 1.5 hour movies. But there is not enough plot for seven and a half hours.

And by the time the last film is released, will be about 4.5 hours too long.

And what would you define something that didn't ingest, metabolize, excrete, reproduce and have some sort of system of heredity? Other chemical processes; like fire and crystallization, might hit some of these marks, but we don't call them living systems. So while the precise chemical processes, heck maybe even many of the chemical elements involved may be different (silicon-based life on Titan or something like that), I think at the end of the day if it going to be called life, it has to have the same basic features as terrestrial life.

If it's life, it's going to have a metabolism, it's going to reproduce and it's going to excrete. It may not, at first blush, look like life, but there will be chemical processes that in some way replicate processes found in terrestrial life.

I suspect they're not producing these kinds of phones simply because, despite the author's assertion, very few people actually do want such phones.

A writer and a submitter does not constitute some vast ignored market.

I actually totally get Amazon's logic on this one. If there's only a $10 extra profit on each drone delivery (something I'm sure tons of people in range of the service would pay for in order to get their item in half an hour), and if we assume each drone operational cycle takes one hour (delivery, return, charging), then that's $240 a day. Doesn't take a lot of days to justify the cost of a drone with a return like that.

Except that you have bought them; you just haven't realized it. Energy density of li-ion batteries has grown by about 50% in the past five years. Have you seriously not noticed how cell phone and laptop battery mah ratings keep growing while they keep making the volume available for the batteries smaller?

It's big news when a new tech happens in the lab. It's not big news when the cells first roll off a production line.

Most new lab techs don't make it to commercialization. But a lucky fraction of them do, and that's the reason that you're not walking around today with a cell phone with a battery the size of a small brick.

If everyone last person was going to be driving electric cars tomorrow, yes, that would be a problem.

Given that that's not the case, and for decades it's always going to be such that the people whose situation best suits an electric car are going to be the next ones in line to adopt them, then no, it's not a problem. You really think people can't build curbside/parking lot charging stations over the course of *decades* if there seems to be steadily growing interest in EVs?

As a side note, I don't know those exact neighborhoods in your pictures, but in my experience, most people who live in such places don't own *any* car.

Actually, 800 is quite a sensible number. At an average speed of 60 miles per hour (aka, factoring in driving / bathroom / meal breaks), that's 13 1/2 hours of driving - a good day's drive. Throw in a few more hours driving time / a couple hundred miles more range if you charge while you're taking your breaks. Once you get that sort of range, charge speed becomes virtually irrelevant because it happens while you're sleeping (and getting ready for bed / getting up in the morning). A regular Tesla home charger could handle that sort of load.

I agree with you that a half hour charge isn't actually that onerous, but it definitely will scare off people who are used to filling up faster. And charge stations that can do half hour charges on 300 miles range (150kW+ for an efficient car, more like 250kW for a light truck) are exceedingly rare as it stands. A charger that powerful isn't some aren't some little wall box with a cord hanging off of it, it's the size of a couple soda machines put together (bigger if you add a battery buffer so that you don't need a huge power feed) that feeds so much power that its cable has to be liquid cooled and which costs around $100k installed. Ten minute charges are, of course, around three times that size. I've only ever come across mention of *one* charger in the ballpark of the required 750kW to charge a 300 mile light truck in 10 minutes - an 800kW device custom made a couple years back for the US Army Tank Command. I have no clue what it cost, but I'm guessing "Very Expensive".

I'm not saying that the problem is intractable, by any stretch, I totally believe that we're going to transition over to EVs. I just question the sort of time scales that a lot of people envision. The average car on US roads is 10 years old. Implying an average 20 year lifespan. And many cars don't get scrapped then, they just go to the third world. Even if you suddenly switch all new car manufacturing over to EVs, you're talking decades to replace them. But of course you can't just switch over like that - even if everyone was right now sold on the concept of EVs with current tech, you're talking at least a decade, possibly more, to tool up to that level of production. But of course, not everyone is right now sold on the concept of EVs with current tech.

Realistically, you're looking at maybe a 40 year transition. I hate to say that, because I love EVs, but I'm not going to just pretend that the reality is other than it is.

I'll also add that while fast chargers are big and expensive, the size and cost actually are comparable to building a gas station on a per-pump basis, and the economic argument works out for making them even if there's only a reasonable (50% or less) surcharge on the electricity sold and if they're only selling electricity a couple percent of the time. But you need to get a couple percent of the time usage to economically justify them - one person stopping for 10 minutes every few days just isn't going to cut it. And not every EV is going to stop at every charger even if they're driving on the same route - if your chargers are that far apart, then that means you're pushing people's range so much that they're not going to be comfortable driving that route. All together, this means that if you want to have fast charging infrastructure economically justifiable in an area you need high EV penetration, where several dozen EVs driving long distances will be going by each charger every day - even out in the boonies. And when you're talking at prices on the order of $100k per unit, you're no longer talking about a range where peoples' goodwill toward EVs or interest in having a loss leader outside is going to pay for them.

Basically, while busy interstate routes on the coasts and the like can economically justify them with a small fraction of a percent of people driving EVs, out in the boonies, they're going to be stuck with smaller, cheaper, slower chargers for a good while. Unless people are willing to pay a big surcharge on the electricity sold, that is (500% surcharge instead of 50% = 1/10th as many vehicles needed).

You don't have to understand everything, but you do need to at least understand the basics, like how networking works, how crypto works, etc. at a conceptual level. I feel like too many developers learn how to program by learning JavaScript and other scripting languages on their own, then jump into app programming thinking that it's only one step harder because you can sort of do it in Python/Ruby/other Obj-C bridged languages/other .NET languages, or because Swift looks like JavaScript, or whatever their logic might be. Unfortunately, it's not one step harder if you care about doing it right; it's a hundred steps harder, but the apparent accessibility of app programming tries to hide that fact, resulting in a lot of people getting in way over their heads.

Too many developers then balk when we tell them that they need to read conceptual books, insisting that they just want to learn how to solve their particular problem. The result is that they understand just enough of what they're doing to be dangerous. It's like deciding to build a house and telling someone, "I just want to know how to cut a board and hammer in a nail." You're likely to get a very strange looking house with no right angles. You really need to start with higher-level design and philosophy texts, then work your way down to the practical texts. That's equally true in programming, but the short-attention-span instant-gratification crowd just doesn't get that.

And I understand the desire to just learn how to solve the problem. I've been there, and I've done that, but only in areas where I was reasonably comfortable. Even then, I've often later discovered that snippets that looked right weren't quite right in certain edge cases, but at least this happens fairly infrequently, because I've taken the time to learn what I'm doing. Developers who don't do this aren't just hurting themselves; they're hurting their users. There's just no reason for that.

How much does a middle aged Slashdot ID go for nowadays? I might be in the market to sell mine to an astroturfer.

Code recycling is one thing, but not understanding what that code does when you put it into a production app or not following best practices is another. As Android gains popularity as a platform to develop for, we're going to lose quality as the new folks jumping onto the band wagon don't care how their apps work or look beyond the end goal. This mentality is already popping up with Android Wear developers who cram as much information as they can on the screen and claim that design guidelines are "just recommendations."

The exact same thing happens on every other platform, though perhaps to varying degrees. I refer to it as the Stack Overflow effect. One developer who doesn't know the right way to do something posts a question. Then, a developer who also doesn't know the right way to do it posts how he or she did it. Then ten thousand developers who don't know the right way to do it copy the code without understanding what it does or why it's the wrong way to do it. By the time somebody notices it, signs up for the site, builds up enough reputation points to point out the serious flaw in the code, and actually gets a correction, those developers have moved on, and the bad code is in shipping apps. Those developers, of course, think that they've found the answer, so there's no reason for them to ever revisit the page in question, thus ensuring that the flaw never gets fixed.

Case in point, there's a scary big number of posts from people telling developers how to turn off SSL chain validation so that they can use self-signed certs, and a scary small number of posts reminding developers that they'd better not even think about shipping it without removing that code, and bordering on zero posts explaining how to replace the SSL chain validation with a proper check so that their app will actually be moderately secure with that self-signed cert even if it does ship. The result is that those ten thousand developers end up (statistically) finding the wrong way far more often than the right way.

Of course, it's not entirely fair to blame this problem solely on sites like Stack Overflow for limiting people's ability to comment on other people's answers unless they have a certain amount of reputation (a policy that is, IMO, dangerous as h***), and for treating everybody's upvotes and downvotes equally regardless of the reputation of the voter. A fair amount of blame has to be placed on the companies that create the technology itself. As I told one of my former coworkers, "The advantage of making it easier to write software is that more people write software. The disadvantage of making it easier to write software is that... more people write software." Ease of programming is a two-edged sword, and particularly when you're forced to run other people's software without any sort of actual code review, you'd like it to have been as hard as possible for the developer to write that software, to ensure that only people with a certain level of competence will even make the attempt—sort of a "You must be this tall to ride the ride" bar.

To put it another way, complying with or not complying with design guidelines are the least of app developers' problems. I'd be happy if all the developers just learned not to point the gun at other people's feet and pull the trigger without at least making sure it's not loaded, but for some reason, everybody seems to be hell-bent on removing the safeties that would confuse them in their attempts to do so. Some degree of opaqueness and some lack of documentation have historically been safety checks against complete idiots writing software. Yes, I'm wearing my UNIX curmudgeon hat when I say that, but you have to admit that the easier programming has become, the lower the average quality of code has seemed to be. I know correlation is not causation, but the only plausible alternative is that everyone is trying to make programming easier because the average developer is getting dumber and can't handle the hard stuff, which while possible, is even more cynical than the original assertion and makes me weep for the future.

Either way, there's something really, really wrong at a fundamental level with the way we search for solutions to coding problems. There needs to be an easy way to annotate the fact that a code snippet was derived from a particular forum post, and to automatically receive email notifications (or bug reports) whenever someone flags the snippet on the original forum as being wrong or dangerous. And we as developers need to take the time to learn enough about the OS and the programming environment to ensure that we at least mostly understand what a piece of code does before we ship it in a product.

I'm not clear as to how, for instance, using buggy versions of SSL libraries fits into your whole theory. One possibility is that what you wrote is gibberish.

Now, now, now, it's not the version control system's fault that you checked in a bug....

You could have saved some typing by not opening the article. But then you would not have been able to write this long pointless OT rant.