Free Software

I hear often that only if released under a so-called copyleft license is software truly free. This is usually presented in language that can only be described as Religious. Copyleft, without the religious language, is a class of licenses which require that distributed changes to or uses of the software must, themselves, be licensed the same way as the original. The idea is that this protects the users’ freedoms by preventing proprietary vendors from distributing nonfree software. This, as I hope to show, is misleading.

Suppose I am a proprietary vendor. My product is a slightly modified version of code that is originally under a permissive license. I have no intention of making most of my changes open source. Due to the original code’s permissive license, I suffer no legal or moral penalty for this, provided I include any necessary notices or copyrights along with my distributed product. The original software remains open source, presumably, so my customers have full access to its source code and can get a glimpse of how some of my product works. Some of my heaviest, most relevant modifications may have been contributed back to the open source community; it’s easier and cheaper than maintaining a fork when it causes no loss of competitive edge. Some of my modifications are closed source, so my customers have no access to them. My customers accepted these terms when they acquired the software. No freedom was lost in the exchange. They may have chosen the open source software of their own accord, but chose mine because it offered something they considered more important than the ability to inspect and modify its source code. This is part of the price.

Now, suppose I am a proprietary vendor. My product would have been a slightly modified version of open source code, but that code happens to be licensed under a copyleft license. I have no intention of making my changes open source. Due to the copyleft license, I have no choice but to write my own implementation which does basically the same thing. This inflates the cost of the product. The original software remains open source, but since I didn’t use it, my customers don’t even get a chance to see some of the inner workings of my product. None of my modifications were contributed back to the open source project; I had to write my own, incompatible version, instead. All of my product is closed source, so my customers have no access to any of its code. My customers accepted these terms when they acquired the software. No freedom was lost in the exchange. They may have chosen the open source software of their own accord, but chose mine because it offered something they considered more important than the ability to inspect and modify its source code. This is part of the price. However, they also pay a greater monetary value for the same product due to the extra work required to write additional, closed source software.

The latter scenario demonstrates some problems with copyleft, at least under the assumption that proprietary vendors are not going away any time soon. The users of the proprietary software pay more and have fewer freedoms when the vendor can’t use open source code due to a copyleft license. The open source project potentially loses valuable contributions from proprietary vendors by choosing a copyleft license. Nobody has benefited from the copyleft scenario. On the other hand, the software with the permissive license has more eyes and potential users due to its copyright information being included in the distribution and may have some contributions it wouldn’t have had without the proprietary vendor “stealing” it. The end users of the software also ended up paying less and retaining more freedoms.

Another common argument for copyleft I see is that vendors don’t deserve to be able to take for free and make profits on what open source developers worked so hard to give to the community for free. The contradiction is obvious if you read that closely. Open source developers give their work to the community for free. They do not expect compensation, and they will not, whether or not somebody else makes a profit from it. It simply makes no difference either way. This argument from the copyleft crowd is nothing more than a partially obscured form of vengeance. Is restriction from making a profit really something we should be calling “freedom”?

Just for the record, my current preferred license is the ISC license because it is permissive and very simple:

Copyright © 2009, Jake McArthur

Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.

Some Haskell Misconceptions: Idiomatic Code, Purity, Laziness, and IO

Laziness vs. strictness is a commonly misunderstood part of Haskell, as is how the IO monad is evaluated. I hope to clear some things up here.

One of the main features of Haskell is call-by-need evaluation. The idea is to avoid unnecessary computation by suspending evaluation until the result is needed. A suspended computation is called a thunk. When a thunk is evaluated, it is replaced in memory with its value, which may itself refer to more thunks. For example, say we have a Stream type.

data Stream a = Cons !a (Stream a)

Notice that this is always going to be an infinite structure. If we were to evaluate a stream strictly, we would run out of memory. Also notice the strictness annotation on the first component of the structure. It’s not required, but it makes the evaluation strategy explicit and may happen to also help GHC better optimize things in some cases. I am using strictness annotations not to make structures lazy or strict, but merely to indicate how the structures are inherently lazy or strict. Whenever I evaluate a Stream, its head will be evaluated immediately, but its tail will be suspended. This means we can use a Stream in a real program without running out of memory, which turns out to be very useful.

