Showing posts from November, 2008

Biblical laws

During the last few years I have slowly come to a conclusion: the reason for a lot of Biblical laws is not actually religious (as in, God has decided that something should not be done and that's that); it is the fact that non-religious commandments would have required explanations beyond the Jews' knowledge at the time or at least that they would have not obeyed them for long otherwise.

Take incest, since it does make for a rather glaring weirdness. Most people - an overwhelming number - consider incest to be "yuck"... the term cannot be discussed in polite company, only among porn freaks. When people ask "who did Adam and Eve's sons marry?" and receive the obvious answer "their sisters", they go "that's disgusting".

And yet... incest was not forbidden for a long time in the Bible. A quick search on Google reveals this page where we can see that Abraham married his half-sister, Moses' father married his aunt, and even when ince…

More on incentives

While watching a concert I started thinking about the amazing cooperation needed for such a task - there are dozens of people on stage, playing various instruments in very specific ways, and hundreds of people in the audience, whose only responsibility for a successful concert is to stay quiet during performances and maybe applaud in between. The performers are rewarded financially if they perform well, and they risk being fired if they don't. The audience risks being fined or even jailed if they don't behave.

Given all that distinction - disassociation on one hand, jail on the other - who do you expect to cause more intentional trouble on the average? My money is on the audience, of course [grin].

Market incentives work a lot better than force incentives. To me, this is a beautiful example of capitalism versus socialism. Even though the risks of disobeying the state are much greater than the risks of disobeying an employer or a business associate (there's no meaningful dist…

Socialism does not scale

I was deleting some spam and reflecting on the whole issue... as I was telling someone a few weeks ago, the problem with spam will be stopped when it will become a serious issue. Right now, the problem is distributed: a few benefit and a lot have to pay for it. (Just like in politics [grin].) Worse, there is a socialism of sorts in the relationship between internet providers: the sender doesn't have to pay the carriers for the traffic it sends through them. This messes up the incentives completely.

A simple scheme like a hundredth of a cent per email would make it too expensive to send bulk emails ($100 per million emails) while not affecting regular users in any way; legitimate companies would have already a large enough internet subscription that any email charge would be drowned in the noise; finally, large, voluntary mailing lists like RISKS would need something on the order of maybe a few dollars a day - again, irrelevant when compared with the price for the actual equipment a…

Extracting named variables from an array

My code uses the following pattern in a lot of places:

string[] array = GetSomeData();  Debug.Assert(array.Length() >= 3);  m_Member = array[0];  m_Password = array[1];  m_SomeOtherInfo = array[2];  

... and so on. This is happening often enough that I tried finding a clearer way of expressing it. I even asked a question on stackoverflow. The answers I got aren't bad, but I came up last night with a solution I like more. (It doesn't mean it's the best, and it does look a little kludgy, but I like the way my code looks.)

using System.Diagnostics;  publicstaticclass ArrayExtractor  {  publicstaticvoid Extract<T1>(thisobject[] array, out T1 value1)        where T1 : class  {      Debug.Assert(array.Length >= 1);      value1 = array[0] as T1;    }  publicstaticvoid Extract<T1, T2>(thisobject[] array, out T1 value1, out T2 value2)        where T1 : class      where T2 : class  {      Debug.Assert(array.Length >= 2);      value1 = array[0] as T1;      value2 = …