vec

The Econ 101 answer is that we'll have some number of people going into STEM fields would be more productive to the economy (and probably personally better off) as lawyers or cops or bakers or whatever. More realistically, it's likely to cause average salaries for engineers to decline somewhat as supply catches up to demand.

There are two essential traits I look for in a leader. They should have goals that align with my own, and they should advocate for policies that could reasonably be expected further their goals. At least in American politics, I usually see the term "idiot" applied to politicians who pass the first test but fail the second.

There's essentially no such thing as pure democracy at a national level. Even in cases of public referenda and ballot initiatives there's still a small group of (usually) professional bureaucrats of one variety or another that controls what questions are asked, how they are asked, and to whom.

Asking "the people to have their voice heard" on international organizations and trade agreements is particularly ill advised because those are "how" questions instead of "what" questions, and to a first approximation nobody actually cares about how. People care about whether their job is secure, or their groceries are affordable, or their culture is preserved.

Leaving the EU may or may not be a good idea for Britan, but crucially very few people really know whether it would or not. The level of specialized training necessary to reasonably predict the effects of leaving on any of the core interests that people do actually care about is prohibitively high. Directly asking whether to leave the EU is a bad idea because it doesn't capture what "the people" really want and it forces a specific course of action even when there may be safer and more effective methods for achieving the same ends.

Let's Encrypt doesn't offer EV certs. Which is reasonable; EV certs can't be automated (and they're a dumb idea anyway), but they're still necessary for some of my sites.

Do you have any examples? I completely believe you, but I'd love to know exactly which flavor of mass delusion we're dealing with.

C/C++ no,but it's not uncommon for me to stream of consciousness sizable blocks of Javascript or of HTML plus templating language special characters.

No, the argument is that humans are tribal creatures.

Imagine going off to live in the woods with a handful of other individuals, 100% off the grid and with only the tools you can carry. Inevitably, it wouldn't be long before you start insisting that everyone help out with farming or hunting or repairs or something. It's literally built into our DNA that individuals should contribute some labor to the betterment of the tribe in exchange for the security and comfort the tribe provides.

Now, fast-forward to the modern world. We have much, much bigger tribes called countries, and we have a way of talking about and trading human labor that we call money. But it's still true that you should contribute some of your labor (i.e. money) to the tribe (i.e. your country) in exchange for security and comfort (i.e. civilization).

Taxes are moral so long as the taxed individuals consent to be part of the entity imposing the taxes, and there are very few individuals throughout history who have actually been willing to opt out of civilization. And, since you're reading a page on the internet you are clearly not one of them.

Be very careful with this logic. I'm in the middle of cleaning up a project where the original developer did this calculus and stored a lot of metadata as JSON strings in text fields. Now, three years out, we have new reporting requirements that need to be able to filter on some of that metadata.

Experience has taught me that it's next to impossible to know what types of queries will be needed for the entire lifetime of a project. If you absolutely must store data like this, please leave a clear migration path for moving some or all of it into well structured tables when (not if) it becomes necessary.

Historically speaking, it's an incredible luxury to expect all of your children to survive past infancy. That doesn't mean it shouldn't be a basic expectation for citizens of an advanced modern nation.

If a third party can inject arbitrary JS onto your page then how you store your session token is far from your biggest problem.

Part of the idea is that if it takes more than 3 or 4 "why"s to get to some really fundamental business goal (i.e. "Because I want to make more money"), then it might not be a problem worth solving in the first place

Extremely well.

Stakeholders are supposed to present problems to engineers, and engineers are supposed to propose solutions to stakeholders.

The underlying meta-rule is that problems should be solved by the person with the most expertise.

It will, but it's still a net win because Google's not actually optimizing for time to load. They're optimizing for time to usability. Moving all of the non-essential CSS out of the head and into a post-load request increases the total request time but decreases the time until the user can begin interacting with the page.

It's still drastic overkill for almost everyone except Google, but it does make sense for their use case.

It's completely legal for the police to make note of who enters a public storefront. It's also legal for the police to dig through your trash. Once it's placed on the curb to be picked up it's not your trash anymore, it's the city or county's trash, and they can do with it as they like.

Evidence of illegal contraband in trash is almost by definition probable cause for a search warrant, and judges tend to be okay with handing out a few false positive warrants. Assuming that the police are professional and the citizens are cooperative, the damage is usually relatively minor.

This seems to be less a case of rules failing and more a case of common sense breaking down. Wasting an officer's time someone's trash because you once saw them leave a gardening store isn't illegal, it's just a dumb waste of resources. And serving the resulting search warrant with a SWAT team is the kind of risk-averse cover-your-ass common sense violation that legal remedies tend to make worse instead of better.

I think the real question is "does the existence of unicorns provide an incentive to the average founder?", and I'd say that question's a lot less definitive.

Sure, some founders have gotten filthy stinkin' rich off their startups, but those are lottery-ticket odds. Most founders seem to be aiming for either a self-sustaining small business or an acqui-hire, both of which are middle- to upper-middle-class career paths, but neither are by and large own-your-own-helicopter-class career paths.

Probably a lot of overlap, but they're separate projects with different versions and release schedules.

Because then they'd have to change the semantics of how `require()` works. As it is, node packages are not version aware at runtime. Instead NPM is designed to place packages such that any library will have the correct version first in their load path.

Changing the directory structure to encode versions is probably the Right Way in a grand sense, but it's a much more substantial change than just promoting packages by default.

So, assuming I have two libraries, A and B, that both require the same version of library C, do those libraries still get their own separate in-memory copies of C, or do they share a singleton?

It's terrible practice, but it's not unheard of for an NPM module to monkey patch its dependencies, since before this the library could assume it had sole ownership of its whole subtree.