Contrast this with a Vector type.

data Vector a = Vector !a !a !a

Notice the strictness annotations. I placed them there because there are no circumstances where I would want to evaluate a Vector without evaluating its components. If I evaluate Vector 1 2 3 + Vector 4 5 6, then I want Vector 5 7 9, not Vector (1+4) (2+5) (3+6). Imagine what would happen if, using vectors with lazy components, I added an infinite a huge number of vectors together and only then evaluated the result’s components. I would be building three thunks which each store an infinite a huge number of values to add together for no reason, causing the computer to run out of memory. This has the same effect as strictly evaluating a stream.

Are you paying attention? Strictly evaluating a lazy structure and lazily evaluating a strict structure does the exact same thing! With strict evaluation only, we run out of memory on huge structures like streams. With lazy evaluation only, we run out of memory on huge computations like loops.

This parallel indicates pretty clearly that recursively operating on each element of a stream is an infinite loop. Stream is a control structure. It doesn’t exist to persist data across many parts of a program. It exists to feed data into a function one element at a time. In contrast, a Vector exists to persist an intermediate or final result of some 3-dimensional computation. In short, Stream is for controlling computation, and Vector is for storing data. This generalizes to lazy and strict types, respectively.

This can come as quite a shock to those who mistakenly believe that laziness is a way to save memory and computation at the expense of predictability. There may occasionally be positive performance side-effects, but that is not the most important and common use for laziness. Further, lazy evaluation is not unpredictable. It is just a model of computation, another tool for your toolbox, and if you understand it you will not be surprised by it. Haskell is not really a lazy language as much as it is a lazy-by-default language. It is simple and idiomatic to use strictness where your program calls for it. In other words, contrary to many complaints, strictness is not a low-level optimization technique. Strictness is a strategy for algorithms. As is always the case, if you change an algorithm, its time and space requirements will change, but it’s a high-level change. A strictness annotation or data structure redesign is not like dropping to C or assembly.

