## Friday, October 17, 2014

### On object oriented programming

tl;dr() return true;

As a result of a recent promotion, I've been brushing up on my programming skills. By far the most dominant programming paradigm today is "object oriented programming," (OOP) which is a style of coding that aims to represents programs as data structures contained in objects. What is an object? Yes.

According to Smash Company, it turns out that "Object Oriented Programming is an expensive disaster which must end." The article is quite lengthy and well informed, but I think it is at once too harsh on OOP and not harsh enough.

In OOP languages everything in a program is an "object"--your program itself is an object, all of the components of your program are objects, all of the components of those components are objects--"it's objects all the way down" as the saying goes. This is where I think Smash Company was too harsh: the generic and abstract nature of the "objects" in OOP languages makes them extraordinarily flexible, allowing these languages to support a diverse range of programming styles. Rather, they argue against not so much OOP languages themselves as the programming style which is also known as "Object Oriented Programming." I think this is something of a misnomer. The programming style that has come to be associated with OOP should more precisely be called "Class-Oriented Programming" because the central tenant is that all data and functions in your code should be organized in a specific type of object called a class. Indeed, Bjarne Stroustrup, who invented the first popular OOP language originally called his creation "C with classes" instead of the later name "C++."

While you can do Class-Oriented Programming (COP) in languages like Python and Javascript, these are actually more highly general versions of the core COP languages of C++, C#, and Java which more or less torture programmers into adopting the COP style. In COP, the aim is to put all your code into classes that are separate from each other and minimize the amount of code inside the main section of your program. The classes themselves shouldn't do anything other than store your initial data. Instead, to use the data contained in a class the main program will create "instances" of the class as needed at run time, and perform all operations on these instances rather than the classes themselves. The advantage of this is that it prevents data destruction. In a non-COP program, for example, you might start with a dataset, perform some operations that change the dataset to get the desired output, but then be unable to reuse the original, unmodified dataset because it has now been altered. Ideally, a COP design prevents this problem by allowing you to call additional, separate instances of the original dataset (ie, the class) for each separate routine you are performing, without ever modifying the original data. This is called "abstraction," one of the three pillars of COP (note, I'm use the term "abstraction" through out this post generically to refer to a few separate but related OOP concepts: abstraction, encapsulation, and information hiding. Sources disagree on the exact definitions, which aren't really relevant here.).

But more likely than not, your program does not consist of doing a series of identical routines on identical datasets, but instead performs distinct routines on a set of related datasets. You could just make separate classes for each type of dataset and leave it at that. But if the types are related to each other, then they probably have a lot of common features that would require you to copy and paste identical chunks of code, and that's just a pain in the butt, especially when, months from now, someone asks for additional parameters to be included in all the data and you have to change every single dataset type you use. For this, COP offers inheritance. You still have to define as many classes as you have types, but if you create one or more additional parent classes where you put all the common code the types share, you can save time by simply telling the child classes to inherit this code from the parent classes. Indeed, "inheritance" is usually cited as the second pillar of COP.

But sometimes your classes are so similar you just say what the heck and combine them into one by programming the one class to respond differently under different situations, mimicking the multiple class you eliminated. And programmers are so lazy that this "polymorphism" is actually called the third pillar of COP.

So how does all this actually fare in practice? Like Smash Company, I'm inclined to conclude that it fares not well. At it's core, programming is just set theory. And it turns out that this set is too complicated for the COP paradigm:This is where I think Smash Company was not harsh enough: inheritance, at least as it is implemented in COP is bad bad bad.

Let's explore why with a simple application. For reasons no one is entirely happy with, my employer uses C#, so we'll use C# to construct a standard 52-card deck of playing cards. The goal is to use the COP paradigm to produce 52 objects representing the 52 playing cards--that the goal is to produce objects means we are already biasing this exercise in favor of COP. Each card bears the identifying features of a playing card--color, rank, and symbol--and does stuff for game play. So let's rewrite that in C# notation:
abstract class Card {
private string symbol;
private string rank;
private string color;
public string[] deal(){
return new string[]{color,rank,symbol};
}
public void show() {
Console.Write("\n{0} {1} of {2}", color, rank, symbol);
}
public Card(string c,string s,string r) {
color=c;
symbol=s;
rank=r;
}
}
Ok, so all I've done here is create a dataset describing what a card is like: each card has three data fields called symbol, rank, and color, that are left blank for now, as well as three methods called deal(), show(), and Card(). Technically, there are no functions in C#, and all behaviors are carried out by methods. What is a method? It's a function.

