[MUD-Dev] Languages (slightly offtopic, was Text Parsing)

[Cynbe ru Taren]

Mark Gritter <mark at erdos.Stanford.EDU>:

| Cynbe ru Taren writes:
| 
| > Remember that Algol was invented well before electronic computers,
| > simply because natural language sucks as a medium for giving precise
| > directions, even between humans.
| 
| Umm... I don't believe this is correct.  Algol was invented in the
| late 1950's (first formalized in 1958), and there were certainly electronic 
| computers before then.  EDVAC was built in 1952.

Well, you can stretch the chronology that far, plausibly, if you wish.

But that doesn't affect the point:

Algol was developed without reference to electronic computers.

Algol was developed before there was any appreciation that such a
syntax could be "automatically programmed" -- compiled.

Algol was developed as a publication language for humans to
communicate with other humans.

Algol was developed because natural language was felt to be
inadequate for publishing and discussing algorithms --
precise directions.


| > Mathematicians similarly developed math notation because natural
| > language is completely inadequate for precise communication.
|
| But a MUD doesn't need "precise communication"!

We may have to agree to disagree for the nonce on this.

I think human interface people generally, however, recognize
the value of the principle of least surprise:  Users prefer
their interface and the activities it controls to behave
in easily predictable ways.

Which means that the commands they issue need to have
precise, defined meanings, rather than ambiguous our humanly
incomprehensible ones.

If that wasn't what you understood by my use of "precise"
above... well, maybe that illustrates the problem. :)


| In fact, I'd argue that mathematical notation isn't any more "precise"
| than natural language.  Most proofs are done using the writer's
| native tongue rather than a formal system--- specialized notation is
| just a shorthand.  It's simpler, easier, and more efficient to write 
| "x + y \equiv 2 (mod N)" than to say "The sum of the values of the 
| variables 'x' and 'y' is in the same congruence class as 2, when 
| all numbers that differ by a multiple of 'N' are in the same congruence
| class."  But it's no less precise-

I've seen very few proofs done in natural language devoid of
mathematical notation.  But no doubt your experience is wider
than mine.

I'm quite convinced that you'd fail miserably if you tried
to teach even an elementary course in any of (say) number
theory, quantum mechanics or tensor calculus without benefit
of mathematical notation:  The ambiguity of natural language
would make a difficult subject quite impossible for the
students.



| -- mathematical notation is a fairly
| recent invention in the history of mathematics.

*blink*

Specialized math notation dates back at least to Euclid's
diagrams, and I rather expect to the Sumerians, although I
must admit I haven't studied their texts in the original.

Of course, Euclid can be considered "fairly recent" if one
wants to push the history of mathematics back to paleolithic
times -- a not completely implausible exercise.



| I don't believe that they really want to learn a different set of conventions 
| from what they already know.

*shrug*

Look at what such users actually do when faced by any
well-defined domain from music to weaving patterns
to football plays: They develop an appropriate notation,
quite as impenetrable to outsiders as algebra.

Humans are symbol-making critters.  Deaf children
spontaneously invent sign languages.

They want a notation appropriate to the domain.

I've been working for a couple of decades with anatomists,
one of the least math-sophisticated and most computer-averse
professions around, and the notations they pick for
filenames &tc make old 50s fortran programs look readable by
comparison :( ...



| An NLP parser, however, should
| have the ability to ask questions and attempt to resolve ambiguities
| through dialogue.  I think the lack of this feedback is probably more 
| crippling than any inefficiency or lack of clarity in English itself.

I wrote the first Loglan parsers back in '81 or so:  I may not be
a domain expert, but I've thought about this some. :)

It cuts both ways: IMHO English is ambiguous because
ambiguity is more compact and efficient in the face of a
huge, ill-defined universe of discourse.  It can afford this
because it is being exchanged between relatively intelligent
critters with compute power dwarfing anything available in
silicon (outside the NSA?), and because in typical
applications feedback -can- be used to resolve any
ambiguities.  It needs this efficiency because while
human internal bandwidth is immense (gigabits/sec? --
pick your exponent), human-human bandwidth is pitifully
limited -- Marvin Minsky quotes 2 bits/sec to long term
memory.  Bandwidth to short-term memory is undoubtedly
higher, but something like a nine order of magnitude
disparity remains.

But current muds don't have universes of discourse anywhere
on that scale, current servers cannot bring anything like
that level of intelligence to bear, and current mud players
don't want to have to confirm every command and argue with
the server to get it to respond. :)  (Jewish-momma shell,
anyone?)



Anyhow.  As a mud-design matter, I think the best solution
is to not hardwire anything in particular: Let the user
command shell be user programmable and replaceable, and let
them use whatever they want.  That's what I'm doing with
Muq/Micronesia.  Who knows, maybe they'll all
plug in enormous NLP shells, given the choice.  I'll bet
against it, though. :)

I'd note, however, that Unix has had user replaceable shells
for quite a few years now, and there is as yet no
discernable trend towards NLP shells.  I expect the next
generation of palmtops will give the idea a try: Each
computing generation seems to play briefly with it.  Maybe
this time it will turn out differently -- the universe
remains a surprising place!

 Cynbe



_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev