Friday, May 28, 2010

Tax for holding intellectual properties

There are a few parallelisms between intellectual properties and real estate properties: They last indefinitely. They exclude public access. They cost law enforcement.

However, real estate properties are localized and the effect of any single property on general public is limited. (There could be exceptions, for example, the property of the only water source within a large area of land.) However, intellectual properties are generally universal since new knowledge is build on old. The effect of their restriction can grow and propagate to all aspects of public lives. (Imagine patent on wheels, clocks, or electricity; Copyrights on all classical texts or musics; Or, trademarks on commonly used words.)

So, under a necessary condition that such an intellectual property is to be granted to a private holder, proper tax should be assessed to recover the cost to the public. This can include loss of free access, blockage of innovation, and cost of property right enforcement. It is easy to imagine the growth of such cost will generally speed up in time. Thus, the tax rate should increase with the time that such a right is held.

Alternatively, the creation of intellectual properties can be compensated and rewarded up front and their access should be made free to the public. The only difficulty is in determining the value of these properties. As naive this may sound, it has been practiced since the incipiency of science, where scientific knowledge gained is open to the public and scientists are rewarded by fame and status for the impact they made. Similar difficulty exists in judging the value of a research, but the current system based on consensus appears to be working.

Friday, May 7, 2010

Processing command-line arguments in C++

I just released arg as a standalone library under LGPL. It's a command-line parser for C++ programs. The aim is to keep the programming effort in adding command-line processing to C++ programs at a minimum. There are several considerations in this direction:
  1. simple and intuitive syntax
  2. requiring no redundancy
  3. localized codes
  4. extensibility
  5. completeness
The simple example as given on the arg homepage,
#include <arg.hh>
#include <iostream>
int main(int argc, char ** argv)
        arg::Parser p;
        int n;
        p.parse(argc, argv);
        std::cout << n << '\n';
        return 0;
should be very close to the minimum as far as 1. goes.

Programming is for a programmer to describe what he wants the computer to do. Per point 2., he should not be asked to provide the same information multiple times. (Well, maybe except in situations where multiple confirmations are required: "Launch the missile. Please have the missile launched. Yes, I really want you to launch the missile! Launch the *&^%$ missile!!!"; Computer: "Aborted on Error: missile != *&^%$ missile".)

When working on an item, e.g., adding a new command-line option, the programmer won't be asked to go to multiple places in the codes if 3. is observed. While common and frequent usages should be supported and simplified in the library, new and novel applications will ask for 4. Finally, some rare, special, and/or tricky applications will demand 5. in the arsenal.

Thursday, May 6, 2010

Push forward

As an organic matter, one requires constant exertion to maintain tension. The process ends when tension is out.