Two of the methods in the class Card, deal() and show(), are used in game play while the third is called a constructor--it's purpose is to create objects of the type Card, and those objects are called "instances" of the Card class. Remember, the code above isn't a card, it creates cards with all of those specified features. We haven't actually created anything yet.

Now, no card player ever says "this is a card that has the color red, rank Jack, and symbol Diamond"--rather we say "this is a red Jack of Diamonds." In COP, anything that fills the blank "is a ____" should be described by a class, while "has a ____" are things that should be properties of the class. So we can divide Card into two subclasses, Red Card and Black Card which are themselves classes:
abstract class Red:Card {
public Red(string s, string r)
:base("Red",s,r)
{

}
}
abstract class Black:Card {
public Black(string s, string r)
:base("Black",s,r)
{

}
}

These two new classes, Red and Black, inherit all the fields and methods of the Card class, but differ in the colors they assign to cards. We can go further, because there are two kinds of Red cards, Diamonds and Hearts, and two kinds of Black cards, Clubs and Spades. Thus we have four more classes, inheriting from Red and Black and, by transitivity, from Card as well:
class Heart : Red
{
public Heart(string r) : base("Hearts", r) { }
}
class Diamond : Red
{
public Diamond(string r) : base("Diamonds", r) { }
}
{
}
class Club : Black
{
public Club(string r) : base("Clubs", r) { }
}

Ok, we've still not created any cards. But we have created various classes that describe some of the data that makes up each card, and so far we've done it without having to copy and paste anything, because our inheritance classes let us apply all the common features to their respective cards without needing to mindlessly reuse code. This is good. But now we're stuck. We still have 13 more classes--2 through 10, plus Jack, Queen, King, and Ace--but no way to represent them as classes in the COP paradigm, because of inheritance. A Jack of Hearts, for example, should inherit from the classes Jack and Hearts, but COP does not support instantiating a single object from more than one class. Even if we wanted to create a class called Jack of Hearts, C# does not allow multiple inheritances so class JackOfHearts:Jack,Heartsdoes nothing. It's true that other languages like C++ do allow multiple inheritances at the class level, but this doesn't really help us as it would mean coding 72 separate classes to generate 52 playing cards.

It's true that there are some silly tricks you can do with interfaces here, but they are exactly that: stupid hacks that probably shouldn't work but do. Here's what I will do. Instead of creating classes to represent the actual ranks of the cards, I will create one more class, representing the concept of a deck of cards. This final class will contain the instructions for making all 52 cards from the 7 classes we've already defined. Here it is:
class Deck :List<Card>
{
private string[] rankList = {"Ace","King","Queen","Jack","10","9","8","7","6","5","4","3","2"};
public Deck(){
for(int i=0;i < 13; i++){
}
}
}
What this does is create a class that follows the structure of a List, which is a pre-defined class in C#. The elements of the list will be our 52 card deck.

So that's all the classes. All of the data needed to make a 52 card deck are contained in those 8 classes, and we wrote this without hardly needing to repeat any bits of code. But we still don't have our deck of cards, these classes are merely instructions to the computer about how it would go about making the cards. To actually tell the computer to make them, we have a 9th class--which is common to all C# programs, that contains a static void main() method. When you actually run the application, it will start by running this method, and then following your instructions to all the various classes and methods in the order that you specify within main(). At this point, creating the deck is as simple as Deck myDeck=new Deck();We can now use this deck for card playing. You can imagine doing something fun here, but in our case we will merely read all of the cards off into the console:
for(int i=0; i < myDeck.Count;i++){
Console.WriteLine(myDeck[i].show());
}

Putting all the code together now:
using System;
using System.Collections.Generic;
namespace cards
{
class Card {
private string symbol;
private string rank;
private string color;
public string[] deal(){
return new string[]{color,rank,symbol};
}
public void show() {
Console.Write("\n{0} {1} of {2}", color, rank, symbol);
}
public Card(string c,string s,string r) {
color=c;
symbol=s;
rank=r;
}
}
abstract class Red:Card {
public Red(string s, string r):base("Red",s,r){}
}
abstract class Black:Card {
public Black(string s, string r):base("Black",s,r){}
}
class Heart : Red
{
public Heart(string r) : base("Hearts", r) { }
}
class Diamond : Red
{
public Diamond(string r) : base("Diamonds", r) { }
}
{
}
class Club : Black
{
public Club(string r) : base("Clubs", r) { }
}
class Deck :List<card>
{
private string[] rankList = { "Ace", "King", "Queen", "Jack", "10", "9", "8", "7", "6", "5", "4", "3", "2" };
public Deck(){
for(int i=0;i < 13; i++){
}
}
}

class Program
{
static void Main(string[] args)
{
Deck newdeck=new Deck();
foreach(Card i in newdeck){
i.show();
}
}
}
}

This code has some admirable features. For one thing, we've achieved a significant amount of data abstraction: almost everything in our code is protected, so that computer, programmer, or user errors cannot corrupt the data. The color, rank, and symbol data for all of the cards, for example, are private variables that cannot be altered once the cards are created. Moreover, the Red, Black, and Card classes are all abstract, meaning that we cannot instantiate Red cards that aren't Hearts or Diamonds, for example. The abstraction of this code into modular classes also makes it exceedingly easy to add new types of cards--for example, Green Flowers as a new type of card along side the traditional Hearts, Diamonds, Clubs, and Spades, is as simple as adding Green and Flower:Green classes, and inserting one line into the Deck class. And, at least for our purposes, adding another rank--say, an 11 to follow the traditional 2 through 10, is as easy as inserting "11" into the rankList array.

At the same time, this code represents a complete failure of the COP paradigm to achieve its goal. We aren't actually creating the right objects. We aren't, for example, creating a Red Jack of Hearts, but rather a Red Heart that has a Jack. The only COP way to produce a true Red Jack of Hearts requires more classes than we have cards, and isn't even supported in all the major COP languages. And the level of abstraction that is possible here could be better, since this code gives both the Deck class and the main() method direct access to the Heart, Diamond, Spade, and Club classes, which in reality are abstract. This exposes our code unnecessarily to additional possible sources of error that--in a larger program--could be extremely hard to track down because it could originate anywhere in the code. Moreover, we are calling constructors from inside the Deck class, which is bad according to COP.

The failure of COP to actually be capable of representing a standard 52-card deck is a bit comical. This is programming, after all, and computing repetitive patterns of data in a systematic way is what computers are supposed to be good at. Hardly anything in the real world is as systematically patterned as the 52 card playing deck where, although each card is unique, no card contains unique attributes and all of the attributes are assigned according to fixed, very simple rules. I should be able to tell the computer what these simple rules are, and get it to do the rest.

But isn't a simple rule...wait for it...just a function? YES! In fact, if we adopt a more functional paradigm instead of full-out COP, multiple inheritance is no problem at all. Consider the following generic non-COP language
function setA(obj){
var obj={};
obj.prop1= <properties of set A> ;
return obj;
}
function setB(obj){
obj.prop2= <properties of set B>;
return obj;
}
function setC(obj){
obj.prop3= <properties of set C>;
return obj;
}
function main(){
var b=setB(setA());
var c=setC(setA());
var d=setC(setB(setA()));
}
var closure=main();
We just constructed what COP could not. We have created three objects: object b is an element of sets A and B from the Venn diagram above, object c is an element of sets A and C, while object d is an element of A,B, and C, corresponding to the set D in the diagram. This is where Smash Company was not harsh enough. We want inheritance, but we do not want hierarchical data structures. The real world does not consist of coverings of mutually disjoint sets. In the real world, data is not hierarchical.

