The Bay Area is absolutely worth visiting. The Computer History Museum alone is a must see if you're into that sort of thing.
The wealth inequality and housing crises don't make it a bad place to visit any more than New York, London, or any of the great cities.
People wouldn't complain about the changes in their home regions if they didn't love those places. There are many things about SF and the South Bay that make them really wonderful places: climate, natural attractions, cultural attractions, etc. And those things are very much available to tourists. The dystopia only starts when you try to find an apartment.
Somewhere in the instructions it says that your solution should run in less than a minute on ordinary computer hardware. Sometimes it's just as interesting to make your brute force solution more performant as it is to find 'the trick.'
The common thread is that robots look like people or animals. No one would call a CNC machine a 'robotic machinist' but an industrial robotic arm is still a robot because it is visually similar to a human arm.
What's more common outside PHP is that functions throw errors or exceptions when given invalid input, rather that trucking along and producing output that is clearly not what was intended.
At least in PHP. Unfortunately in my experience the PHP documentation is not frequently read by PHP developers or even PHP internals developers. It seems to exist mainly for PHP hatebloggers, for whom it's a gold mine.
This illustrates some problems with the PHP way of doing things. For some reason the PHP internals community prefers to have this function continue to spit out garbage when given invalid inputs instead of throwing an error, especially if spitting out garbage is what was done in the past. The answer is always, "Don't do that. RTFM." but most developers don't read the documentation for each and every function that they use, but rather rely on the name of and common sense until there's a error. If there's no error, the documentation never gets read.
True, but it takes a lot fewer resources to thoroughly catalog and monitor all large NEOs and divert the potentially hazardous ones. Estimates I've seen put 5km impacts at an average frequency of one every 10-100 million years range, and those are survivable. Larger impacts are even less frequent, but we can still likely divert them with existing technology.
To be fair, it's Hardware Description Language, not Hardware Synthesis Language. HDLs are mostly tools to support V&V, it's just that synthesis is the most convenient way to ensure that an implementation is consistent with the HDL description.
I see. This is similar to my experience. Most software is made for people to use at work, usually semi-custom. Most software also doesn't depend on low latency or high graphics throughout, so most applications, especially new ones, are web applications. Most of the developers I know that do similar work would call themselves "web developers" though that may be required to context. Someone might identify themselves as a web developer to me, a developer in an unrelated domain, but not to a non-developer in the domain.
I think the grandparent is referring to 'free as in beer.' It doesn't cost anything to tinker with programming because almost everyone already has a computer they use for other things. Not so with FPGAs.
All true. The first used F9 payloads will likely be Geosynchronous communications satellites, where the smaller payload is mostly fuel for apogee kick and station keeping, and the rest is mostly off the shelf hardware.
Alternately, operators of large constellations, eg. Iridium that can replace the payload relatively quickly and cheaply. Opportunity cost can be mitigated if some of the payload is intended as on-orbit spares.