billsimpson

health issues such as balding

Thanks, doc. Though I agree most men would prefer to avoid it, I never really regarded my balding as a health issue before now (and especially not the one I'd lead with over cancer and heart disease).

Accidentally creating sentient AI with today's technology would be like accidentally creating a nuclear explosion by rubbing two sticks together.

Boston cabs do this now (I assume it's happening all over) by playing a short ad reel that loops over and over. It's pretty horrible.

If that's their end game here, I'd be disappointed.

This doesn't represent an immediate threat to Uber's drivers, and I doubt most Uber drivers see themselves as Uber drivers in 3-5 years.

Many people here are suggesting that Google views Uber as a threat or a competitor. My take is that (a) Google wants to follow through on its self-driving car experiment, (b) public transportation would be a natural fit this product, and (c) Google doesn't want to be reliant on Uber, Lyft, or any other middleman for introducing self-driving car to the word. Initially, it will be a tightly-controlled roll-out that will eliminate as many variables and risk factors as possible.

This is their way of getting a head start in that direction, and smoothing the transition of the technology to partners like Uber down the road.

Facebook was viewed as a threat to Google for two primary reasons:

- Facebook had access to tremendous amounts of personal information, and it was assumed they could leverage this data to improve ads and search and beat Google at their own game.

- Everyone sat at their desktop computer staring at Facebook for hours on end, making it valuable ad real estate. Again, this cut into Google's core business.

So is Uber a comparable headache for Google? I don't see Uber as being a threat to their core business (their business is ads, not search; search just happens to be their best channel for ad delivery). Arguably it provides valuable information to improve their ad targeting, but it seems like a huge investment for relatively little payout in that regard.

My guess is that it's a natural extension of their work on self-driving cars. People have identified how Uber would be natural fit for self-driving cars. But I doubt Google wants to be reliant on a third-party company with reputation problems to introduce these cars to the world. That would introduce too many variables. So they're cutting out the middle man and doing it themselves, at least at first.

So how does this impact advertising? A nation-wide or global fleet of automated, networked cars would obviously produce a glut of valuable information (arguably their Uber-clone would too, but an automated solution could be taken to another scale). But really, I think the self-driving car is a disruptive enough technology that it could be completely orthogonal to their core business and still worth pursuing.

On a side note, can we agree yet that Facebook is quickly fading into irrelevance? It seems to have two important properties left (neither of which they developed): WhatsApp and Instagram. WhatsApp gives Facebook as much value as AIM gave AOL in its later years (which is to say, not enough to justify the company's size and market capitalization). Instagram took Facebook's best use case (looking at your friends' photos) and stripped away everything that made the experience suck: ads and Farmville (in other words, Facebook's business model).

I like what they're doing with React though.

That does sound fun. Let me know if you find it.

I never, ever want to write any OS-specific code

With Go, you never, ever have to write any OS-specific code. From a single source, you can build executables compiled for different operating systems.

In any case, you're right that it can be nice to simply "run" a JavaScript application directly from its source code without worrying about compilation.

You need to compile to code for every single platform, making code distribution costly. With Node.js you can simply distribute the code as it is and it probably works in any platform.

You're missing the point about distribution. Let's say you write a non-trivial command line application, and want to distribute it to your clients. With Go, you can distribute your program as a self-contained executable file. Yes, you may generate a few versions (Windows, OS X, etc.) depending on the needs of your clients, but the cost is a few seconds of compile time, and a few seconds posting links to the Windows, OS X, etc. executables. The cost is negligible.

Compare that to Node. How are you going to distribute your Node app to clients? Is every client going to install Node on their personal computer? Will they be able to figure out NPM? Yes, it's easy, but they'll mess it up anyway. What happens when the network has a hiccup and npm doesn't download your dependencies correctly, or they try to upgrade your dependencies and everything breaks?

If you plan on distributing your Node code, you're pretty much limited to distributing it to other Node developers. That's not going to work for everybody.

Maybe you don't like programming? Or you did once, but you've grown bored with it now that it's not as challenging?

In my opinion, a programming language is good if it enables the programmer to move from a concept to correct and maintainable implementation with minimal friction. I don't expect a programming language to entertain me.

The burden is then on me to find projects that I believe in and will enjoy implementing. This is, of course, easier said then done.

In that case, must you create one or more separate bundles to contain your vendor libraries? I suppose there's no way to directly integrate a jQuery library hosted on a public CDN.

I loved reading "Masters of Doom." It's an easy read, and a fascinating story about a handful of people of had a remarkable influence on an entire industry.

Also, I learned by reading it that Carmack and Romero created Commander Keen (somehow I'd never made that connection with their later games). Commander Keen was my Mario. Perhaps it was more than that. It introduced me to shareware, which led me to BBSs, and then the Internet.

Yes. The issue for me has been that I bundle my libraries with my app using, for instance, Browserify. So whenever I update the app (which is fairly often), the entire bundle needs to be redownloaded by all clients. I guess the obvious solution is to unbundle the larger libraries that don't get updated frequently.

they can't think their way out of a paper bag

Can you elaborate on this? Is this based on first-hand experience, media coverage, or some other source?

This is a bit off topic, but whenever I'm tempted to add React to a page or incorporate it into my single page app, I keep asking: is it worth roughly doubling the size of my javascript payload (130 kB React + 96 kB jQuery for AJAX + X kB business logic)?

I keep backing off, and sticking with jQuery/Backbone. One solution would be using a lightweight AJAX library in place of jQuery, but I haven't found one that is widely used, well maintained, and recommended. Can anyone recommend one?

Or in 2015 should an extra 130 kB be considered a non-issue?