So, with the functional approach we've achieved a stronger version of inheritance than COP allows for. We've fully protected and abstracted all our data by using local variables defined inside functions, along with closures, and we don't need any darn polymorphism because our functions are not loitering inside objects pretending to be "methods." Adding more types is still just as easy as inserting more functions. The code is still totally modular and serviceable. And we still ended up with objects as the result of our initialization procedures. My point is that the functional paradigm does object oriented programming better than the dominant COP paradigm.

And yes, in the real world an object can belong to both the class of objects that are "too harsh" and the class of objects that are "not harsh enough."

## Wednesday, September 17, 2014

### Chamley-Judd revisited

When I started grad school we started with a math boot camp, of which the first topic was formal reasoning. One of the exercises that some of my classmates struggled with was counter-factual reasoning. Take for example the theorem:
If 1+1=3, then 2=1.
This is a valid theorem. We can prove it: we know that 2=3-1, and it is postulated in the theorem that 3=1+1, therefore 2=1+1-1, which implies 2=1. Neither the postulate nor the conclusion are factually correct, but the theorem is nevertheless correct.

I mention this example because it turns out that one of the most important theorems in tax theory makes exactly such an error. I'm referring of course to the famous Chamley-Judd result which is usually described as saying that we can't redistribute capital income to workers--that the optimal tax rate on capital is zero.

But that's not what the theorem actually says. Take for example Judd (1985): in the rather extreme setting where capitalists are unable to work and workers are unable to save, Judd's theorem says
Theorem 2. If the redistributive capital taxation program maximizing a Paretian social welfare function converges [to a steady state]...then the optimal capital income tax vanishes asymptotically. Specifically, there should be no redistribution in the limit and any government consumption should be financed by lump-sum taxation of workers.
Ok, there's a lot of verbiage in there, but the point is that Judd's theorem postulates that at the optimal tax rate all quantities and multipliers converge to fixed steady state values, and from this concludes that that optimal capital tax rate is also constant at zero. As a theorem, "if steady-state exists, then optimal rate is zero" is correct. But a recent paper by Ludwig Straub and Ivan Werning showed that Judd's postulate "if a steady-state exists" turns out to be about as wrong as 1+1=3. As a result, so is Judd's conclusion.

In fact, at the optimal tax rate the steady-state which Judd assumed does not necessarily exist. To illustrate the conditions when it doesn't exist, suppose that capitalists have utility functions of the form $$U=\sum_{t=0}^\infty\beta^t\frac{C_t^{1-\sigma}}{1-\sigma}$$ (which is the same as in my DSGE calculator) where $C_t$ is the capitalist's consumption in period $t$, and $\beta,\sigma$ are just constants. As Straub and Werning showed, if $\sigma\gt 1$ and we want to make workers as well of as absolutely possible, then the optimal tax rate doesn't converge to zero as Judd claimed, but actually diverges all the way to 100 percent1 in the long run! It turns out that at the actual optimal tax rate, equilibrium doesn't converge to a steady-state but actually diverges so that capital stocks and consumption plummet towards zero over time. This result illustrates exactly how extreme a setting the Judd model where workers can't save really is--so extreme, that workers are actually better off suffering immiseration than the pittance they'd earn under a zero-tax regime. At least with immiseration, workers will get to consume the capital stock first.

Judd is still wrong in the special case where $\sigma=1$ which corresponds to logarithmic preferences.2 Even though in this case the quantities do converge to steady state, the optimal capital tax is still positive in the steady-state because it turns out that the multipliers diverge. If you're unfamiliar with the math, 'multipliers' are a weird relic of mathematical optimization techniques that do not represent real-world things--they can be interpreted as the theoretical "marginal utility of wealth" but they are really just abstract mathematical constructs. Yet Judd's theorem requires that these too converge to steady state values at the optimum tax rate, which isn't even true in the simplest case of his model.

For anti-taxers, there is a small silver lining. If $\sigma\lt 1,$ then the equilibrium does converge to steady state and the optimal tax rate converges eventually to zero. But for practical purposes, even if you think $\sigma\lt 1,$ this probably doesn't matter much, because convergence to that steady state is quite slow:So, no, we can't actually say that the optimal tax rate on capital is zero. Chamley-Judd didn't even say that!

