Metablog

Wow, even I wouldn’t have picked a name that corny. And what a terrible color scheme.

But it looks like they’ve come from exactly the same perspective I have. Hat tip to Will Pearson from the SL4 mailing list. I’ll comment later.

In lieu of a bunch of mindless rambling, I’m going to spend {whatever time today I spend on Debate Modeling, and not watching the Chronicles of Narnia}*, dissecting this this typical blog discussion to try to figure out what sort of elements can be atomic enough and yet still capture all of the good content (as opposed to the unwanted content). Actually, it’s not an entirely typical discussion. It has less noise, and more controversy. It does have a few people playing tug-of-war about presenting evidence, each presuming dishonesty on the other’s part, but there’s only one thread of that, and it’s pretty explicit, and I need to think about that stuff anyway.

* These braces are generic phrase grouping markers. Not standard english, but oh so useful in writing long, nested sentences. They’re not needed often, but when they are, it’s really annoying to rearrange things to work with The Man’s English instead of just using them. You don’t want to support The Man, do you?

When a developer is put on a project without clear requirements, and without someone from whom to gather requirements, they’re being put into a very difficult position. If they just make arbitrary decisions about the design and start implementing, it’s likely there will be a lot of wasted effort, both through extra, unneeded things being implementing, and through the wrong things being implemented that consequently have to be done over. So that they don’t have to do over a bunch of work before the product is ready, they stop before developing and try to plan it out. But they don’t have the information to be able to plan anything, so they try to talk to other people to find it out, and they end up waiting around while the others, who might have a meager idea of the requirements, get back to them. In the meantime, the process is repeated on some other subissue, and because humans can only do so many things at once, the poor project developer ends up forgetting about the first issue.

So what’s the solution? Those who know the requirements should be very available to answer all these questions right when they come up. In the absence of such people, can individual “initiative” make up for this? This “initiative” will lead to a lot more work being done, but a relatively small portion of that work will meet the requirements. So it’s not clear whether the extra work is worthwhile. It would depend on the relative value of the time of the various participants, and of the nature of the decision to be made about requirements. (If it’s a relatively minor point, it’s definitely not worth stopping work over). If the people that know the requirements don’t have time to communicate them thoroughly to the developers when they first start development, that doesn’t change the fact that they’ll have to communicate them eventually. So there’s really no point in it not being done immediately.

So what if it can’t be done anyway? What if the people who know the requirements are simply inaccessible most of the time, for some reason? What should be the top priority for our abandoned developer when he has run out of clear directions? There are a few choices here. He could choose another project or issue within the project whose requirements he has better access to. He could attempt to do some more generic version of code that meets the reqeirement that can be specialized later. (Which is often overwriting the software.) He could simply pick arbitrary directions to go with the code.

Any three of these options could be the correct choice in a given situation. If the project has plenty of room before its deadline, then working on another project of slightly lower priority whose requirements are already known is probably the best choice until the requirements for the first project can be clarified. The developer should be sure to write down all of his current state so that when he comes back to the project, or when someone with requirements knowledge becomes available, work can be resumed without wasted additional effort to recover a working memory of all the issues that were being ruminated upon before.

If the project needs to be done soon, however, and the requirement ambiguity can’t be handled simply by doing generic code or adding configuration options–deferring the decision but not holding up development–then the developer is faced with the harsh reality of having to write code inefficiently, because the most efficient use of his time would still leave the project behind a deadline, even if other projects were able to advance more quickly. (And let’s face it. Those “other projects” are really easter eggs, eh?)

It all really comes down to the exact nature of the ambiguity. If taking the wrong direction would mean a complete waste of time–even considering that writing the code would make it easier to write similar code in the future, even from scratch–then the project has to be more or less stalled. But if the decision is something that might not really matter anyway, or even if it’s something that the customer won’t get to mad about when they discover how wrong it is, then an arbitrary choice might not be so terrible.

But god damn, I hate arbitrary choices. Maybe I just need to get over it.

I should think about how this applies in the case where the project is a hobby and the person who knows the requirements is also the developer, but is unable to find the energy to discover the requirements.

While I really like the language Lojban and really wish there were three hundred hours in the day, it’s occurred to me recently that it should be possible to modify English to give it one of the advantages Lojban currently has over it, and let English still be pretty comprehensible. (A much more minor modification than, say, Loglish. In fact, Loglish isn’t really modified English so much as it is modified Lojban.)

