From lojban-out@lojban.org Sun Sep 24 08:30:16 2006 Return-Path: X-Sender: lojban-out@lojban.org X-Apparently-To: lojban@yahoogroups.com Received: (qmail 39854 invoked from network); 24 Sep 2006 15:27:04 -0000 Received: from unknown (66.218.66.216) by m34.grp.scd.yahoo.com with QMQP; 24 Sep 2006 15:27:04 -0000 Received: from unknown (HELO chain.digitalkingdom.org) (64.81.49.134) by mta1.grp.scd.yahoo.com with SMTP; 24 Sep 2006 15:27:03 -0000 Received: from lojban-out by chain.digitalkingdom.org with local (Exim 4.62) (envelope-from ) id 1GRVsY-0007Z9-Bg for lojban@yahoogroups.com; Sun, 24 Sep 2006 08:26:51 -0700 Received: from chain.digitalkingdom.org ([64.81.49.134]) by chain.digitalkingdom.org with esmtp (Exim 4.62) (envelope-from ) id 1GRVq6-0007XT-Pz; Sun, 24 Sep 2006 08:24:20 -0700 Received: with ECARTIS (v1.0.0; list lojban-list); Sun, 24 Sep 2006 08:24:10 -0700 (PDT) Received: from nobody by chain.digitalkingdom.org with local (Exim 4.62) (envelope-from ) id 1GRVpb-0007X0-1E for lojban-list-real@lojban.org; Sun, 24 Sep 2006 08:23:47 -0700 Received: from py-out-1112.google.com ([64.233.166.177]) by chain.digitalkingdom.org with esmtp (Exim 4.62) (envelope-from ) id 1GRVpY-0007Wq-Ux for lojban-list@lojban.org; Sun, 24 Sep 2006 08:23:46 -0700 Received: by py-out-1112.google.com with SMTP id i49so1780426pyi for ; Sun, 24 Sep 2006 08:23:43 -0700 (PDT) Received: by 10.65.23.15 with SMTP id a15mr2963259qbj; Sun, 24 Sep 2006 08:23:43 -0700 (PDT) Received: from blackbeast ( [67.165.223.114]) by mx.gmail.com with ESMTP id e13sm1281897qba.2006.09.24.08.23.37; Sun, 24 Sep 2006 08:23:42 -0700 (PDT) Date: Sun, 24 Sep 2006 09:24:17 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C6DFBB.374C1810" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acbf7X/2ksbtHvsBSzmmiEGsu42yMw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-ID: <4516a2fe.7679a989.04d0.2c5d@mx.gmail.com> X-Spam-Score: -2.1 (--) X-archive-position: 12615 X-ecartis-version: Ecartis v1.0.0 Errors-to: lojban-list-bounce@lojban.org X-original-sender: matthew.dunlap@gmail.com X-list: lojban-list X-Spam-Score: -2.1 (--) To: lojban@yahoogroups.com X-Originating-IP: 64.81.49.134 X-eGroups-From: "M@" From: "M@" Reply-To: matthew.dunlap@gmail.com Subject: [lojban] my opinion on why lojban isn't specifically well suited for human-computer interaction X-Yahoo-Group-Post: member; u=116389790; y=dezGGe0rpkvdpfbx8XYoN6ipGEMItGTmP0GsN1w1LVGtc_AiMw X-Yahoo-Profile: lojban_out X-Yahoo-Message-Num: 27049 ------=_NextPart_000_0018_01C6DFBB.374C1810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit First, a disclaimer; while I have put a significant amount of time into thinking about this kind of thing I'm certainly not an expert. I'm still going for my BS. Computers are both digital and binary (note: I distinguish digital from binary, some people disagree, but that's another argument altogether (and yes I'm aware that binary implies digital, that phrase is foreshadowing)), which makes them an interesting self metaphor. The difference between MI and AI is as fundamental as the difference between 1 and 0. Thus, the two potential uses of a syntactically unambiguous language (SUL for brevity) in a computer have no grey area between them. The short term use (dream) is to teach computers to utilize the language's unambiguous nature to provide an interface that can be read and written to in a spoken language. Obviously in a classical (ie linear processor based) computer syntax ambiguity is a severe no-no because the correct (intended) parsing is a non-digital process. Initially it's very tempting to say, oh, here's a language that sidesteps that problem by eliminating syntax ambiguity, we should use it to provide a more natural interface! And yes, that goal can be reached in a year or two with devoted work. The problem I have with this goal is that it's a solution to a problem that has been solved for decades. There are many SULs that are already written and in use as computer interfaces across the world. My personal favorite is bash. To compare bash to lojban I would say that bash is easier to learn (it is much smaller after all) and every bit as versatile as a cross-programming-language interaction framework as lojban could possibly be in a classical computing environment. Both languages are equally not my first, and I would say I'm truely fluent in neither, but comfortable with both. Of course, it is possible that in the near future there will be core (to borrow a term from the ASL community) jbopre, but even they will find the system is as unintuitive as any other digital language processing system (even with AI assistance) because of the restrictions requiring digital formatting. Another way to say it, is no matter how hard you try classical computers will never be able to figure anything, they rely on unambiguous meanings to get things done, lojban doesn't necessarily provide that, bash does. The real beauty of lojban isn't the fact that it's a SUL. The real beauty of it is a consequence of being a SUL, and that is, it can be used to convey things in absurdly creative (ie anything but digital) ways. As with any real beauty there is always a converse beast, which in this case is the fact that it's silly to be more creative than the person (or computer) you're talking to. Anyone who has dealt with the people that work at a DMV knows exactly what I'm talking about. Lets look at a very simple example that directly relates to an everyday computer activity in a lojban based classical computer system. ko minde mi> la zgikeB.mp3 fukpi la zgikeA.mp3 je'e The computer had no problem using with the command because it was in the finite list of things it is programmed to do, but if I throw even the simplest creative twist into the command it breaks out of the list of functions and the computer has difficulty. ko minde mi> la zgikeC.mp3 fukpi la cdrom0 le mp3 la ripperprogram .a'onai je'enai ko minde mi> ko facki go'i .a'onai je'enai ko minde mi> .o'onaisai This example was designed to illustrate two specific problems with a linguistically interfaced classical computers. Yes, the first command could have been simplified to "la zgikeC.mp3 ripperprogram la cdrom0 le mp3" and it probably would have worked, but what if there was some desired functionality that fukpi provided (a cvs push or something)? That aspect of the operation would then have to be done in a separate command. To interpret the command correctly the fukpi programming would have to figure out how to use whatever x4 argument you could send it, but the nature of the language makes that impossible without understanding the meaning of the words in the x4 place, simple recursion won't do it. The second thing I'm pointing out here is that 90% of the people I sit at a modern command prompt don't understand the limitations of the system, so they intuitively assume that it speaks whatever language the OS prompts are in. Then they try to talk to the computer through the keyboard and are frustrated when it doesn't work. It's freaking hilarious sometimes (http://blog.myspace.com/index.cfm?fuseaction=blog.view &friendID=77851792&blogID=130868121&Mytoken=26C6508D-0CAC-43BB-BDA1B437DCB0A A7811819937 is a candid transcript of one such occasion), but it's remarkably non-productive. Of course, the other dream is to actually teach a MI how to speak and understand lojban. Assuming such an auto-associative system could be made hardware wise, there would be absolutely nothing preventing it from being a perfectly natural feeling interface in spoken or typed lojban. You could ask it absurd questions and it could give you obviously considered answers. The problem I find with this is that once you've built MI there's no reason whatsoever you couldn't teach it English as well. The problem with human languages is that they are based on understanding. The problem with computer languages is that they're based on digital principles (which don't really apply in an analog world). That's what I think anyway, if you disagree I'd love to hear why. --M@ ------=_NextPart_000_0018_01C6DFBB.374C1810 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

