Thursday, January 7, 2016

Funny Slashdot exchanges, before they're lost to time

In the time that I was a regular reader of Slashdot, I saw a few exchanges that stayed in my mind. I later went back to find them, but was never able to. So that they're not lost to time, I figured I'd post all the ones I remember. What follows is from memory, and prettied up a bit. (Not trying to plagiarize, if you can find the original post for any of these, let me know.)

Enjoy.



[Story: Armadillo Aerospace has a failed rocket launch.]

A: Well, I think we can close the books on Carmack's little project.
B: Come on, now. Private space travel is still in its infancy. There are growing pains. Not everything works the first time. But what's important, is that we're learning from these events. Armadillo is learning. They'll adapt. And the next voyage will be better and safer!
C: You mean, even safer than a big orange fireball?



A: [long rant] So that's the problem with this ban on incandescent light bulbs.
B: Whoa whoa whoa, slow down. There is no "ban" on incandescent light bulbs. It's just that the government passed new efficiency standards, and incandescents don't meet them.
C: Oh, that's clever! I should try that some time: "See, I'm not breaking up with you! I'm just raising my standards to the point where you no longer qualify."



[Story: a pedophile was caught because he took pictures of his acts and tried to blur out the victims' faces, but police analysts were able to unblur them.]

A: Hah! What an amateur! Everyone knows you have to do a true Gaussian blur to destroy the information content of the picture!
B: Yeah, or entropize it by blacking out the whole face.
C: Right. Or, you know, you could just ... not molest children.

(IIRC, C was heavily voted down and criticized for assuming guilt.)



[Story: police used "big data" analytics techniques and discovered that most robberies occur on paydays near check-cashing places, which allowed them to ramp up arrests.]

A: I don't know, this seems kind of big-brothery...
B: Not at all! This is the kind of police work we should applaud! Working only off publicly available, non-private data, they found real, actionable correlations. It wasn't just some bigoted cop working off his gut: "Oh, this must be where the thugs go ..." No, they based it on real data. What's more, it let them avoid the trap of guessing the wrong paydays, which can actually vary! Some people get paid weekly, some biweekly, some of the 1st and 15th. For example, I get paid on the 7th and 21st.
C: So, uh ... where do you cash your checks, by chance?

Wednesday, December 30, 2015

What every programmer *really* should know about ...

So there's a common kind of article that comes up a lot, and annoys me. It's the "What every programmer should know" or "needs to know" about this or that. About time, or names, or memory, or solid state drives or floating point arithmetic, or file systems, or databases.

Here's a good sampling on Hacker News of the kinds of things someone out there is insisting you absolutely have to know before you can knock out "Hello, World", or otherwise meet some higher standard for being a "real programmer".

I hate these articles.

For any one of them, you can find about 99% who don't already know something from the article, and yet they manage to somehow be productive enough that someone is paying to produce a product of value. To me, they come off as, "I want to be important, so I want to make it seem like my esoteric knowledge is much more important than it really is." If taken seriously, these articles would heavily skew your priorities.

So here's my standard for when you're justified in saying "what every programmer needs to know about X":

Think about the tenacious, eager kid from your neighborhood. He picks up on things really quickly. Once he learned to program, he was showing off all kinds of impressive projects. But he also makes a lot of rookie mistakes that don't necessarily affect the output but would be a nightmare if he tried to scale up the app or extend its functionality. Things you, in your experience, with your hard-earned theoretical knowledge, would never do. When you explain it to him, he understands what you mean quickly enough, and (just barely) patches that up in future versions.

What are those shortcomings? What are those insights, that this kid is lacking? What of this kid's mistakes would you want to give advice about to head off as soon as possible? That's what every programmer needs to know.

The rest? Well, it can wait until your problem needs it.

Sunday, December 6, 2015

The Scylla-Charybdis Heuristic: if more X is good, why not infinite X?

(Charybdis = care-ib-dis)

A Scott Alexander post really resonated with me, when he talked about one "development milestone" (#4): the ability to understand and speak in terms of tradeoffs, rather than stubbornly try to insist that there are no downsides to your preferred course of action. Such "development milestones" indicate a certain maturity of one's thought process, and greatly change how you discuss ideas.

When a Hacker News discussed Alexander's post, I remembered that I had since started checking for this milestone whenever I engaged with someone's advocacy. I named my spot-check the "Scylla-Charybdis Heuristic", from the metaphor of having to steer between two dangers, either of which have their downsides. There are several ways to phrase the core idea (beyond the one in the title):

Any model that implies X is too low should also be capable of detecting when X is too high.

Or, from the metaphor,

Don't steer further from Scylla unless you know where -- and how bad -- Charybdis is.

It is, in my opinion, a remarkably powerful challenge to whether you are thinking about an issue correctly: are you modeling the downsides of this course of action? Would you be capable of noticing them? Does your worldview have a method for weighing advantages against downsides? (Note: that's not just utilitarian cost/benefit analysis ups and downs, but relative moral weight of doing one bad thing vs another.) And it neatly extends to any issue:

- If raising the minimum wage to $15/hour is a good idea, why not $100?

- If lifting restrictions on immigration is good, why not allow the entire Chinese army to cross the border?

- If there's nothing wrong with ever-increased punishments for convicts, why not the death penalty for everything?

One indicator that you have not reached the "tradeoff milestone" is that you will focus on the absurdity of the counter-proposal, or how you didn't advocate for it: "Hey, no one's advocating that." "That's not what we're talking about." "Well, that just seems so extreme." (Extra penalty points for calling such a challenge a "straw man".)

On the other hand, if you have reached this milestone, then your response will look more like, "Well, any time you increase X, you also end up increasing Y. That Y has the effect/implication of Z. With enough Z, the supposed benefits of X disappear. I advocate that X be moved to 3.6 because it's enough to help with Q, but not so much that it forces the effects of Z." (I emphasize again that this method does not assume a material, utilitarian, "tally up the costs" approach; all of those "effects" can include "violates moral code" type effects that don't directly correspond to a material cost.)

I've been surprised to catch some very intelligent, respected speakers failing this on their core

What about you? Do you make it a habit to identify the tradeoffs of the decisions you make? Do you recognize the costs and downsides of the policies you advocate? Do you have a mechanism for weighing the ups and downs?

Wednesday, December 10, 2014

Bitcoin mining pools attacking each other for profit?

So after posting our new Bitcoin book, my buddy Tim Swanson alerted me to the problem of Bitcoin mining pools attacking each other.

Reminds me of the recent Tax Interaction Effect post, where I had to unearth the core of a counterintuitive result: in this case, the claim that not redeeming some of your solutions can increase your return.

I don't think I'm entirely there, but I at least have an analogy to understand the mechanics of the attack.

Bitcoin mining model:As you might know, mining is like buying a bunch of (positive sum) lottery tickets. A fixed reward is given out every hour, then divided equally among the winning tickets. Some people join into pools, where they buy tickets with the proviso that *if* it's a winning ticket, they share the winnings equally among all the tickets in their pool.

The attack: You use some of your money to buy tickets for someone else's pool (call it the "attacked pool", but hide and destroy the winning tickets for that pool.

The effect: There are fewer total wins per period. Each (non-destroyed) ticket gets a larger fraction of the hourly reward. The attacked pool gets a smaller fraction the reward.

My response/confusion: This increases the return to all winning tickets, not just those of the attacking pool, so the attacking pool effectively subsidizes all the others, and dilutes the value of its own tickets across the set of all players.

But maybe I'm missing something here.

Tuesday, December 9, 2014

Our new Bitcoin eBook is up!

Phew, been a while, eh? Well, Bob Murphy and I have a new free eBook up about the economics and mechanics of Bitcoin! Check the site for it, or, if you're too lazy, just go straight to the book itself.

Sunday, March 16, 2014

Tax interaction effects, and the libertarian rejection of user fees

Phew! Been a while, hasn't it?

I want to come back to the tax interaction effect (TIE) issue from previous posts, and go over what I think has been bothering me about the TIE-based argument against the carbon tax shift.

So, a high-speed review of why a carbon tax shift (CTS) is inefficient. The CTS, remember, involves a revenue-neutral reduction of taxes on capital (including land) and labor, replaced by a tax on carbon emissions -- specifically, those fuels that, when used, release carbon dioxide, in proportion to how much CO2 they release per unit.

Review of the argument


And why could it be inefficient? Well, the harm of a tax increases faster than its rate. To have a revenue-neutral CTS, you have to "focus" the tax -- i.e. raise the same revenue from a smaller class of goods. This necessarily means a higher tax rate on the "focused" goods, and therefore higher induced inefficiencies (compared to the broader tax). When you further note that these taxes will, in effect, "stack on" to the existing labor and capital taxes, then the inefficiencies are even higher -- that's the TIE -- and could even swamp the environmental benefit from the emissions reduction."

But hold on. Those very same steps are a case against any correspondence between "who uses" and "who pays", whether or not the payment is a tax! That's because you can always point out how "concentrating costs" leads to disproportionate inefficiencies, even and especially for textbook "private goods".

That is, you could likewise say, "if people have to -- gasp! -- pay for their own cell phones, at $300/each, then that scares away all the people who can't pay $300 (after paying labor taxes, remember!), so you can an efficiency loss there. Plus, anyone who can steal the phone has a $300 incentive too, so people invest in ways to steal them, and you have to pay for countermeasures. Those go up quickly with the price of the good.

"Therefore, the government should just tax everyone to cover the cost, and then hand out the cell phones for free."

Wait, that doesn't sound right ...


What's wrong with that argument? Well, a lot. So much that you probably already know the answer. It's for the very same reasons that many advocate user fees for any good that's excludable. Generally, whoever benefits should be the one to pay. ("Cuius lubido, eius sumptum." -- "Whose desire, his expense.")

As with those reasons in favor of user fees, you can make the exact same argument regarding the purported inefficiency of a CTS:

"Yes, you get inefficiencies every time you concentrate costs like that. And yes, they disproportionately stack with whatever taxes you already had. But you need the fee structure to work that way in order to align incentives. The one who uses the scarce resource -- whether a cell phone, or atmospheric dumping capacity -- should be the one to pay for it, as this leads them to economize on the use of that resource, and if possible, route around it. That remains doubly so when exempting them from the expense would lead to further penalization of every other class of socially-useful activity."

And that, I think, goes to the core of my original balking at the CTS/TIE argument.

Saturday, November 23, 2013

Liberty vs efficiency: The real conflict

Liberty: Being free of constraints

Efficiency: Raising the state of the world as high as possible on everyone's preference ranking (or some aggregate measure thereof)

You might have heard of Amartya Sen's Liberal paradox, which purports to show that the two necessarily conflict. Of course, as I said a while back, it does no such thing; it only shows a problem with preventing people from waiving their liberties when they find it preferable to do so.

However, there is a real sense in which those two conflict, and it becomes most apparent in discussions of taxation, and how to make it better.

The conventional economist's view is that "The ideal tax system is the one that hurts efficiency the least."

But there's another view, exemplified by the Murphy article that I linked in my last post: "The ideal tax system is the one that's easiest to opt out of."

Naturally, these really do conflict. Why? Because generally speaking, if you want to levy a tax that merely transfers purchasing power to the government without also forcing people to bear other hardships, you have to do it by taxing goods with inelastic demand, like energy, as people will not respond to the tax by buying less of the good, which would indicate a reduction in efficiency.

But the harder a tax is to avoid, the harder it is to "opt-out" of!

So if you think it's good for people to be able to legally reduce government revenues by abstaining from a product at relatively little cost to themselves, then "economically efficient taxes" are no longer an unvarnished good, as they come at the direct expense of the goal of making it easier for people to change their behavior in a way that routes around taxation.

This, I think, is the true conflict between efficiency and liberty, as it doesn't hinge on confusing rights and obligations.