The advantage I have in mind is the lackadaisical tense system. You don’t ever have to specify the tense of a verb (selbri) unless you so desire. If you don’t specify, the tense is left up to context, including especially the tense you specified for any previous selbri, but also allowing other considerations.

Now, there are a few problems with trying to port over such a system to English. For one, a whole bunch of idioms are tied more closely to their sounds than the tenses of the verbs in them, so changing the verb tense could make them hard to recognize. And then, there’s just a general weirdness about not having verb tenses in English. But it’s still worth a try, for sure. So what technical issues are there?

There’s some decisions to be made. How do you choose a verb tense to be the neutral tense? And how do you show positive tenses? It’d be nice if English had a simple infinitive, like say Spanish. That would be a natural candidate for the neutral tense. Alas, English’s infinitive is unwieldly for frequent use. (”English’s infinitive to be unwieldly for frequent use.”) One could take the most common verb tense, the present tense, first-person conjugation, and just use that everywhere. Or, maybe, the infinitive minus the “to”. Then when one wants to switch out of the neutral tense, one just uses some specific other tense. What happens if you want to use a non-neutral present tense? Not sure. Maybe “does” as an auxiliary verb? One could borrow “ca” (pronounced “sha”) from Lojban, but that’s not amenable to being immediately understood. Then again, the whole practice probably would take a bit of knowledge to read (and get the full meaning), so perhaps that’s not too much knowledge to require.

Another approach is to use a single form of every verb, and use markers for all indication of tense. That avoids the ambiguity problem between the neutral and non-neutral forms, but makes the text even more odd sounding if the markers are the English auxiliaries, and increases the learning curve a lot of Lojban’s (more flexible and much more numerous) markers are used. But perhaps a bit more odd-sounding text is a reasonable sacrifice in this case, and the more comprehensible to the uninitiated, the better. So let’s see what this technique leads to. I’m going to go with the “infinitive minus ‘to’” form, and translate the first paragraph of this post. For past tense, I’ll use “did”, for future, “will”, and for progressive of any time, “has”. I think I’ll try using “is” as a present tense marker, as the word “is” isn’t used as a verb, since “be” is the infinitive version. Bolded regions indicate things I’m just not sure about.

While I really like the language Lojban and really wish there be three hundred hours in the day, it has did occur to me recently that it should be possible to modify English to give it one of the advantages Lojban currently have over it, and let English still be pretty comprehensible. (A much more minor modification than, say, Loglish. In fact, Loglish be not really modified English so much as it be modified Lojban.)

OK, so that was interesting. “Like” in the first sentence “sounds” present tense, even though it’s neutral (having no marker). And “isn’t” becomes “be not”, a very awkward construction, that probably takes one a moment to recognize. What is the present tense equivalent to “has occurred”? “has been occurring” would be present progressive, but that’s not quite the same. The future tense would be “will have occurred”. There’s the present tense, completive, “has occurred”, as in “this breaking news just in: such-and-such has occurred.”

I’m not even sure what the verb is in the phrase “should be possible”. “Be” sort of sounds like it, but what the hell part of speech is “should” in that position? An auxiliary verb? If so, does it belong there as is? Well, I guess I’ve reached the end of my explicit knowledge of the English tense system.

That was pretty fun.

It’s a bit of an unfortunate aspect of blog commenting that to really participate in a good discussion, a few conditions have to apply, and those can make it hard to participate as much as one might like and still lead a balanced life. For instance, most large blogs on my list have a ratio of good, substantial, thought-provoking comments to vapid, insipid, incomprehensible, flaming, or otherwise undesirable comments of around 1:3. That’s average. Less than about 1:8, I can’t really stand ever going through the comments. (In fact, those blogs tend to have main content that I don’t enjoy as much either, but whatever.) But the blogs with higher ratios also tend to be those with fewer readers, and discussion sort of just ekes along slowly there, since there’s not enough input to keep it going. There aren’t enough readers for there to be any dedicated readers.