First, a disclaimer; while I have put a significant amou= nt of time into thinking about this kind of thing I’m certainly not an expert.  I’m still going for my BS.

 

Computers are both digital and binary (note: I distingui= sh digital from binary, some people disagree, but that’s another argumen= t altogether (and yes I’m aware that binary implies digital, that phras= e is foreshadowing)), which makes them an interesting self metaphor.  The difference between MI and AI is as fundamental as the difference between 1 = and 0.  Thus, the two potential uses of a syntactically unambiguous langua= ge (SUL for brevity) in a computer have no grey area between them.<= /span>

 

The short term use (dream) is to teach computers to util= ize the language’s unambiguous nature to provide an interface that can be read and written to in a spoken language.  Obviously in a classical (i= e linear processor based) computer syntax ambiguity is a severe no-no because= the correct (intended) parsing is a non-digital process.  Initially itR= 17;s very tempting to say, oh, here’s a language that sidesteps that probl= em by eliminating syntax ambiguity, we should use it to provide a more natural interface!  And yes, that goal can be reached in a year or two with devoted work. 

The problem I have with this goal is that it’s a solution to a problem that has been solved for decades.  There are man= y SULs that are already written and in use as computer interfaces across the world.  My personal favorite is bash.  To compare bash to lojban = I would say that bash is easier to learn (it is much smaller after all) and e= very bit as versatile as a cross-programming-language interaction framework as lojban could possibly be in a classical computing environment.  Both languages are equally not my first, and I would say I’m truely fluent= in neither, but comfortable with both.  Of course, it is possible that in= the near future there will be core (to borrow a term from the ASL community) jbopre, but even they will find the system is as unintuitive as any other digital language processing system (even with AI assistance) because of the restrictions requiring digital formatting.  Another way to say it, is = no matter how hard you try classical computers will never be able to figure anything, they rely on unambiguous meanings to get things done, lojban does= n’t necessarily provide that, bash does.

