[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lojban] Response ro Robin's "Essay on the future of Lojban"
On Thu, Apr 08, 2010 at 01:55:23PM -0400, Robert LeChevalier wrote:
> I call upon everyone involved in this discussion to reread the
> policy http://www.lojban.org/tiki/Official+Baseline+Statement
I think the success of that policy speaks for itself.
> 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).
One place where we differ is that I no longer think usage should
decide *ever*. Unless the BPFK becomes totally controlled by a pack
of drooling morons, of course usage will be acknowledged and
respected, and the BPFK may *choose* to promote usage to the status
of officialness, but we should not let the language drift via usage.
It should be well specified.
I also don't think that describing the lanugage is what we
should be doing. We should be *declaring* the language.
> 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.
The problem is that:
1. defining the cmavo requires making sense of them, which
routinely leads to discovering contradictions and having to make a
decision
2. no-one wants to do work that will shortly be made irrelevant; if
we *know* there's a problem, defining the current state and then
discussing the change at some future date feels like a waste of time
> 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.
I shouldn't have to say this after 7 years, but: it's not going to
happen. I explicitely refuse to try to document things we are later
going to change without working on the changes as part of the
documentation, and other BPFK members have told me they feel
similarily.
In other words: I refuse to do part 1 of
http://www.lojban.org/tiki/Official+Baseline+Statement by itself.
If you can find people who do not so refuse, let me know.
> 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's very simple: basically discussion that has occured in the BPFK
has *immediately* turned into a detailed discussion of what,
exactly, the cmavo actually means: what the CLL says it means, how
it's been used, where contradictions exist, whether what the CLL
says makes any sense, and so on. The only time anyone does
*anything* in the BPFK is when they're having discussions like that.
The point of the essay was to say "OK, great; this is how people
around here actually work. Let's harness that."
If what you want is a simple description, written by people who are
going to simply ignore the CLL's contradictions and actual usage and
so on, umm, you need to find a completely different group of people.
> 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".
It's been, what, 15 years since the first baseline was declared? I
think "forever" is quite an apt description.
> 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?
We need to do *SOMETHING* now.
> >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.
I conflated two issues: (1) the forever-in-the-future when the BPFK
is done and usage rules the land, which I think is a bad idea and
(2) the built-in respect for the current state, implicit in the
ordering of the line items in section 4 of
http://www.lojban.org/tiki/Official+Baseline+Statement ,which I
*also* think is a bad idea.
> 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
Absolutely the opposite; it argues for a complete as possible
specification, so newbies do not have to work to understand how to
use the language.
> (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 then 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.
Yep, that's pretty much what I have in mind.
> 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 expect there to be varying levels of documentation; a beginner's
book, the CLL, the online super-spec, that sort of thing. How much
people choose to learn is up to them; you can speak perfectly good
Lojban without ever opening the CLL, even now. But when people *do*
have a question, there should be an answer, somewhere.
> >rather than people getting attacked for not conforming to the
> >CLL, which is what actually happens.
>
> Robin seems to disapprove of this,
I neither approve nor disapprove; I acknowledge that this is how
Lojbanists actually work, and suggest we embrace that fact.
> 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.
I am unhappy only with the stagnation of the BPFK, which you have
not participated in at all to my knowledge. Everything else is
going just fine, IMO.
> >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.
I disagree. You can have a large, popular language without it being
subject to random, unfettered linguistic; see, for example, French.
> >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.
Perhaps you should go find me one of those people, then, because I
can't seem to find any.
> 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.
No, we don't; the policy statement's ordered list in section 4 *is
the problem*.
> The fact that xorlo was approved, and then the membership
> reinforced that approval, and yet people are apparently still
> asking "Are you using xorlo?",
I don't know where you got that impression; I haven't heard anyone
say that since the approval. Which was my *point*: the formal
approval of xorlo suddenly made everything run more smoothly.
> >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 %^)
You weren't speaking the language *before* xorlo, so that's not
really interesting or relevant to me.
> >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.
Task 4 explicitely orders the basis for such decisions. That
ordering *is the problem*.
> >** 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).
That was very much not my understanding; my understanding was that
after that 5 year period, usage *always* wins, even if it's
illogical or stupid. That at that time the BPFK is not empowered to
over-ride usage in the interests of the overall design goals of the
language, whatever those might be.
If I am misunderstanding, then I assure you I am not the only one to
so misunderstand, and clarification is needed regardless.
> 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 really don't understand why you have this hard-on for the freeze
period? What difference does it make? People are coming into the
language all the time; some will be during the freeze, and some
won't. How does it help anybody?
People who want to learn to speak the language seem to deal just
fine with changes; people like you and Nora who don't don't seem to
be able to catch up even over the 5+ years the language *was*
frozen. Seriously: I don't get who the freeze is supposed to
benefit, or how.
> 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).
I explicitely refuse to spend time writing definitions based on the
current documentation without stopping to consider whether that
documentation makes any sense internally. This means I refuse to do
tasks 1-3 without also doing task 4. Task 4, and its ordering of
requirements, was what caused the deadlock.
You seem to think that everything is fine with the BPFK's charter as
is, yet clearly it isn't, because we've been stuck for 5 years on
{.ai nai} (yes, really, on *just* that issue, for that long).
I'm very, very close to being past caring, but: what do *you* want
to do to fix it? (and would this involve you yourlself actually
doing anything? because it if would, you might as well keep it to
yourself; I simply don't trust you to actually do any BPFK work.
Too many broken promises)
-Robin
--
They say: "The first AIs will be built by the military as weapons."
And I'm thinking: "Does it even occur to you to try for something
other than the default outcome?" See http://shrunklink.com/cdiz
http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/
--
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.