And sometimes, even if the ratio is OK, the pace of discussion is just too fast. Commenters that have more time than you to dedicate to commenting come to dominate. This is a natural outcome of the dynamics of commenting. The more prolific commenters have a higher tolerance for long comments threads than the average commenter, so the more commenters you have, the higher percentage of your commenters will be the prolific, dedicated type.

So, if you want to participate at all, you have to both ignore all the comments you don’t really care about dealing with* and also take the time to read and sometimes respond to a sometimes large number of other comments. It’s quite a tiring prospect.

* And that takes as much effort as dealing with spam does, at least–except that blogs don’t have bayesian filters on their comments threads, unless you use an RSS reader with that feature and the blog you read supports comments.

So I’ve been wanting to learn math for a while. Really get a handle on calculus, learn some probability theory, and who knows what next? But I’m not terribly great at it. I have problems dealing with the algebra. Managable problems, for sure. But I have an itch. Why not make a program that lets you manipulate algebraic equations without error? I know exactly what form such a program would take.

And it’s not quite this. And it’s nowhere near this or this. Those programs can do a whole bunch, but they don’t do what I want to do. So what is it I want to do?
Continue reading »

Why do people get mad about spam? It’s kind of funny to watch sometimes. Paroxysms of anger. Holy quests to eliminate it. Rightous screeds proclaiming the utter evil that are spammers. Frankly, it’s not the sort of thing that you would expect from a lot of the intelligent people whence it comes.

So what’s the explanation? I believe it all rests on a simple, but basic, misunderstanding. They fail to view the fact of spammers as an inevitable feature of the e-mail system as it stands. (And it is.) Instead, they treat spammers as a member of a social group (users of e-mail) that have broken the codes of that group. Social ostracism, and all that entails, is the natural and instinctual reaction.

But it’s a bad reaction. It’s not rational. Because of the systemic and inevitable nature of spam, and the hugeness of the system, no social sanctions are going to do any good. Social ostracism is worthless, because spammers don’t heed the codes of e-mail.

Spam is nothing more than a disease of the internet. A parasite. They don’t get mad and indignant at viruses do they?

So where do they get this misunderstanding? It’s an attractive proposition, sure. We’re all one big happy family. And spammers are just some of the less desirable members of that family. They can be reformed, or banished. These are all intuitions that evolved in an environment where pretty much anyone we had contact with was either someone to run from, someone to kill, someone to apply social pressure to, or someone to heed to social pressure from. In the modern world, on the other hand, we have interactions with a lot more people than we are in a position to apply social pressure to. Not everyone has really adapted to this reality yet.

Maybe it’ll come with time.

I know most who study very hard on any subject (especially multiple subjects) eventually come to this realization at some point. I’ve known that for a long time. I’ve long been familiar with Socrates’ aphorism, that I know nothing, except for the fact of my own ignorance*, and I’ve never disagreed. But now’s my turn to really learn what it means.

I can’t learn enough about everything. More importantly, I have to set explicit boundaries to what I’m going to choose to spend my time learning about, and what communities I participate in. Otherwise, there’s no end to things. I have to, arbitrarily, decide what I want to accomplish, and decide what’s not necessary to do those things. Then I have to cut out what’s unnecessary. When I’m reading along about something, and some sentence strikes a chord with my curiousity, I’m going to have to stop instead of clicking on that link or opening up a Google tab, and I’m going to have to consciously choose to ignore my curiousity, and say “I don’t need to know this to accomplish what I need to; I’m not going to look into it.” It will hurt, badly, but I will have to do it.

One of the expressions of my insatiable curiosity is a desire to become a writer. As a writer, I can firm up incremental blocks of thought that are then published, sometimes even with feedback. It makes progress seem real. But the progress isn’t real. The firmness of a given essay, if it ever comes, is illusory. I’ll never know enough to write a good essay, except maybe on one subject.

Because I’m such a “meta” person, (thus the name of the blog,) I think I do have some valuable and relatively new ideas about communication in various forums. At least, I seem to consistently be the most insightful person when the topic comes up. And I’ve been wanting for years to try to focus harder on that topic. Perhaps, now that I’ve nominally come to realize my limitations, this will start to happen. May it be so.

* OK, so I went to look this up, and apparently there’s no exact place in the dialogues where this quote comes from, even though I seem to distinctly remember it from a past reading. Oh, well. At the least, it’s a consistent theme in the various Socratic dialogues.