[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lojban] Response ro Robin's "Essay on the future of Lojban"

Bob:

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.)
A language is a system of rules mapping between sounds and meanings. By that sensible definition, Lojban is nowhere near "pretty close to good enough". The so-called 'grammar' doesn't deserve to be called a grammar, since all it does is give meaningless structures to phonological strings. CLL does make a start on the definition of the rules of Lojban, but only a start. 
Some users of Lojban don't realize how meaningless or semantically indeterminate their utterances are. Some, I presume, don't care. Others are frustrated. And perhaps in a small Lojban-speaking enclave of Argentina, they've created their own much more complete dialect.

I would have felt much more vehemently about all this, had I not become convinced that Lojban can never be Logban3, i.e. can never be a usuable logical language; and since I care about a usable logical language, the failures of Lojban pain me less.

Robin Lee Powell, On 09/04/2010 02:47:

On Thu, Apr 08, 2010 at 01:55:23PM -0400, Robert LeChevalier wrote:

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.


Exactly. Declaring the language.

What users do should be neither here nor there: the language should be a tool, consisting of a set of sound--meaning correspondence rules, available for whatever use people wish to make of it.

Pierre:

Can we have some Lojbanists accepting some, but not all, of the rulings of the BPFK?


The usage of Lojbanists would and should be unregulated. The declaration of Lojban would exist to be used freely however people choose.

Robin again:

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


This is partly why my contributions to BPFK were never more than desultory. Description of prior usage is dreary and time wasting if the goal is to create a declaration that satisfies the main design goals. Of course, the original BPFK founders did mainly want a body that would primarily describe usage, but nobody was interested in doing that work.


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.


If a versioning system exists, it might make sense for the default position to be that cmavo are abolished unless a good clear case can be made for retaining them.

--And.

--
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.