I've only focused on Judd, but Straub and Werner also look at Chamley as well. There's a lot more in their paper than I was able to squeeze in here, so go check it out!

1 I'm assuming that the government's only function is to redistribute. In the case where the government also consumes resources (often termed "wasteful government spending"), such as when redistribution imposes administrative costs or where government provides services other than social insurance, then the long-run capital stock must remain just large enough for the government to be able to finance it's own consumption, which requires a maximum long-run capital tax less than 100 percent.

2 To see why, take the derivative: if $\sigma=1$ then $$\frac{\partial}{\partial C_t}\left(\frac{C_t^{1-\sigma}}{1-\sigma}\right)=\frac{1}{C_t}=\frac{\partial}{\partial C_t} ln\left(C_t\right)$$ for all $C_t.$

## Monday, September 15, 2014

### Monday Morning Music

Here's the chorus from the beginning of Rossini's La Cenerentola. To be honest, I didn't think the Met's production overall was very good--unusual for a production that includes Elina Garanca--but this seems to be the best version of this particular aria on youtube at the moment:

## Sunday, September 14, 2014

### Why we have no idea if ACA premiums are rising

A recent report from the Kaiser foundation found that premiums on the ACA exchanges are falling slightly, a big surprise not just because of the right-wing hysteria about how the ACA was supposed to cause massive price hikes, but also because it is historically unusual: pre-ACA, insurance premiums usually went up by between 5 and 10 percent per year.

The Kaiser study compared the second-lowest-cost silver plans on the exchanges for 16 cities from 2014 and 2015, finding an average decrease of 0.8 percent from 2014 to 2015. I do have doubts about the dataset itself--it's possible that states that offer more comprehensive data (the criteria for inclusion in this study) are not representative of most states. Time will tell.

But Avik Roy isn't impressed: he cites this McKinsey study finding an 8 percent increase on average between 2014 and 2015. Their methods are similar to Kaiser's, with (as far as I can tell) the only major difference[update] being that McKinsey looked at the cheapest silver plan while Kaiser had looked at the second-cheapest plan (same caveats about incomplete data apply to both). That tells me that estimators of this type aren't very stable, and thus not very useful.

These estimators suffer from compositional fallacies. For example, on twitter Austin Frakt makes an excellent observation: That is, neither estimator is literally comparing the same plans year to year. Moreover, they are looking at only one plan in each area in each year, and therefore missing what's happening to most of the premiums that people are buying. To see why this isn't robust, just consider the case where the cheapest plan in 2014 simply isn't offered in 2015 because no one bought it, but that none other premiums changed at all. This would show up in McKinsey's study as a large premium hike, even though no one is paying a higher premium! The Kaiser-McKinsey estimator has extremely poor theoretical validity, and is not what we want to look at how premiums are changing.

When I think about premium hikes here’s the “ideal” estimator I have in mind: take the premium for each specific plan in 2015 and subtract the 2014 premium for the exact same plan, and then take the average of the differences weighted by the number of 2014 buyers for each plan. This truly tells us the average—not the mostly meaningless “benchmark”—change in premiums while eliminating all confounding compositional effects. It’s also mostly impossible, because the plans offered in 2015 are not the same as the ones in 2014. They never are. Still, I think this is the standard against which various metrics should be compared—a statistic is only valid if it approximates this. Kaiser and McKinsey haven’t got it.

[update] Avik Roy also pointed out this difference in methods between the two studies:

## Wednesday, September 10, 2014

### Why might increased insurance coverage decrease Emergency Department use?

Adriana McIntyre points us to a recent study in Health Affairs showing that the expansion of health insurance coverage to adults under 26 years old, under the new ACA rule that children can stay on their parents' plans, has actually decreased emergency department (ED) use. Though notably studying a different population, this is the opposite of what the Oregon Health Insurance Experiment (OHIE) found, where expansion of medicaid coverage increased ED visits. For some reason, prior to the OHIE, the idea that expanding coverage would reduce ED use became conventional wisdom, but as Aaron Carroll explained back then, it makes more sense for expanded coverage to increase ED use--as he put it, "Improved access will lead to, well, increased access." Indeed, insurance coverage makes ED visits cheaper, so why would making something cheaper decrease demand for it? Proponents of the insurance-reduces-ED theory have been extremely vague on exactly what is supposed to drive that result, and I think this lack of an explicit theory has hindered empirical study of the topic.