Data types aren't the bottleneck, the deployment model is. Editing a Go application requires the following steps:

  1.  Edit the project's files.
  2.  Open the (scary and alienating) command line.
  3.  Run `go build` and hope it works right.
  4.  Find and stop the old running server process and start the new version

Oh, and you'd better hope step 3 goes smoothly, because a tiny mistake anywhere in your application will cause this weird thing called a "compiler error" that means that the entire thing will break. Editing a Wordpress site, on the other hand, looks like this:

  1.  Edit the project's files.
  2.  There is no step 2.

As developers, we're comfortable with the first workflow. We happily accept the added complexity because of all the other nice things it gives us and because we're probably using other tools like version control that end up making our experience much more uniform between the two. But to a user whose primary experience is with editing Word documents there is a huge jump there.

I don't think you're going to see a serious competitor to Wordpress in anything but PHP for a long time. The core target audience for a CMS is content creators and designers without strong compsci backgrounds. The things that make it hackable (trivial to modify in-place, extremely forgiving of type errors, no internal sandboxing, etc.) are the very things that make it attractive to non-developers.

Nothing is going to dethrone Wordpress unless it's at least as easy to cargo cult, and anything that does will more or less by definition annoy experienced developers more than what it replaced.

"Face consequences" doesn't necessarily mean "get fired". In this case it may be as simple as his boss pulling him aside to explain exactly how stupid what he did was. It may mean being pulled off the interview team and replaced with someone who's better at that task.

It's worth noting that neither we nor the original interviewee know whether this is repeated bad behavior or not. It might've been a one-time slip-up, or he might be serially abusing his position. We can't know, but his boss can and probably does. Go ahead and report to the folks who are in a position to make an intelligent decision.

Short selling is necessary and good as a stopgap measure, but there's at least one good reason we shouldn't want it to be a go-to reward strategy. Most investments have a bounded worst-case loss. You can only lose as much money as you put into it. Short selling, however, is backwards; you have a strictly bounded best-case profit and the theoretical maximum loss is infinite.

It's not inappropriate for discussion, it's just wrong. People who are rich and healthy don't have kids above replacement rates. We don't know why but we've observed the effect within countries, between countries, and across a broad range of cultural and religious groups. Economic improvement and public health aren't in opposition to population control measures, they are population control measures.

The correlation doesn't seem to hold at the high end, and much of the data in the western world confounds population growth due to fertility (still low) with population growth due to immigration (which has upticked across the board in recent years). As far as I know, though, the effect is still strong in the delta range that the Gates foundation is targeting.

This[1] suggests that fighting poverty is a pretty effective way to fight overpopulation. Most rich countries are reproducing well below replacement rates, and as poor countries become rich their average fertility reliably plummets. There are number of theories as to why, but one of the more compelling ones is that peoples' relationship to their children changes when they can be reasonably certain that all of those children will survive to adulthood. If that's correct, then public health initiatives may provide an even more direct impact on wide-scale population control.

[1]: http://en.wikipedia.org/wiki/Demographic-economic_paradox

This is correct, of course, in principle, but in the real world its often not feasible. As a freelancer, the author likely spends much of his time working on small business blogs and brochure sites.

These are frequently set up on a single server, containing code, database, and any file storage necessary. They're frequently written by cloning and modifying a framework, making reinstalling from a known good copy difficult to impossible. They often have no version control and are frequently configured to allow the webserver to modify code, so there is rarely a known good copy of the site code. In short, what's running on the compromised server is often the only usable iteration of the site's code available.

I hope nobody on HN would willingly set up a site like this, but the fact remains that they exist and need to be maintained. Attempting to clean a system in place is nowhere near 100% effective, but it's much more effective than doing nothing, which is exactly what will happen if you try to tell a client that they have to be offline for days, lose several months of data, and pay someone to rewrite half their site from scratch because you want to format their server and attempt to rebuild it.

> Imagine you make a tool and someone proposes making a change to that tool that would be potentially useful to slavers, people who enslave other people. This makes you hesitate.

No, it really doesn't. "Bad people might use it to do something I don't approve of" is a terrible rationale for not creating something, mostly because it's almost always true. Strong crypto is great for terrorists. Psychology research is wonderful for propagandists in dictatorships. Unlocked cell phones are very useful for drug trafficking rings.

If we, as a species, refused to innovate when we weren't sure of the consequences, we would still be arguing about whether fire was a good idea.

Triangle is "back", actually; the circle is "home". And the square thing is the app switcher history thingie. More evidence, I suppose, that the new icons aren't very intuitive.

On the other hand, floppy disks haven't been used for anything for a couple of decades now but they're pretty universally understandable as save icons. Most of our icon vocabulary has meanings that we learn by rote memorization more than inferrence from their pictographic representations. I'm not sure that the difference between a "good" and a "bad" icon (as long as they're used consistently) really matters that much beyond first-use experience.

Yes, and I think I can safely say I've never used this feature (in either Ruby or PHP) for anything more serious than a code golf challenge.

This might just be me, but I don't think an ordered hash is a particularly easy data structure to reason about. Almost all the code that I've seen depend on it in either language has been too clever by half.

You can't actually solve a lot of problems by throwing money at them. Ensuring that scaling your core application to arbitrary traffic sizes is in the class of money-solvable problems isn't trivial and should guide your architectural decisions from day 1.

Yes, you'll probably end up doing significant rewrites if you do actually win the lottery and get big, but it's nice to know that you're not going to top out at some arbitrary size and have to start turning customers away while you do those rewrites.

One of the main points of the article is that the only way to do Facebook-scale sites is to have an architecture that scales out horizontally without incurring any extra overhead, and that rails does so out of the box. So yes, you could quite easily run something at Facebook scale with rails, it would just require more physical servers than a more performant framework.