Re: my proposals for a philosophical language

On Wed, Jan 22, 2003 at 02:08:10AM +0100, Andrew Nowicki wrote:
> Andrew Nowicki wrote:
> AN> The root words must be made in such a way that
> An> it is clear where is the beginning and the end
> AN of each root word.
>
> "H. S. Teoh" wrote:
> HST> Why?
>
> This is the same problem as recognizing where
> one word ends and another word begins. Novice
> speakers of English are lost when they listen
> to fast spoken English.
But as many others have pointed out, this happens in *every* language. You
seem to think it's a very bad thing, but I disagree.

Consider: have you ever noticed that when, for example, English speakers
(or whatever language of your choice) speak in the presence of people they
know are still learning the language, they tend to *slow down* and
articulate their words more clearly?

Let's look at this from another perspective. When these same English
speakers were babies, and were first learning the language, didn't their
teachers and parents speak *slowly* and *clearly* to them? And didn't they
start speaking English *slowly*, with clear-cut word boundaries? Now
consider: why is it that after they grew up, they stopped doing this? If
it is so much better for them to always articulate everything very
clearly, if it's so much better for them to always accentuate word and
morpheme boundaries, then why did they stop doing it?

The answer is, it's because when you're speaking with other fluent
speakers, it's a waste of time and effort. Or, to put it another way,
there is NO NEED for them to articulate things precisely, because their
brains can pick out the words effortlessly, even though on the surface it
looks impossibly hard!

This is called optimization. Fluent speakers of *any* language will always
optimize. Nobody wants to take the time or effort to articulate everything
painfully clearly; especially if it doesn't even make a difference anyway.
Optimization happens in *every* language, and you're not going to stop it,
because no amount of language control is going to convince anyone to do
something that to them is suboptimal.

I think you're focusing on the wrong problem. What you want is give your
roots a *distinctive* shape, so that it will stand out no matter what it's
embedded in. Trying to micromanage the lexical makeup of root words is
losing sight of the forest for the trees.

[snip]
> HST> I'm not sure I understand the rationale
> HST> behind this. I can see a reason behind
> HST> limiting the number of root words used
> HST> in common, everyday conversations (learn
> HST> a small number of roots and you'll
> HST> understand most of what people say). But
> HST> putting an upper limit on root words in
> HST> the entire language seems to me something
> HST> that will only hamper the language's
> HST> development and ultimately, acceptance.
> HST> People who have mastered the basics will
> HST> say, "why can't I coin new roots? It's too
> HST> repetitive to keep using these long words!"
>
> We agree that consonant clusters are not
> desirable. Consider a language that has
> only two letters long root words.
Why do you have to restrict roots to X number of syllables? It seems to me
like an arbitrary, artificial decision that only limits your option, and
doesn't really address the problem you're trying to address.

[snip]
> total number of CVC root words. Another problem
> with VCV and CVC is that they may be confused
> with two letters long root words -- you would
> not know where the root words begin and end.
For some reason you seem awfully concerned with root boundaries and word
boundaries. And I'm not sure I understand why. I don't see any reason why
that is desirable; on the contrary, I see disadvantages. Such as limiting
the number of possible roots, and making the language sound fragmented and
staccato-ic.

[snip]
> At present Ygyde uses only CV roots but it
> can be extended with CVV roots. The total
> number of CV and CVV roots is on the order
> of one thousand. What do you do when you
> need more roots? You are in big trouble.
No you are not. Why can't you introduce CVCV roots? Nothing says you can't
have disyllabic roots, except when you impose that artificial limit upon
yourself. Then no wonder you're in trouble. You can have CV roots for
basic, core concepts, so that they're shorter and easier to remember. But
why restrict yourself unnecessarily? More complex concepts deserve more
syllables. Biologists have no problem with long strings of taxonomic names
made of long polysyllabic parts.

To me, this sounds like simple resource management: you have a limited
number of CV combinations, so use them on basic, foundational things.
There are more CVCV combinations, so less important things can be
allocated to those. Rare things can be allocated CVCVCV roots -- nobody
will mind because they are rare, so the three syllables isn't that much of
a bother.

[snip]

> It is easy to change pronunciation and add more root words, but it seems
> impossible to change the meaning of existing root words or to change
> Ygyde's prefix table. Well, we could easily include longer compound
> words in the prefix table, but other changes of the prefix table would
> require increasing the number of vowels from 6 to 9.
Then add longer compounds instead of more vowels. I don't see the problem
here.

> The prefix table *is* the philosophy of Ygyde. Those who make the
> compound words may invent taxonomical rules, but as you have pointed
> out, these rules result in very similar names of vegetables.
Not just vegetables. *Everything* sounds too similar. Because of the way
words are constructed. That's the problem.

Also, IMHO, the prefix table is overly restrictive. You are basically
excluding new prefixes from being created; as a result you have to
construct new prefixes from existing, shorter prefixes. But since a finite
prefix table is necessarily limited in expression, there will always be
new concepts that isn't adequately described by the basic prefixes and/or
their combinations. As a result, any combination of existing prefixes will
not adequately describe some concepts. That's why you have nasty
ambiguities like North America/South America, and others, that other
listmembers have pointed out. Sure, you can re-assign meanings, but that
doesn't solve the *real* problem, which is that limiting word formation to
the prefix table is overly restrictive.

I can't believe I'm actually trying to solve your problem for you, :-P but
anyway... since you initially mentioned Linux in relation to Ygyde, and
since I myself am an avid Linux user, I have a suggestion: why not
actually *follow* the Linux development model? Which is, let the masses
(~= Ygyde speakers) submit patches (=~ new words), and then you factor out
the common parts and turn them into "official" (pre|in|suf)fixes.

Let me illustrate what I mean: instead of having a prefix table, just
create a basic vocabulary of more or less arbitrary words. Then let Ygyde
speakers make up words that didn't exist before, and send them to you.
After enough words are submitted, analyse them for common patterns. You
may find common patterns, maybe common prefixes, or common infixes, among
related words. Put *those* up as official morphemes for that category of
words. Then in the future, when somebody wants to coin a new word, they
look at the "official" morpheme and, at their choice, incorporate it into
the new word.  There may be some arbitrary words that can't be analysed.
That's OK, don't throw them out! They may serve as the basis for future
words.

You may end up with several common morphemes for the same category of
words. But that's OK; don't regard them as "bad"! On the contrary, they
are *enriching* your base of morphemes, upon which new words can be
constructed. Far from being "bad", having multiple morphemes for the same
(or similar) things is a *good* thing. Think about software development
terminology: you have words like "construction", "build", "linking",
"integrating", even "development". Imagine if we had to derive all our
software development words from a single morpheme, "build". We'd quickly
run out of different words for expressing different aspects of software
development. They'd all be "X-build", "Y-build", "Z-build". We'd be
X-building our Z-build, using the Y-build tool called W-build, which we
have V-builded with the U-builder. You see how inane and verbose it
becomes very quickly? And how difficult it is to distinguish between them?

But it's because of the rich heritage of English, that we have a rich
library of morphemes to pick from: "struct" for words like "construct",
"destruct"; "build" for "building", "builder"; "link" for "linking",
"linker"; "integrate" for "integrator", "integration"; "develop" for
"developer", "development", etc.. Sure, English has its flaws, but every
language does. Forcing everybody to live with X-build, Y-build, Z-build
instead of "develop", "link", "build", doesn't solve the problem---it only
introduces more of its own.


T

--
PNP = Plug 'N' Pray

Replies