[Edit: Everything after this point, I would really like to just delete completely. I don't think it supports my points as well as I originally thought, and it's also just sloppy. I'm leaving it so you readers can at least see where I was going.]

The other important point I want to go over here is the way the Haskell runtime causes side-effects. [Edit: From this point on, take the things I say with a little salt. I am stretching things a bit to make a point without burdening the article with tedious details. It's practically true though.] A common misconception is that the IO monad represents impure code, that it is a hack to get around an inherent limitation in an otherwise pure language. The misconception, I believe, comes from a misunderstanding of what an IO function actually does. Many believe that IO is strictly evaluated, artificially, in order to preserve the ordering of effects, as it would be in an imperative language. In reality, the evaluation of IO is no different than of any other monad. The laziness or strictness of a monad’s evaluation depends only on the underlying data structure.

Before I delve too deeply into IO, I’d like to go on a brief tangent back to streams. I already gave one possible way to define a Stream data type above. There are other ways as well. For example, consider this one, loosely based on the definition used in the stream-fusion package:

data Stream a = forall s. Stream !(s -> (s, a)) !s

The first component of the structure is a step function which takes some state and returns a new state and a value, and the second is an initial state. This version is just as lazy as the one I gave earlier. The laziness, in this case, is captured by the step function. The next state and value are not computed until the step function is applied to the initial (or some other) state.

Back to IO. Here is a simplified version of the type of IO’s innards:

type IO a = RealWorld -> (RealWorld, a)

Notice the similarity to the definition of Stream I just mentioned. Here, the state parameter is RealWorld, and we don’t hold an initial state since it will vary from execution to execution. (RealWorld is not an actual value, of course. In this way, the IO monad may be considered a hack, but it’s a clean hack, and it works with the standard evaluation model rather than against it.) This is a lazy structure. Based on the definition, this is the expanded type of the bind function for the IO monad:

(>>=) :: (RealWorld -> (RealWorld, a)) -> (a -> RealWorld -> (RealWorld, b)) -> RealWorld -> (RealWorld, b)

And a direct function definition would look something like this:

(>>=) m k rw = let (rw', x) = m rw in k x rw'

So we pass in the RealWorld to the first action, then we pass its results to the second action. Pretty simple stuff, really.

Now to prove that it is lazy. Let’s say I have actions a and b, which I sequence with a >>= \_ -> b. What happens when we execute this? What we are looking for is whether b will be evaluated before the effect of a is performed. If it is, then we are evaluating strictly because we have to evaluate the whole action before it is useful. If it is not, then we are evaluating lazily because we are delaying computation until it is needed.

If we expand the operation a bit, we get \rw -> let (rw', x) = a rw in (\_ -> b) x rw', which we can simplify a bit to get \rw -> let (rw', _) = a rw in b rw'. Clearly, in order to evaluate b, we have to already have evaluated a. [Edit: augustss pointed out in the comments that this is not generally true unless b always uses its RealWorld parameter, so we have to assume that it does in this explanation. This is fine. If it doesn't use the parameter, then it doesn't have an effect anyway.] The only way to evaluate a, obtaining its return value and the new RealWorld state, is to perform its side-effect. Evaluation of the IO monad is indeed lazy. Also, the evaluation of the IO monad is, itself, what causes the side-effects.

Here’s the kicker: this evaluation model means that IO functions are pure. If you use the same IO function in two parts of a program, you may indeed get different return values, but that’s simply because they are parameterized on the RealWorld, which will be different every time. Referential transparency means that a function will always return the same value for the same arguments, but we will never pass the exact same argument to an IO function, so IO functions are, trivially, referentially transparent.

This brings me to my final point. There do exist some “lazy IO” functions (e.g., readFile, hGetContents, etc.), so called because they use unsafeInterleaveIO to return a lazy value before the effect that generates that value has been performed, treating the effects as the result of evaluating the value. In other words, these generate lazy effects. These values can perform effects in otherwise pure code. It is as if they have a hidden global reference to the current state of the real world which they refer to for evaluation; since this RealWorld value may be different each time the value is evaluated, we lose some predictability in pure functions. It is unfortunate that tutorials for beginners seem to encourage use of these functions because it appears to be a common source of misunderstanding and misuse.

So there you have it. Haskell is lazy by default, with optional strictness. Strictness is part of an algorithm, not a low-level optimization detail. IO actions are evaluated lazily. There is no impure hack in place for side-effects in normal IO actions. IO actions are pure. So-called “lazy IO” is not pure complicates things significantly. I hope this cleared some things up.

More Computer Random vs. True Random

A little while ago in #haskell on Freenode, one topic of discussion was random number generators. I wasn’t at my computer at the time, but when I came back, dejones had linked to a blog post about the patterns of pseudo random number generators. The author had made a PHP script which generates a random image using PHP’s rand function and compares it to one generated with true random numbers. The difference is significant.

dejones complained that there was no image for /dev/random on Linux, and I was curious about Haskell’s built-in random number generator, so I wrote a Haskell program to do the same thing and ran it on Linux. (As I type this, I am still gathering entropy for the /dev/random run. Just a warning, it’s still not done. I will be updating this some time tomorrow with the final image.)

Update: I never did gather enough entropy. I allowed the computer to run over 24 hours while I did all kinds of perverse things to the hard drive (old one, wouldn’t be devastating to lose it anyway), and still couldn’t gather enough entropy to generate the image. Perhaps I would fare better if I altered the program to use every single bit from /dev/random instead of just using modulo two of each character.

My original program tested Haskell’s random number generator. It looks like this:

module Main where

import Control.Monad
import qualified Graphics.GD as GD
import System.Random

imageSize = (512, 512)

imagePoints = do x <- [0..(fst imageSize - 1)]
                 y <- [0..(snd imageSize - 1)]
                 return (x, y)

main = do image <- GD.newImage imageSize
          plots <- randoms `liftM` getStdGen
          sequence_ $ zipWith (plot image) imagePoints plots
          GD.savePngFile "out.png" image
    where plot i p True = GD.setPixel p (GD.rgb 255 255 255) i
          plot i p False = GD.setPixel p (GD.rgb 0 0 0) i

I’m using the GD library to create a PNG image. I won’t bother explaining the code for this.

And here is what that creates:

So not too bad. Now let’s try Linux’s /dev/urandom:

module Main where

import Control.Monad
import qualified Graphics.GD as GD
import System.IO

imageSize = (512, 512)

imagePoints = do x <- [0..(fst imageSize - 1)]
                 y <- [0..(snd imageSize - 1)]
                 return (x, y)

main = do image <- GD.newImage imageSize
          devfile <- openFile "/dev/urandom" ReadMode
          hSetBuffering devfile NoBuffering
          plots <- fmap ((==0) . (`mod` 2) . fromEnum) `liftM` hGetContents devfile
          sequence_ $ zipWith (plot image) imagePoints plots
          GD.savePngFile "out.png" image
    where plot i p True = GD.setPixel p (GD.rgb 255 255 255) i
          plot i p False = GD.setPixel p (GD.rgb 0 0 0) i

And here is what it looks like:

This looks pretty similar to the output of Haskell’s generator, to me, but if somebody sees something I don’t then please do tell.

The code for /dev/random is exactly like the code for /dev/urandom, except we, obviously, use /dev/random instead! I would post the output image here now, but I can’t seem to gather enough entropy yet. I have to go home now. I’ll just post the image some time tomorrow. Sorry about that!

Update: As I mentioned in the update above, I never did get this done. I will get around to it eventually.

On the Utility of Functional Programming

I have been using Haskell for about a year now (wow, has it really been that long?), and I think I have arrived at a point that I can talk about how useful it actually is with some level of credibility. It’s a question that comes up very often, mostly among imperative-only programmers and functional neophytes, but even a seasoned Haskell programmer might ask it from time to time.

The Haskell community suffers from a serious problem. There are very few large projects written in Haskell. There are very few libraries. There is very little use of Haskell in industry. There just isn’t much proof out there that Haskell is all that superior for somebody who wants to actually get something done. Before I finally decided to learn Haskell, I had poked around on Google on numerous occasions looking for some sort of evidence that it would be worth it. My conclusion almost every single time was that Haskell is nothing more than an academic language for academic people. I found the small examples amusing, such as the quicksort algorithm expressed as a couple lines of dense symbols and small variable names, but I never found anything significantly larger or more useful. Later, I heard about darcs, a distributed source code management system. It was the first time I had even heard of such a thing, so I decided to give darcs a shot to see if I liked it better than Subversion. I used MacPorts to install it, which usually compiles from source. Installing darcs took an extremely long time since I had to compile GHC first, and once it was installed, it turns out that darcs was, itself, extremely slow as well. This was the first time I had knowingly used anything written in Haskell. I made up my mind. Haskell was very, very slow, and would never be anything worth learning except as a mind exercise. Only a long time later, after I had already learned Haskell, did I learn that it wasn’t Haskell but the darcs “theory of patches” algorithm itself that was so slow.

Over the next couple years, I became more interested in programming language theory, so, inevitably, I became interested in functional programming once again. I had heard that OCaml was very fast, and since it was impure I had the impression that to catch on to it would be more natural for me, an imperative programmer, than a pure language like Haskell. I started through a couple tutorials, but never felt like I was learning anything ground-breaking. The syntax was surely different from what I was used to using, but the thinking process felt too similar. This did not line up with what I had heard about the way functional programming is supposed to open up your mind and whatnot. But weren’t monads supposed to be hard to learn and confusing to use? It didn’t make sense to me that purity was worth anything. I finally gave in. I learned Haskell.

I have gained a lot since then. I learned all kinds of neat stuff, like monads, generic algebraic data types, type classes, functional dependencies, purely functional IO, pattern matching, purity, and types as proofs. To a nonfunctional programmer, this list probably looks like a bunch of gobbledygook, but each of these concepts has expanded my mind. It was difficult, especially having to read academic papers just to feel like I had some notion of what each of these concepts meant at all, but I now have a strong interest in learning more, and there is oh so much more to learn! Functional programming has led me to a wondrous path of discovery.

My programming skills have definitely improved. I am a better programmer in every language I use because of Haskell. I use Haskell most of the time now though. It’s really not that bad. I get a lot done. I feel better about the code I write. I could even write a large application in Haskell without feeling like I am limited in some way. Haskell is, without a doubt, practical for every day use, far more so than any of the imperative language I have come across.

The only problem is that I find myself dissatisfied even with Haskell. I have finally been exposed to the wide open world of programming language theory, and all the numerous flaws of the popular (and unpopular) languages of today. The fun of programming has been stripped away from me because I have read and understood so many papers detailing better ways of doing everything. I no longer want to work on large projects, even in Haskell. I just want to further improve my Haskell skills, make Haskell better, find a better language, or make my own language from scratch.

This is the root of the problem. This is why, I think, there are not so many large Haskell projects out there. It’s just too tempting to make your skills and development environment even better now that you have caught a glimpse of the light. This only leads you farther and farther from reality into academia. It’s a black hole. The Haskell community certainly could write significant applications in Haskell, we just choose not to do so because there are so many opportunities for improvement. It takes a great deal of discipline to focus exclusively on the implementation of a project without being distracted by “what if I …,” “wouldn’t it be neat if …,” and “if only ….” Haskell, while leaps and bounds more enjoyable and productive than any of the imperative languages I know, has made me dissatisfied.

We Are Lost

“We believe that the worst thieves in the world today and the worst terrorists are the Americans. Nothing could stop you except perhaps retaliation in kind.” – Osama Bin Laden, May 1998, ABC interview

Our nation is in one of its darkest times. Most Americans are aware of the controversy, but most do not realize the full extent of our corruption. We live in a time when our president blatantly lies to us, our media spreads false propaganda, our military destroys and occupies nations who did nothing to us, our government assumes we are traitors, and we don’t even think twice about it. Even the motives behind the attack on the Word Trade Center are a mystery to most Americans.

We Had It Coming

We are the aggressors in this war. We got involved in the Gulf War because we had alliances to maintain (which is something to cover in a future article). After the Gulf War, though, we kept about 5,000 U.S. troops in Saudi Arabia. From there, we enforced no-fly zones over Iraq and attacked them with cruise missiles and bombs. On top of all this, Saudi Arabia contains the most important sites in Islam, namely Mecca and Medina, and our presence alone, even ignoring our aggressive actions while there, was insulting to Muslims. We, as part of the UN, made Israel an independent nation, ripping the holy land from the hands of the Islamic Middle East, then we played the biggest military role in maintaining that independence, then we made such aggressive actions against Iraq, even during a “peacetime,” that there really is no other way to interpret us but as a threat to the entire Middle East. We clearly didn’t sympathize with the Muslims, and we clearly didn’t care. We had alliances and agendas to protect, all the while destroying everything they have.

Bin Laden made his grievances public, publishing fatwas in 1996 and 1998 urging Muslims to kill Americans, both military and civilian. The 1998 fatwa listed particularly clearly his grievances against the United States:

“First, for over seven years the United States has been occupying the lands of Islam in the holiest of places, the Arabian Peninsula, plundering its riches, dictating to its rulers, humiliating its people, terrorizing its neighbors, and turning its bases in the Peninsula into a spearhead through which to fight the neighboring Muslim peoples.

“If some people have in the past argued about the fact of the occupation, all the people of the Peninsula have now acknowledged it. The best proof of this is the Americans’ continuing aggression against the Iraqi people using the Peninsula as a staging post, even though all its rulers are against their territories being used to that end, but they are helpless.

“Second, despite the great devastation inflicted on the Iraqi people by the crusader-Zionist alliance, and despite the huge number of those killed, which has exceeded 1 million… despite all this, the Americans are once against trying to repeat the horrific massacres, as though they are not content with the protracted blockade imposed after the ferocious war or the fragmentation and devastation.

“So here they come to annihilate what is left of this people and to humiliate their Muslim neighbors.

“Third, if the Americans’ aims behind these wars are religious and economic, the aim is also to serve the Jews’ petty state and divert attention from its occupation of Jerusalem and murder of Muslims there. The best proof of this is their eagerness to destroy Iraq, the strongest neighboring Arab state, and their endeavor to fragment all the states of the region such as Iraq, Saudi Arabia, Egypt, and Sudan into paper statelets and through their disunion and weakness to guarantee Israel’s survival and the continuation of the brutal crusade occupation of the Peninsula.” – Osama Bin Laden, 1998 fatwa, translated by the FAS

Bin Laden also tried to clear up exactly why he thought it was appropriate to attack U.S. civilians instead of just military targets. It is too large to quote directly, but here is a summary of a small portion of Bin Laden’s Letter to America in 2002:

1. The fact that Americans are free means that you are responsible for the actions of your government.
2. American citizens fund the bombers, tanks, armies, and fleets because your government continues to provide funds for Israel using tax dollars.
3. The American army, who is also fighting alongside the Jews, is part of the American people.
4. The American people also fund the American forces.
5. Therefore, the American people are guilty.
6. Eye for an eye, tooth for a tooth.

I’m not trying to say that we could have even accurately predicted an attack, at least not the exact time and nature of it. I’m also not trying to say that I would have done the same thing that Bin Laden did. I’m trying to say that we deserved it. At least, that is certainly what Bin Laden thinks.

For more Bin Laden quotes about the reasons for the attacks, check out this page.

Lies

I’ve never been much of a conspiracy theorist, but I think it’s pretty safe to say that the Bush administration is lying to us.

“Americans are asking, why do they hate us? They hate what we see right here in this chamber — a democratically elected government. Their leaders are self-appointed. They hate our freedoms — our freedom of religion, our freedom of speech, our freedom to vote and assemble and disagree with each other.” – George Bush, September 20, 2001

To this day, the Bush administration supports this as fact. The terrorists just hate freedom. They hate freedom so badly that they would kill thousands of people just to hurt free people. The worst part is how many Americans believe this crap.

Just as bad as Bush is the mainstream media, especially televised media. Everything they report seems to be either a lie or an incomplete picture. They take their interpretations too far, and we end up getting something more like a national pep rally than news. Anybody who gets on the Internet and checks up on the facts from credible, first-hand sources can then decide for themselves what to make of the mainstream media’s interpretations, but, please, don’t depend on the mainstream, especially televised, media anymore.

Logical Problems with a War on Terrorism

There is something fundamentally wrong with declaring a war on terrorism.

“No group or nation should mistake America’s intentions. We will not rest until terrorist groups of global reach have been found, have been stopped, and have been defeated.” – George Bush, November 6, 2001

What are we doing in Iraq now? We certainly didn’t go after terrorism there. The WMDs that were reportedly there have not been found (as if mere possession should be cause for war), and all alleged cooperative ties between Saddam Hussein and al Qaeda have been found to be false, even before we invaded Iraq. If Hussein and Bin Laden were cooperating and there had been any WMDs in Iraq, there would have been a lot more dead American citizens than the under 3,000 lives lost on 9/11. We are now making plans to attack Iran. They haven’t even done anything to us yet, just like Iraq. We have not and are not stopping terrorism by invading these countries, yet we still are doing it.

Why is this happening? It’s because you just can’t declare war on subnational groups. If a nation allows our military to enter and track people down, they have surrendered to us. No effort in this war will be without nation-level conflict. These nations do not deserve to be torn apart by war. Terrorism is criminal, not national. It might be a nation’s responsibility to suppress terrorists on their own soil, but they have no responsibility to us for the actions of terrorists on our soil.

Habeas Corpus

Habeas corpus is the right to challenge your own imprisonment in the court system. If there ever was an important restriction on government enforcement of laws, this is it. Habeas corpus has been revoked for non-citizens, and it has been hinted by Attorney General Gonzales that even citizens don’t have Constitutional guarantees to habeas corpus, implying that we could potentially lose the right in the future. The wording in the Constitution (found in Article I, Section 9) regarding habeas corpus says that it is permissible to suspend habeas corpus in times of rebellion or invasion, but neither of those circumstances have arisen. Some might claim that we could be invaded, but that simply hasn’t happened. Terrorist attacks are clearly not an invasion; it is definitely criminal and violent, but the word “invasion” simply can’t apply. It does not warrant a violation of the basic principles of government.

Even despite rulings by the Supreme Court within the last few years protecting habeas corpus, the government continues to keep prisoners in Guantanamo Bay under the claim that it’s acceptable because it’s not on American soil. Is nitpicking like this really the way a government should be allowed to run? There is always a loophole in legalese, but it should be the government’s responsibility to be faithful to the underlying purpose of a ruling. If we can’t even make our own government do that, even with the backing of the Supreme Court, there is something very broken about the way we are doing things.

The Bush administration would like us to believe that the suspension of habeas corpus is the only way to combat terrorism. This just shows that they would rather make things easy than ethical.

Where Does It End?

We have certainly set a lofty goal:

“[…] through the sustained effort to compress the scope and capability of terrorist organizations, isolate them regionally, and destroy them within state borders, the United States and its friends and allies will secure a world in which our children can live free from fear […].” – National Strategy for Combating Terrorism, page 12

How can our government seriously think they can rid our nation of fear? This is one of the surest signs of our government using fear as leverage to control its citizens. This administration is gaining power by convincing us that we are afraid.

Losing Freedom

The Patriot Act is the most clear infringement on our freedoms. It allows the government to monitor us without our knowledge and without justification, to seize our property arbitrarily, to arrest us without charges, to hold us indefinitely without trial, and to arrest us just for talking about it. This is a clear violation of our rights as specified by the Bill of Rights in the Constitution.

But it gets worse than that. The number of police officers needlessly attacking civilians is increasing rapidly. Protesters have been arrested for reading the Constitution in public (the First Amendment, at that). An ad titled “General Petraeus or General Betray Us?” was officially denounced by both the Senate (72 to 25) and the House of Representatives (341 to 79) on the grounds that it was unpatriotic. In fact, most criticisms of the current administration are treated as treason. We don’t even actually own our own property, by current policy; the IRS does, and they will take it whenever they decide you aren’t contributing enough to the government on your own, despite the fact that there is no law or provision giving them the authority to audit you or even collect an income tax at all.

We Dropped the Ball

I urge my readers to very seriously look into these issues. You don’t have to take my word for any of this. Just read up on some historical context and keep an eye on the activities of Congress and the President. There is no excuse for allowing the nation to fall like this.

Subsidies Are Bad

Today’s post is going to be a fairly short one. I want to talk about government subsidies, the effects they have on the economy, and the effects they have on you and me. In particular, I make an argument that the presence of subsidies make us lose more money and result in sub-par products and services. As a case study, I will talk about corn, which is a blaring example, but my arguments should apply to all subsidization.

We started subsidizing corn for basically the same reasons as subsidizing anything else: we perceived an “unfairness” in the market, which appeared to be a market failure. The conception is that farmers are part of the hard-working poor, so they deserve more money. On the flip side, corn is a “basic commodity,” so it should be cheaply available to everyone. As it appears on the surface, the government should pay for some of it so we don’t have to ourselves.

Obviously, that logic has several flaws. Farmers are certainly hard-working, and they definitely aren’t wealthy, but they are not as dirt poor as they are often made out to be. More importantly, everybody does not need corn. Even more importantly, if the government pays for it, it’s no less expensive. We get higher taxes, so we are still paying the full price of it.

But unfortunately, the problems go much, much deeper than that. For one, this creates a cycle. Lower (apparent) prices leads to an increase in demand which, in turn, leads to pressures on the market to increase the prices some more, but since it’s already being subsidized, we might as well just subsidize it just a bit more. After all, this just demonstrates ever more clearly that corn is a basic commodity that everybody needs. Eventually, things will reach an equilibrium again. This is still a big mistake. Trust me, we are paying heavy premiums on our corn. We just don’t see them because they are paid with our tax dollars.

This apparent decrease in price results in a lot of side-effects, too. We use corn in everything we eat now. Corn is not very nutritious. Corn is in our food because it is cheaper to obtain than the actual food we think we are eating. Americans are fat, and this is the reason why.

Corn is even being used to make fuel! It’s not efficient considering the amount of corn and work required to make it, but the market price does not reflect this because of subsidies. Imagine what would happen if the government subsidized oil. That’s what’s going on with this corn ethanol movement. We get about 375 gallons of ethanol per acre of corn, and to use it we must burn about 15% more ethanol than petrol. Doing some math, that means one vehicle that might normally get 20 miles per gallon on petrol doing 1000 miles per month needs somewhere around two acres of corn per year to power it. Combine that with the fact that we are paying for that with taxes and you can see why this idea is bogus, and yet so many people are still touting corn ethanol as the future of fuel because they don’t see that there is more money required than the apparent cost of the corn. I don’t want to pay for the entire nation’s auto fuels, personally. I like to drive as little as possible anyway, so I would get nothing out of it. We would not even be considering this if not for the subsidization.

Briefly, here are my conclusions:

• Subsidies don’t solve the problems they seek to solve.
• Subsidies actually result in inflated prices.
• Subsidies cause consumers to purchase more than they normally would, more even than is beneficial or healthy.
• Subsidies loosen consumer value-per-dollar standards.

A Different Approach to Version Control

Version control systems as they exist today are quite dumb. They usually can only distinguish between two types of files — text and binary — and often are only able to do anything useful at all with text files. Focusing on text files specifically, the only change version control systems can detect is on a line granularity. Attempting to detect changes at a finer level would likely result in chaos due to the limitations of plain text algorithms. Even if your only change is to change the indentation of a line or rename a variable, the version control system can only see that the entire line has been edited, and dutifully replaces the entire old one with the entire new one in the repository.

The Problem is Semantics

Normally, this wouldn’t be so bad. It seems like just an implementation detail. So what if the internal storage mechanism is ever so slightly less efficient than it could be? They’re just text files. Or are they? The files in your projects are probably mostly structured source code. These are not “just text files.” They follow a very strict formatting convention, the syntax of the language, and different kinds of changes have different syntactic and semantic meanings. Sometimes line breaks are good points to partition a source code file. Sometimes you can even rearrange the lines in a file while preserving meaning, but usually not. For a simple example of the problems caused by considering lines atomically, consider the following snippet of C code:

if(x > 0)
  y = 1;
else
  y = x+1;

What if you want to add z=27; as part of the else block of the code? Obviously, you would have to add brackets if you want to insert it as a separate line, so now the code looks like this:

if(x > 0)
  y = 1;
else {
  y = x+1;
  z = 27;
}

In another branch, let’s say that you have added x++; after the entire if-else block. So in that branch, it looks like this:

if(x > 0)
  y = 1;
else
  y = x+1;
x++;

Let’s say you want to merge these two branches. If you have ever merged two branches in a repository before, you probably can already see where this is headed. For a version control system that is only aware of changes to entire lines at a time, the final result of the merge is ambiguous. If we assume that the VCS can magically tell what is syntactically valid (although it probably can’t), then there are three possible results from the merge. One is the result that you probably intended:

if(x > 0)
  y = 1;
else {
  y = x+1;
  z = 27;
}
x++;

One looks like this:

if(x > 0)
  y = 1;
else {
  y = x+1;
  z = 27;
x++;
}

And one looks like this:

if(x > 0)
  y = 1;
else {
  y = x+1;
x++;
  z = 27;
}

The latter versions have completely different meanings from the former. This could serve as an argument against ever using if-else blocks without brackets, but even better would be if you didn’t have to restrict your programming style just to cater to a picky VCS.

The Solution

Don’t represent the code as a plain text file! It’s the wrong abstraction for source code. Represent it as a parse tree or syntax tree. I know this sounds infinitely more complicated than simple diffs at this point, but bear with me.

Let’s take our example from above. First, we need a simple tree data type for the C concepts we use. Here is a very basic one (with a lot of details absent that even our simple example could have benefited from had I taken the time to demonstrate then, such as finer granularity for expressions) in Haskell syntax:

data Statement = If Exp Exp Exp
data Exp = Statement Statement | Compound Exp Exp | ExpStr String

So, basically, all we know about C syntax with this is if statements and the fact that expressions can be chained, terminate with Strings (not the best idea), and can be statements (which isn’t really true, but it makes the example simpler).

Here is what the first version of our example program would look like internally:

Statement (If (ExpStr "x > 0") (ExpStr "y = 1") (ExpStr "y = x+1"))

Changes can be represented as functions that work by pattern matching. Here is the first branch:

Statement (If c t f) = Statement $ If c t $ Compound f $ ExpStr "z = 27"

Here is the second branch:

Statement (If c t f) = Compound (Statement $ If c t f) (ExpStr "x++")

Obviously, an internal representation like this could lose certain formatting details, such as whitespace. However, this is probably more of an advantage than a disadvantage. No longer are visual formatting changes going to affect merges or even visually clash due to differences in team members’ styles. The version control system will always normalize the style on update. You could even customize this output locally. Very slick.

There are other implications to this which may lead to evolutionary developments. I will save them for a future post.