The real beauty of lojban isn’t the fact that it’s a SUL.  The real beauty of it is a consequence of being a S= UL, and that is, it can be used to convey things in absurdly creative (ie anyth= ing but digital) ways.  As with any real beauty there is always a converse beast, which in this case is the fact that it’s silly to be more crea= tive than the person (or computer) you’re talking to.  Anyone who has dealt with the people that work at a DMV knows exactly what I’m talki= ng about.

Lets look at a very simple example that directly relates= to an everyday computer activity in a lojban based classical computer system.<= o:p>

ko minde mi> la zgikeB.mp3 fukpi la zgikeA.mp3

je’e

The computer had no problem using with the command becau= se it was in the finite list of things it is programmed to do, but if I throw = even the simplest creative twist into the command it breaks out of the list of functions and the computer has difficulty.

ko minde mi> la zgikeC.mp3 fukpi la cdrom0 le mp3 la ripperprogram

.a’onai je’enai

ko minde mi> ko facki go’i

.a’onai je’enai

ko minde mi> .o’onaisai

This example was designed to illustrate two specific problems with a linguistically interfaced classical computers.  Yes, t= he first command could have been simplified to “la zgikeC.mp3 ripperprog= ram la cdrom0 le mp3” and it probably would have worked, but what if ther= e was some desired functionality that fukpi provided (a cvs push or something= )?  That aspect of the operation would then have to be done in a separate comma= nd.  To interpret the command correctly the fukpi programming would have to figu= re out how to use whatever x4 argument you could send it, but the nature of th= e language makes that impossible without understanding the meaning of the wor= ds in the x4 place, simple recursion won’t do it.

The second thing I’m pointing out here is that 90%= of the people I sit at a modern command prompt don’t understand the limitations of the system, so they intuitively assume that it speaks whatev= er language the OS prompts are in.  Then they try to talk to the computer through the keyboard and are frustrated when it doesn’t work.  I= t’s freaking hilarious sometimes (http://blog.myspace.com/index.cfm?fuseaction=3Dblog.vi= ew&friendID=3D77851792&blogID=3D130868121&Mytoken=3D26C6508D-0C= AC-43BB-BDA1B437DCB0AA7811819937 is a candid transcript of one such occasion), but it’s remarkably non-productive.

 

Of course, the other dream is to actually teach a MI how= to speak and understand lojban.  Assuming such an auto-associative system could be made hardware wise, there would be absolutely nothing preventing i= t from being a perfectly natural feeling interface in spoken or typed lojban.=   You could ask it absurd questions and it could give you obviously considere= d answers.  The problem I find with this is that once you’ve built= MI there’s no reason whatsoever you couldn’t teach it English as w= ell.

The problem with human languages is that they are based = on understanding.  The problem with computer languages is that they’= ;re based on digital principles (which don’t really apply in an analog wo= rld).

 

That’s what I think anyway, if you disagree I̵= 7;d love to hear why.

 

--M@

------=_NextPart_000_0018_01C6DFBB.374C1810--