According to the study McIntyre cites, some individuals who would have chosen ED visits when they have no insurance would instead opt for an alternative with insurance (it helps to think of this as a choice between ED and doctor's office, but for our purposes "doctor's office" is just a stand-in for anything other than ED, including no care at all). Let $B$ represent their budget set without insurance, and $B'$ is the budget set with insurance, and denote the choice of ED over doctor's office as $e$ while $d$ denotes the choice of doctor's office instead of ED.[1] The relation $C\left(\cdot \right)$ tells us which element of a given budget set the individual will choose (note that the choice can be a set of alternatives that the individual is indifferent between). Since the study showed that gaining coverage--moving from budget set $B$ to budget set $B'$--caused some individuals to switch from $e$ to $d$, this implies that we have $$e\in B~and~e\in C\left(B\right)$$ as well as$$d\in B'~and~d\in C\left(B'\right).$$

Now, the fact that the study observed a decrease in ED visits means we have $d\in C\left(B'\right)$ but $e\notin C\left(B'\right)$ for at least some individuals (if not, then the study estimate isn't causal). What accounts for this difference in choice between the two budget sets?

Suppose that both the ED and doctor's visit are affordable without insurance, so that $e,d\in B$, and that they are both still affordable with insurance $e,d\in B'.$ This would mean we have a contradiction--this says that the consumer simultaneously considers the doctor's office a better option than the ED, while also considering the ED a better option than the doctor's office! If you are familiar with the theory, I'm invoking the Weak Axiom of Revealed Preference (WARP) here. The only way to avoid a contradiction is if either $d\notin B$ or $e\notin B'$. Assuming WARP holds, whenever anyone says expanding coverage reduces emergency room usage, they are really making one (or both) of two possible empirical statements: that either 1| an uninsured person can afford ED visits but not the doctor's office, or that 2| an insured person can afford the doctor's office but not an ED visit. It would be helpful to know which.

Most studies--including my own dataset comparing ED and clinic visits--suggest that the ED is somewhat more expensive than the alternatives, so it would be a bit weird if $d\notin B.$ Weird, but not totally impossible if you consider, for example, that many doctor's offices will turn away patients that do not have insurance, regardless of whether they can pay in cash. If this is what's driving the result in this study, then we've uncovered a useful policy insight: we can reduce health costs by requiring doctor's offices to accept cash in lieu of insurance. Another possibility is search costs: maybe doctor's offices are actually more expensive than EDs once you include the costs of finding a doctor who will accept you--a process that takes time and effort on the part of patients. It may simply be that EDs are easy to locate, while doctor's are not. That too would be useful to know.

On the other hand, maybe $e\notin B'.$ Although it may sound weird at first that gaining insurance access can mean you can no longer afford to go to the emergency room, but this is actually realistic for some people. Even though insurers pay a portion of the ED bill, consumers are in turn paying the premiums that pay for that portion of the bill, so that having insurance does not expand one's budget set overall. What insurance does do, however, is substitute some elements inside the budget set for some elements outside of the budget set, which would be the case if, for example, insurers require a higher co-pay for ED visits than for the alternatives. On twitter, Seth Trueger offered this bit of evidence for this:

Thus, having a clear theoretical model helps elucidate empirical study of the impact of insurance on ED use. Yes, gaining insurance can reduce ED use, and ascertaining exactly why can reveal important policy implications.

[1] Note, $e,d$ are actually vectors in which just one of the elements represents the choice of healthcare, and the rest of the elements represent the choices of all other goods and services. We are really talking about choices between consumption bundles, which is why it is ultimately possible that getting insurance--whose premium is deducted out of the budget--can make bundles associated with ED use less affordable than without insurance.