[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lojban] Response ro Robin's "Essay on the future of Lojban"
I call upon everyone involved in this discussion to reread the policy
http://www.lojban.org/tiki/Official+Baseline+Statement
What I am saying makes no sense without close reference to that document.
The policy explicitly says that "let usage decide" is NOT applicable
until AFTER the byfy completes the 4 tasks assigned under "THE LANGUAGE
DESIGN COMMISSION" is the policy statement (read the second sentence
under INCORPORATION OF PRIOR STATEMENT).
The policy ALLOWS the byfy to consider usage in making decisions, but
its primary purpose has always been to make decisions.
As I see it, the problem has been that the procedures as written by Nick
and maintained by Robin
http://www.lojban.org/tiki/BPFK+Procedures
have largely conflated tasks 1 and task 4 of the byfy effort, raising
the standard for task 1 so high as to make it unachievable, with all
aspects of the language defined and justified to the utmost, whereas the
intent is only that change-by-fiat be justified.
task 1 alone would require that byfy sections include
Expanded cmavo definitions. This should be considered a top priority in
all sections where it is relevant (which is just about all of them),
because the current cmavo definitions suck.
and possibly
Examples of usage in every fashion that the items discussed in the
proposal could feasibly be used, especially of cmavo. I'm serious about
this: lack of examples is one of the major places the current cmavo list
falls down. There needn't be an example for every single cmavo, but
there certainly should be an example for every class thereof.
but all of the rest should be dealt with separately as change proposals
under task 4 and not even considered until after task 1 is done.
While usage is one reason to consider a change under task 4, point 7
under task 4 makes it clear that changes are not limited to what "usage
has decided", merely allows that a pattern of usage is one possible
argument for a formal change. So "let usage decide" isn't applicable to
either task 1 or task 4.
---------
The core of Robin's complaint seems to be:
Here's what I think leads to the BPFK being such a black hole of people:
* It will accept as much time and effort as you give it, which is scary
and daunting
* Similarly, how do you know when the BPFK is done? The goal is
basically perfection: to define every relevant part of the language
well enough to call it done, all at once, forever. Again, scary and
daunting.
* What happens if you get it wrong? People are going to be stuck with
it forever (usage decides after all). Scary and daunting.
* So, people stop working on it. But everyone involved knows that this
is the most important thing in Lojban, so not working on leads to guilt.
* If thinking about Lojban makes you feel guilty, scared and
overwhelmed, you're going to stop thinking about it.
And I contend that his second point is the problem. The assignment for
byfy was NEVER "perfection". I thought the assignment was to achieve
"good enough", and that CLL brought us pretty close to "good enough",
but that a couple of areas like the cmavo list needed to be brought up
to a standard comparable to the rest of the language documentation.
Somehow, things morphed into byfy being required to define the language
so as to answer all the questions that anyone will ever ask. I never
supported that mission, and I'm not entirely sure how it came into being.
(It seems that Robin WANTS that to be the mission, but I'd like to see
the more limited job done first, before forming an opinion on that.)
The procedures were imposed by the jatna, and Robin can change them
pretty much any time he feels them counterproductive. The baseline
policy is harder to change, and should be.
After byfy finishes the four assigned tasks, it (actually the
membership, because the byfy has only delegated authority, but I can't
see the membership overruling byfy) is supposed to declare a "final"
baseline, whereupon the "let usage decide" policy would take effect. At
that point, no change proposals would be considered for at least 5
years. The question is left open as to what would happen after the 5
years, so the apocalyptic "forever" of Robin's complaint really isn't
"forever".
I would argue that the 7 years since the baseline policy was approved,
with no major proposals other than xorlo, shows that a 5 year freeze is
hardly onerous. I suspect that there have been a few changes in how
people have used the language, certain usages becoming more popular and
others fading away. That is what was meant by letting usage decide; it
has happened without byfy making any formal decisions.
But in any event, that is how things are supposed to be AFTER byfy
completes the 4 tasks.
----------
I can come up with one interpretation that makes sense to me about
Robin's extended focus on "let usage decide" in the context of a
discussion of the future of the language, and that is a concern for the
long term after the byfy tasks are done.
I would rather see that debate take place after the 4 tasks are done and
the baseline declared, and I would rather that the debate be limited to
debate in-language. This was the sort of thing Robin and others were
pushing for several years ago when they tried to have the annual meeting
conducted only in Lojban. It is also part of the formal policy.
LLG makes the commitment, however, that should it ever decide to
establish any such procedures after the 5 year period, that all
discussions of possible changes will occur solely in the Lojban
language, ensuring that only actual users of Lojban will participate
in any decision process.
I envisioned, in effect, that byfy would be supplanted or supplemented
by the entire Lojban-using community. Whether some sort of official
body like byfy would make a formal decision is something the community
can decide then. We don't need to decide this now, do we?
---------
The above is the core of my argument. I am going to try to apply it
*briefly* to what Robin said in his essay, mostly my limiting what I
quote and respond to.
As I see it, we have two options: # Throw out the BPFK, and let usage
decide from where we stand today # Throw out the idea of usage deciding,
and re-tool the BPFK to not have these problems
throwing out the byfy is clearly untenable, since people want decisions
to be made, and someone has to make those decisions.
throwing out the idea of usage deciding shouldn't be at issue now, but
clearly is, at least in Robin's mind. I don't see anything in Robin's
proposal that really eliminates the problem.
It would perhaps not be a big leap to have the rump-byfy described in
the baseline policy, which has the assignment post-baseline to certify
various levels of compliance with the baseline, have the additional
assignment to suggest answers to questions left unresolved in the
baseline, when people ask. One would hope that few such questions would
impinge upon the baseline (i.e. require change in what has been
documented in CLL and the various lists). Such answers would not be
part of the baseline itself, and would have limited prescriptive force.
And if any debate by the byfy about the answer were conducted
in-language, it would be perfectly compatible with what I stated above
about MY goal for the "let usage decide" policy. After the 5 year
freeze, such prescriptions could be formally incorporated in the
language definition, but really, I would expect that this would only be
necessary or appropriate if people have found the pronouncement useful.
I remain concerned about
We're basically demanding that every newbie have a gigantic level of
dedication just to use the language effectively. We might as well put
up a sign that says "Warning: hard work within".
which seems to argue for a minimal specification (the section is
entitled "!! Lojban Is Too Well Specified", while
The other big issue is that newbies are looking for a logical language.
I know I was. Part of what "logical" means is "rigorous and well
specified".
and the later
The formal
definition of the language must be complete for their sake: otherwise
you end up with many tiny islands of unique interpretations,
seems to require an endlessly expanding specification, where every usage
question is formally pronounced upon, and the answer becomes part of the
spec, and that no one is really a master of the language until they have
mastered all of this endlessly expanding spec, seeking after an
impossible "complete" specification.
Robin says that newbies want all the answers to be documented in the
spec, and if they aren't
Naturally, they expect there to be an answer to just about
every question they have about the language (and I agree!). How are we
to then turn around and say, "Oh, but the very obscurest, hardest bits
of the language? Yeah, you get to figure those out yourself.
I can't figure out how Robin wants to resolve this dilemma. Throwing
out "let usage decide" doesn't do so. Putting the onus on byfy to
decide everything gives a decision, but the documentation adds to the
amount that the newbie has to know in order to be competent.
I see an analogy to formal law. We have a constitution, which sets
forth general principles. Then we have a set of statutes that define
the law to some arbitrary degree of specification. Most people manage to
be law-abiding without having memorized the constitution, and only on
occasion seeking out exactly what the statutes say. They may turn to a
lawyer or a bureaucrat to ask the latter, but their answers aren't
official. Instead, we have a layer of hundreds of pages of regulation
for each law, and then we have court cases to formally make decisions
that are binding interpretations of that law. The complete
specification of law includes the constitution, the statutes, the
regulations, and all of the court decisions ever made regarding all of
these. Only specialized lawyers come close to a mastery of even a
segment of "the law", and no one masters the whole.
I don't think Robin wants Lojbanists to require the skill and training
of a lawyer to speak the language. So at what level does the formal
specification stop? When do we say "you need to know this much, but
beyond that point we *aren't* going to tell you that you are wrong
provided that people understand what you say"?
If we let usage decide, if no-one can ever legitimately tell another
Lojbanist that they're doing it wrong,
That is not and never has been the policy. Even after the baseline, per
the policy, the rump byfy or some similar group is still charged with
certifying up to five degrees of baseline compliance. They don't tell
someone that "they're doing it wrong", but rather that they aren't
complying with the baseline. I would expect that most people will be
satisfied with the decisions of an "LLG-Approved Author/Editor", but
they will want textbooks written to the standard of "Baseline-Compliant".
The formation of the BPFK itself is another example: when the community
realized that the baseline was invalid, and that the language needed
some polishing, what happened? Did people simply start changing the way
they used the language? Did they let usage decide? No. Overwhelmingly
the community voted/agreed to form a body (the BPFK) from which to
officiate the language. I only recall one or two people even seriously
suggesting letting usage decide.
Actually, what happened was that *I* realized that the baseline was
invalid. We broke the rules stated in 1997. The rest of the Lojban
community was going along blithely unaware of this until I brought it to
their attention. They were indeed "letting usage decide" insofar as
anyone was actually using the language. I don't think any decisions
from byfy were needed for la .alis to be written, and it was completed
before xorlo was decided, IIRC.
*I* proposed the byfy and the policy statement as an answer
to the problem that *I* recognized, and convinced the Board of the
seriousness of the problem, and it was approved with much debate but
IIRC only minimal change by both the Board and the membership.
That policy incorporated the text about letting usage decide, so I
cannot imagine why anyone would feel a need to "seriously suggest" what
was already in my proposal. I'm not sure I recall even one or two
people seriously suggesting to *remove* the "let usage decide" language
until now, though I think there was some discussion about "life after
byfy" with general acceptance that there would be a rump byfy that would
fill the certification role (which is somewhat less than a prescriptive
role).
...
rather than people getting attacked
for not conforming to the CLL, which is what actually happens.
Robin seems to disapprove of this, even while saying that it is a sign
of people rejecting "let usage decide".
But earlier, he says:
If we let usage decide, if no-one can ever legitimately tell another
Lojbanist that they're doing it wrong, we will end up with some very
confused newbies;
Obviously people can and do tell others that they aren't following CLL,
which is one level of "doing it wrong", and there is nobody to say that
such "telling" *isn't* legitimate. The rump byfy will have the
authority to tell someone officially that they are "doing it
sufficiently right", and has implicit authority to insist that
LLG-official stuff comply with an appropriate certification standard.
What we've learned from the free software movement, though, is that
groups that all equally contribute to a great project almost never
actually happens: you get a very small number of people (usually one)
with near-total executive power,
Been there, done that. My executive power was tempered by my
willingness to consult with pc, Cowan, and Nora (and others as they came
and left the Board).
But I think things reached the point where one person could not
effectively exercise executive power over all of the business, the
language-definition, and the leadership of the community.
Robin and others booted me out, apparently because I wasn't delegating
that power enough (or fast enough). Robin now seems unhappy with the
result.
or you get crap, or you get a dead project.
I'd like to think that the current situation is neither of these, though
obviously we can, and need to, do better.
The other thing we've learned from the free software community is that
it is possible to have strong authority without screwing the community.
I HOPE people learned that from my tenure in office.
Projects
like Linux and Perl make it clear, though, that it is possible to give
control over major, hard decisions (like breaking backwards
compatibility) into the hands of a few people without anything horrible
happening. These groups still take lots of input from the larger
community.
In LLG, we call this the "membership", and they in turn have delegated
control over some decisions to "the Board" and others to "the byfy",
while approving general policy guidelines (the statement) that govern
the latter.
The idea behind usage deciding seems to be that people will be able to
figure this out as they talk, and settle on one or the other. In
practice, though, how could you do that? Imagine the confusion that
could result when speaking English if someone didn't think that "the
car" implied that there was actually a particular car. You'd be having
totally different conversations, but how would you ever figure out where
the problem lay?
Umm. In point of fact, that is EXACTLY what we do, and the power of the
human mind is sufficient so that even if a young kid calls every
4-legged animal "doggie", people still manage to understand the kid.
And everyone who has read a schoolkid's English essay (or a Usenet post)
knows that people use English words and grammar in far more deviant ways
than "the car" not meaning a particular car - and are still understood.
Once you figured it out, what would you do? You'd grab a dictionary and
show the other person to be wrong.
Not in most cases, because in most cases we don't carry a dictionary
handy. And when we do - well, I have plenty of experience on Usenet
trying precisely that tactic, and having the person cuss me out, or
ignore me, or sometimes even agree with me but then repeat the error in
succeeding postings.
Formal officiation is part of how
natural languages resolve these sorts of things.
French has its academy, but the French ignore academy pronouncements
when it suits them, and Quebecois French is apparently quite different
from usage in France.
English is entirely informal. It has a multiplicity of "style guides",
and different publishers subscribe to different guides, and some have no
formal style policy at all. No one would accuse Americans of speaking
"the Queen's English". (I'm not sure that the Queen does either, but who
would tell her if she didn't? %^)
Computer languages often resort to formal standards, but even
implementations of computer languages are often lacking in compliance
with formal standards, where such standards exist, and there is very
little one can do about it except to shop for another compiler.
This lead to a bunch of
conversations that started with "Are you using xorlo?". If we ever let
usage decide, you can expect much more of that sort of crap, as people
divide into camps behind their favorite proposals.
We actually addressed that, in MEX, among other places. SEI, and ti'o
in particular, were added to allow multiple conflicting sets of
mathematical rules to coexist. (Chapter 18, section 20)
xorxes says that using xorlo is almost always transparent. I believe
him, so I can't see why I would ever ask someone if they are using
xorlo. Beyond that, I can't comment, since I don't understand xorlo %^)
On the other hand, I can imagine someone using an experimental cmavo I
don't know, and my asking them what it means. I would hope that anyone
who creates such a cmavo considers how one would answer that question,
preferably in-language.
I also can't see any change to byfy or to the policy that would
eliminate this problem other than completely forbidding experimental
usages, which is unenforceable even if we wanted it.
If I want natural, growing, living languages, I know where to find them.
If we never reach that stage, Lojban will never be more than a toy.
This goes hand in hand with letting usage decide: since everyone's
usage is valid, it doesn't really make sense to set goals.
More importantly, everyone's goals for the language are valid. Those
who don't need Lojban to be a "natural, growing, living language" have
to coexist with those who want it to be.
But I think Robin is referring to "design goals". byfy has the
authority within the policy statement to consider specific design goals
when considering changes.
Certainly
large-scale changes were enacted by the Lojban founders at various
times. But after the baseline, the only way to make such changes will
be to make your own fragment of the language, and hope it catches on.
The alternative is to have byfy impose large-scale change on the
community by fiat, when it suits them, and hope it catches on. The fact
that xorlo was approved, and then the membership reinforced that
approval, and yet people are apparently still asking "Are you using
xorlo?", it should be clear that imposing large-scale change on the
community is a problem no matter how it is done (and we knew that
already in the JCB era, because every such large-scale change caused
many people to leave)
It completely disenfranchises participants based solely on the time of their birth.
I can't think of a polite response to this, so pretend I said something
rude and you'll probably be right.
I know that the actual issue here is to avoid having to re-learn the
language all the time, but that's a straw man: people deal with drift
in natural languages all the time. All we need to do is make sure
Lojban doesn't drift noticeably faster.
"Drift in natural language" = "natural, growing, living language", which
I thought you disparaged above. In any event, drift in natural language
does not involve "large-scale changes"
I haven't yet seen anyone complain
that it was too much to learn or that the language was changing too much
for them to want to learn it.
Actually, you have. From me (and to some extent from Nora). Which is
why I have never made an attempt to learn xorlo. I'm relying on xorxes
claim that I don't need to learn it %^)
The case of .ai nai really exemplifies the need for goals ''for the
language itself''. It has been noted that ".ai nai broda" is exactly
equal to ".ai na broda", as .ai nai is currently defined,
Not really true. But usually effectively true because of the semantic
nature of "ai". The same is generally true of .ianai and .ienai But
this is obviously a technical issue tangential to your essay, so I will
stop.
This lack of consistency
(essentially, an exception in our beautiful,
supposed-to-be-exception-free language) really bothers some people, and
they think it needs to be fixed. Others think past usage is more
important. And... that's where we've been for at least a year now.
What you are saying is that there is NO consensus on the design goals of
the language, or at least on their relative priority, even within the
limited circle of those actively participating in byfy.
Of course, achieving such consensus on design goals has never been part
of the byfy process (and arguably shouldn't be, until tasks 1-3 are done
and byfy seeks to implement task 4, where it becomes relevant). The
procedures have been propose - hurry up and vote - move on to the next
topic, which is precisely how consensus political decision *doesn't* work).
With no criteria to weigh the options by except "finish defining the
language", who is to say who is right?
Right now, byfy is to say. They have the authority to define the status
quo. Regarding change proposals under task 4
The byfy can choose at its discretion whether to abide by the intent
of earlier language designers or by the strict wording used, and can add
clarification or modify the wording based on its decisions.
Arguably, the only design goal that is not subject to possible change by
byfy is the only one made explicit in their charge, regarding single,
unitary meanings for words. There are probably other design goals
specified in CLL, but byfy has the authority to change CLL as part of
task 4.
* The BPFK then finishes the dictionary, to whatever level of
specificity can be acheived fairly quickly, which I expect to go
relatively smoothly because of the goals themselves, and the lack of
needing to worry about past usage very much.
byfy shouldn't be worrying about past usage at this point. Tasks 1-3 do
not involve considering past usage, only existing specification.
(though if there is usage, one would hope that it would inform discussion).
Task 4, dealing with proposals for change, does involve considering past
usage, as part of the justification process for change.
** Every once in a while, a vote should occur to place a list of changes
officially into the language. This means documentation must be complete
(see below), and there shouldn't be any feeling of all-or-nothing about
it. We can make some things official while other things are not
completely finished, and we can make mistakes and fix them in a later
round (hopefully not many and no big ones).
The baseline policy regarding "let usage decide" agrees entirely with
this, with the explicit provision that after the baseline is declared,
no such vote will be even proposed for 5 years (and the implicit
provision that when such a vote takes place, actual usage will be
considered).
I don't think that the membership or the byfy should be making anything
more than the most nebulous plans for that time, because the mindset
post baseline will likely be quite different from the present mindset
(the stated considerations in the above quoted paragraph make that
clear), and planning major policies that won't come into play for 5
years "completely disenfranchises participants based solely on the time
of their birth".
The BPFK is also responsible for evaluating conformance to particular
versions of Lojban, as requested.
The existing policy statement pretty much covers this, and it is not
clear what Robin wants changed about the baseline compliance task. (What
he describes in his proposal seems qualitatively different from the
stated policy, but I am not sure why he feels the stated policy needs to
be changed.
* It is also the duty of the BPFK to answer questions about Lojban posed
to it that cannot be answered via the extant documentation, and to
record the answers publicly, and possibly roll the answers back into the
official documentation.
This is the one explicit change that I have absolutely no problem with,
if it is part of defining the post-baseline "rump-byfy" task, with the
proviso that "roll the answers back into official documentation" needs
to be consistent with the policy on only "every once in a while"
"placing a list of changes officially into the language".
A page of approved typo corrections and clarifications doesn't bug me.
The lack of a multi-year period without prescriptively imposed change,
(and without any discussion of such change, except in-language) would
bother me greatly.
I think most of the rest of Robin's proposal should only be considered
after tasks 1-4 are done, and I'd love it if the attempt were made to do
that consideration in a Lojban-only forum (even if it means I
disenfranchise myself by failing to acquire the skill to participate
effectively in such a forum).
lojbab
--
You received this message because you are subscribed to the Google Groups "lojban" group.
To post to this group, send email to lojban@googlegroups.com.
To unsubscribe from this group, send email to lojban+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lojban?hl=en.