Jan. 25th, 2014 | 02:48 am
But it can't be banned! That's the whole point of Bitcoin. (The fact that cryptocurrencies cannot be banned, and the social implications thereof, are explored in A Lodging of Wayfaring Men.)
You know what else can't be banned? Bittorrent. Peer-to-peer filesharing of music and movies.
But P2P networks didn't cause the death of Hollywood. Actors and musicians still show up for work and make movies and albums. (The very same actors and musicians go home at night, go online, and listen to music without paying for it.)
P2P filesharing caused innovation: now we have the iTunes Music Store, we have Spotify, we have Pandora. We have innovated new business models for people to keep making music and movies.
If P2P filesharing didn't destroy music, but rather created Spotify, then Bitcoin won't destroy taxation. What will it create? I have a guess. Let me explain.
First, imagine a world where voting happens through transitive delegation rather than traditional representative democracy. (There are many voting systems. I'm proposing a new one which relies on computing social graphs.)
In traditional representative democracy, one decides independently among a fixed pool of candidates. One votes for one's preferred candidate. This model assumes that one is conversant with the issues. No cheating! Voting booths are designed to keep anyone from peering over our shoulder – and they keep you from peering over anyone else's.
That's fine if you're an educated voter, but educated voters are the exception, not the rule. The fact that most people vote a party ticket shows that most voters don't bother to acquaint themselves with the issues and optimize their vote; they satisfice, so they can get out of the voting booth and go home for a beer.
In fact, I suspect that many voters just call up the friend they know who (a) is more of a politics geek than they are, and (b) they trust to represent them – or at least to resemble them.
Transitive delegation voting acknowledges that reality, and lets you basically hand your vote to your politics-geek friend. That friend collects your vote together with any other delegates, adds it to their own vote, and decides how to pass on the resulting pool of votes. That pool can get split up and handed on, multiple times, like tributaries joining a river, until the votes find their way to someone who decides not to delegate the votes to anybody else, but rather to count them directly in a bid for election. That someone, in the traditional world, would be your Congressman or your Member of Parliament. Here, they're just the root node of a directed acyclic graph – a giant tree, arbitrarily deep. If multiple candidates are vying for the single electoral seat, then the man with the biggest tree wins. (You can implement coalitions this way too, if you want.) And the candidates can at any time drop out of the race and concede their pool to their nominee.
This voting model would not have worked before the Web 2.0 world. Just counting ballots doesn't work in this system. It's fundamentally a social graph, and it needs computers to tell you who won.
Why add all this complexity? Because we're still trying to solve the Bitcoin problem. Bear with me: the votes aren't one-man-one-vote. Rather, they're one-dollar-one-vote. "Dollar voting" has been criticised in the past as an implicit artefact of capitalist democracy. I'd like to make the situation explicit, with a twist: the number of votes you get to cast is equal to the number of dollars you paid in taxes.
In fact, delegating your votes is equivalent to delegating your tax dollars. You put your tax dollars into a system over which you exercise only limited influence. (That's the definition of a tax: if you could choose how to spend it, it wouldn't be a tax: it would be a donation.) If your candidate loses the election, your tax dollars go to the guy who won. So public policy still reflects the will of the majority – and societies still get revenue to pay for public goods – but the process by which we achieve these objectives is a little different from the current setup.
In this world, people have an incentive to pay taxes even if they're using Bitcoin. The more taxes you pay, the more likely it is that your candidate will win, and the more likely that your plan for public spending will be followed, not someone else's. The less you pay, the more likely you won't get your way.
How can societies compel a minimum taxation rate? Easy: everyone could define, as one of the rules of the game, that if you didn't pay a minimum percentage of your audited income, then your vote ratio would suffer a discount: instead of one-dollar-one-vote, you get one-dollar-half-a-vote. Smooth to taste.
That restores all the characteristics of taxation revenue through a voluntary scheme that works with Bitcoin, not against it.
If the Internet begat P2P which induced Spotify, then the Internet begat Bitcoin which may one day induce transitive delegation tax-dollar voting.
Sep. 2nd, 2013 | 08:02 pm
The key to innovation and technology is people.
There is now a global marketplace as goods, services, capital, and knowledge become even more mobile. These developments have accelerated the integration of regional markets. However, in order to benefit from globalization, countries must ensure that their laws and institutions facilitate the global flow.
Businesses now source for talent and opportunities globally. They invent, collaborate, or acquire technologies and capabilities globally to ensure their competitive edge. As the Internet makes more markets contestable, businesses in Asia must compete on this platform or be swept aside. The national counterpart to businesses that source globally is a society that welcomes foreign talent. Societies that will succeed are those which easily assimilate foreigners. Silicon Valley is such a place. Not only is it "color blind" and uniquely meritocratic, it has a culture that draws newcomers in. Asia's businesspeople must acquire these attributes and be globally literate.
We must continue to attract as many able and talented people from China, India, the region, and from developed countries, to add to our team. Without this input of foreign talent, even the U.S. could not have been so successful. Their atomic bomb owed much to European talent fleeing from Hitler in the 1930s and 40s .... Even the American space program owed its start to the German rocket scientist [Wernher] von Braun, who invented the V bomb in WWII and was captured by the U.S. army as the war ended. He was taken to America. Since then, every year, thousands of talented professionals, academics, researchers, and writers are drawn from the UK and EU [European Union] to the U.S. because they are made welcome in America and given the facilities for their research or become successful in their professions or business. This has enhanced America's high performance. If America, with 280 million people, needs to top up with talent, Singapore, with 3 million, must do so, or we will be relegated to the second or third division.
We draw our talent from only 3 million people. A short mountain range is unlikely to have peaks that can equal Mount Everest. You need a long mountain range like the Himalayas unless you are a special people like the Jews in Israel. With a population of four million Jews, they have the talents of a population of more than 40 million. Everyone knows that Shanghainese are the brightest and sharpest of people. But few know why. It is because, for over 150 years, ever since it became a treaty port for the foreign powers, it has drawn the ambitious, energetic, and talented from the Yangtze Delta, Zhejiang, Jiangsu, and other provinces along the river, a catchment of some 200--300 million. Even though Shanghai regularly loses leaders to Beijing, it still has an abundance of talent, because it does not depend only on the 12 million in the city itself.
Jul. 6th, 2013 | 12:38 pm
When software engineering was young, we patterned the field on architecture. Writing code, we thought, is just like constructing buildings. That's why we have "software architects" who organize "development" projects to "build" products.
We started with "waterfall" construction: first we plan it, then we build it, then we test it, then we throw it over to the wall to the client who has to live with it.
We quickly learned that iterative models work better. Software is more fluid than architecture. Labour, not concrete and glass, is the precious resource. And software is unpredictable in a way that architecture is not. Most of the DNA of any new building is shared with millions of other buildings. Due to the sums of capital at risk, architecture tends toward conservatism. But new software naturally tends to be original – after all, if the software you want already exists, you copy it and use it; you don't rewrite it.
The problem with doing something new and original is that you're fumbling in the dark. Show me a client who thinks they know what they want, and I'll show you a client who, after they see the finished piece, will realize that they wanted something else.
The architect, builder, and writer Christopher Alexander has made a seminal contribution to two fields: architecture and software. His Design Patterns has influenced an entire generation of programmers. This influence is recorded in Richard Gabriel's Patterns of Software.
And now, in Alexander's most recent work, The Nature of Order, Alexander articulates a way of building that, apparently, folk builders have always known, but that modern architects of the 20th century had forgotten.
It turns out that the waterfall software construction of the 1970s and 1980s had a lot in common with what Alexander calls the "big-block" architecture of the 1970s and the 1980s. Both were a mistake. Both arose from the historical high point of mechanistic modernism. Both, with any luck, will be laid to rest in the next few decades.
In software, the path has led to agile development: XP, Scrum, TDD, CI, etc.
In The Nature of Order, Book 3, A Vision of a Living World, Alexander articulates a parallel path for architecture. (pp 501–504)
What is needed as an underpinning for a kind of construction which is truly based on making—hence is responsive to feedback, and allows shaping to occur dynamically during the making process, consistent with the fundamental process. This requires a new form of construction management contract. The construction manager is not paid by profit, but by a fixed amount of money (we typically use 20% of hard cost, or about 17% of the contract). The rest of the money, 83% of the construction contract, is also a fixed sum. It is the manager's responsibility to do the most he possibly can to make a beautiful building, within that money. The system has open books. Clients are able to see the checks, payments, of every penny. Changes can be made (and are expected) inside the total of the 83%, without change-orders. Any time a change is made, within the total of the 83%, and the money needed is obtained by economizing on some other part of the contract. The construction manager's job is to juggle the money within the 83% so as to get the most and best quality of biulding from the given sum. To make this possible, the manager also has the right to reduce certain specifications in the building to compensate for others which have been increased. Thus there is a trust relation. The client knows that he will get just what this money can be stretched to pay for. But he has to be realistic about his expectations, and cannot take the conventional adversarial approach to the construction manager.
My colleagues and I have invented (and used and tested) several types of contract which work like this. The contract type I have used most frequently is the one published on pages 92–98 of The Mary Rose Museum. Many others have also been tried in our company and worked. These contracts are downloadable from natureoforder.com, and patternlanguage.com. All deliver a building for a fixed price and leave the architect/construction-manager as much freedom as possible to do the best job he can do with the available money.
The parallels with Agile Development are obvious.
It is a point of pride with Agile that Agile developers can accurately estimate the schedule needed to implement a feature. This estimating capability allows the Agile process to restructure the power relationship between developer and client.
In traditional software development, the client asks for a set of features to be built by a certain date at a certain price. Grizzled veterans will instantly recognize this as a classic no-win triangle, and gruffly respond: "good, cheap, fast: pick any two".
In Agile development, the client sets the schedule and the budget. The client also prioritizes the list of features. But the developer estimates how many of the features on that list, arranged in priority by the client, can be built within that schedule and that budget. And the client has to live with that estimate. You want more features, you need to allow more time, or pay for more developers.
It is delightfully appropriate that Christopher Alexander, who inspired software with patterns, should be the first to rediscover the Agile dynamic in architecture.
Jul. 21st, 2012 | 09:16 pm
A Big Data idea came up at the Singapore Quantified Self meetup last week. Working title: the Fishbowl Flag.
Problem 1: There's a lot of data about me out there – public transit tap-in and tap-out logs; medical records; utility statements; geolocation records. In a sense it's "my data" because it's about me, but in another sense it's not, because it lives on external servers which I have no access to.
Problem 2: Researchers working with public data are limited to pared-down, anonymized datasets. The limits exist because the public haven't given informed consent to publication.
Solution to Problem 1: Imagine a Data Transparency Act that requires all public and corporate records of individual data to be made available to that citizen. In the Web 1.0 era that data would be compressed into a zip file and shipped grudgingly upon request, much as Facebook offers a zip archive of your account. In the cloud era that data would be made available in the cloud not just through a dumb webpage but through some sort of JSON-standard API. UP Singapore's data wiki and Microsoft's Project Nimbus give a sense of the datasets available.
Solution to Problem 2: Imagine if you could instruct all those data sources to share your data at the anonymity level of your choice, with the recipients of your choice. Even if only one Quantified Self geek out of a hundred muggles signed up to flip their fishbowl flag, a lot of data would be liberated. One might even choose to share one's data only with other people who had similarly signed up to share their data: you show me yours, I'll show you mine. First the early adopters do it, then the network effects take over and everybody volunteers.
In most societies the Fishbowl Flag would require opt-in. But under the theory of "libertarian paternalism", and under the theory that Singaporeans are unusually sanguine about state intrusion into the private sphere, it might be possible for Singapore to be the first country in the world to turn the Fishbowl Flag on by default.
I invite the Quantified Self people to continue this discussion here on my interblog.
Jul. 16th, 2012 | 01:07 am
20120716-01:01:55 mengwong@cny2:~% perl -ple 's/(?<!a)b/a/g'
abb correctly becomes aba
But bbb wrongly becomes aaa.
20120716-01:02:17 mengwong@cny2:~% perl -v
Nov. 17th, 2011 | 03:31 pm
To all startup-minded 31337 hax0rz out there: a pop quiz!
This winter, would you rather be shoveling snow or lying on the beach?
Hint: it is easier to type on your laptop while lying on the beach.
But, you ask, does the beach have wifi?
In Singapore, it does!
It is therefore my pressing duty to share the news that the JFDI–Innov8 2012 Bootcamp, just two months away, is now accepting applications!
We follow in the inspiring footsteps of Y Combinator and TechStars. And we expect 10 to 15 teams to start in January's batch.
We've already recruited winning teams from Startup Weekends from around the region, from Manila, Melbourne, Delhi, and Singapore.
Each team will receive S$15,000 in investment and intensive mentoring. Over the course of 3 months, by hook or by crook, they grow according to Lean Startup principles, building toward an investment of $500,000 to $1,000,000 on Demo Day in early May.
We're now accepting applications from around the world so if your startup would like to spend three months in Singapore, working shoulder-to-shoulder with other passionate, talented geeks, the following link will move appreciably closer to your goal.
A quick point: we are not interested in startups that aim to build the next location-based mobile marketing startup with elements of social gamification. There are harder problems out there: please read our manifesto for more.
Oct. 28th, 2011 | 12:36 pm
Miles make sense in all kinds of situations: for people who fly a lot, they're a loyalty program, designed to bias you toward your favourite brand.
But when credit cards offer you mileage points in return for spending real dollars, behaviour can get wacky.
In particular, people start buying things they wouldn't otherwise have bought, just so they can get the miles.
Of course, sometimes it makes sense to buy miles directly, with cash. That establishes an exchange rate: the street value of an airmile in dollars, and of a dollar in airmiles.
The Dollar Auction paradox shows that under the right conditions people will be willing to bid beyond an item's street price just to win an auction.
I wonder what experiments could be designed to explore if credit card miles are related to the dollar auction.
In a sense the credit card airmiles people have already run all those experiments. they know exactly what they're doing.
It's a classic game mechanic.
Imagine someone gave you S$10,000, and then offered you a choice: an additional S$100, or AU$50?
To be clear, S$100 is worth more than AU$50.
But I suspect a lot of humans would go for the AU$50.
And i think it's based on the fact that humans are omnivorous.
After you've eaten three oranges, what would you prefer: a fourth orange, or a chicken thigh?
A koala wouldn't make that mistake. A koala converts everything to eucalyptus leaves.
Oct. 8th, 2011 | 12:43 pm
The job of traders in markets is to diminish the predictability surplus by capturing alpha in a competitive way. The inherent difficulty arises because the game is reflexive.
Expanding this notion to "computational cosmology" – Nick Bostrom's Simulation Argument – I found myself waking up this morning to a forcefully argued thought experiment in which our current universe arises as the outcome of a dispute between godlike entities who themselves have run out of predictability surplus about what would happen: "i bet you're wrong." "no, i bet you're wrong." "fine, let's find out." "okay, run it."
The interesting part of this argument was that adjacent virtual universes may exist, in which the boundaries between deterministic and predictable fall slightly differently. But our own universe ends up dominant because the determinism / predictability tradeoff attains a local optimum, perhaps maximizing some property, such as information density: this universe maximizes the amount of new information generated per unit of simulation cost. We're a giant random number generator.
Of course, Douglas Adams got there first. The answer is 42.
Aug. 17th, 2011 | 06:24 pm
May. 5th, 2011 | 01:48 pm
The most important table is Zenattributedentity; it is denormalized; multiple object types are flattened into a single table, distinguished by their z_ent entity type column.
Z_ENT = 11: shared notebooks (zsharename)
Z_ENT = 12: note (ztitle)
Z_ENT = 13: notebook (zname)
Z_ENT = 14: attachment (zfilename)
Z_ENT = 15: saved search
Z_ENT = 17: tag
This SQL query finds all excel attachments.
SELECT "open $HOME/Library/Caches/Metadata/com.everno
After using DBIx::Class::Schema::Loader's dbicdump to extract the schema,
dbicdump -o dump_directory=/Users/mengwong/lib/perl/
The following DBIx::Class code in Zenattributedentity.pm will create some of the appropriate relationships:
# the has_many through the Z12tag table won't work if the Z12tag table doesn't type its columns.
__PACKAGE__->has_many(tag2note => 'Evernote::Schema::Result::Z12tag', "z_17tags" );
__PACKAGE__->has_many(note2tag => 'Evernote::Schema::Result::Z12tag', "z_12notes" );
__PACKAGE__->has_many(notebook2note => 'Evernote::Schema::Result::Zenattributed
__PACKAGE__->has_many(attachments => 'Evernote::Schema::Result::Zenattributed
Other relations like "a note belongs_to a notebook" are left as an exercise for the reader.
A separate table, Z12Tags, records note/tag relationships.
Please don't contact me with requests for assistance; try the Evernote forum or leave comments in this post.