From lojban-out@lojban.org Sun Sep 24 22:33:33 2006 Return-Path: X-Sender: lojban-out@lojban.org X-Apparently-To: lojban@yahoogroups.com Received: (qmail 33066 invoked from network); 25 Sep 2006 05:31:31 -0000 Received: from unknown (66.218.66.166) by m35.grp.scd.yahoo.com with QMQP; 25 Sep 2006 05:31:31 -0000 Received: from unknown (HELO chain.digitalkingdom.org) (64.81.49.134) by mta5.grp.scd.yahoo.com with SMTP; 25 Sep 2006 05:31:30 -0000 Received: from lojban-out by chain.digitalkingdom.org with local (Exim 4.62) (envelope-from ) id 1GRj3w-0005FA-6I for lojban@yahoogroups.com; Sun, 24 Sep 2006 22:31:28 -0700 Received: from chain.digitalkingdom.org ([64.81.49.134]) by chain.digitalkingdom.org with esmtp (Exim 4.62) (envelope-from ) id 1GRj3M-0005EY-Qy; Sun, 24 Sep 2006 22:30:55 -0700 Received: with ECARTIS (v1.0.0; list lojban-list); Sun, 24 Sep 2006 22:30:44 -0700 (PDT) Received: from nobody by chain.digitalkingdom.org with local (Exim 4.62) (envelope-from ) id 1GRj2r-0005EM-EK for lojban-list-real@lojban.org; Sun, 24 Sep 2006 22:30:21 -0700 Received: from nz-out-0102.google.com ([64.233.162.193]) by chain.digitalkingdom.org with esmtp (Exim 4.62) (envelope-from ) id 1GRj2n-0005EE-Et for lojban-list@lojban.org; Sun, 24 Sep 2006 22:30:21 -0700 Received: by nz-out-0102.google.com with SMTP id n1so695321nzf for ; Sun, 24 Sep 2006 22:30:15 -0700 (PDT) Received: by 10.64.131.4 with SMTP id e4mr532064qbd; Sun, 24 Sep 2006 22:30:15 -0700 (PDT) Received: from blackbeast ( [67.165.223.114]) by mx.gmail.com with ESMTP id e14sm1898811qbe.2006.09.24.22.30.10; Sun, 24 Sep 2006 22:30:14 -0700 (PDT) Date: Sun, 24 Sep 2006 23:31:13 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01C6E031.8AACFD50" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: Thread-Index: AcbgEUfIflXx2DZsSxWiwpUVZ5eQxgAUPb8w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-ID: <45176966.22d930c9.30be.ffff9907@mx.gmail.com> X-Spam-Score: -2.1 (--) X-archive-position: 12621 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] Re: my opinion on why lojban isn't specifically well suited for human-computer interaction.2 X-Yahoo-Group-Post: member; u=116389790; y=Iji29EMASg_KMM26GrHORJZlk9NQ3nV173oau_U-TX1tK9nUpQ X-Yahoo-Profile: lojban_out X-Yahoo-Message-Num: 27055 ------=_NextPart_000_002B_01C6E031.8AACFD50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit So, as I understand your overall design you're talking about a unifying application framework with some fancy (or simplistic depending on your POV) recursion to take care of chaining things together. Forgive me for sounding cynical, but how is that different from .NET (and its IL)? I suppose the positivist translation would be "what problems does this system address?" --M@ _____ From: lojban-list-bounce@lojban.org [mailto:lojban-list-bounce@lojban.org] On Behalf Of Andrii Zvorygin Sent: Sunday, September 24, 2006 1:36 PM To: lojban-list@lojban.org Subject: [lojban] Re: my opinion on why lojban isn't specifically well suited for human-computer interaction It all depends on how you design the interface. I agree that classical computing wouldn't work with a lojban interface in an intuitive way. Because classical computing is very haphazzard, we have monolithic applications (though many of them are modularizing). Our computers aren't really wholes, they are just a bunch of standalone applications, thrown together. with lots of duplicate code. Sure linux is improving we have libraries, but the problem is we have libraries for every single programming language that more or less do the same things. if we broke up the programs into functions, then we could re-use functions from one program in another program. If you say, ran programs in a lojban interpreter, and say the function printed to it's stdout "cusku lu .ui roda drani li'u zo'e la skrin." that would be recieved by the interpreter, and it would (assuming la skrin. was actually a handle for the screen), it would print to screen: cusku lu .ui roda drani li'u or whatever the user or implementation defined as should be done with that kind of output. so say then we need a way of handling these large amount of bridi and selbri and all their possibilities. so we could (while files still exist), make a few files in a directory structure to describe what is happening, say we have a head directory lokrasi/selbri/ this directory will contain directories of all the selbri (including lujvo and fu'ivla, or anything with a function) so going with our cusku example >lokrasi/selbri/ >lokrasi/selbri/cusku/ in each selbri we could have a description file for what this function does say >lokrasi/selbri/cusku/cusku now cusku could contain, the input and the possible output, perhaps just a generalization, and specific inputs and outputs can be handled later. lets take something a little less complicated than cusku temporarily (because it doesn't have any real ouput. so >lokrasi/selbri/valsi/valsi could say on some line: >xu zo ko'a valsi fi la lojban. ja'e lu go'i .a na go'i li'u which would allow for you to use the valsi function to ask for wheather or not it is a word. some other examples of General Bridi: >zo ko'a valsi ma la lojban ja'e lu da li'u in : >lokrasi/selbri/fanva/fanva >zo'e fanva zo ko'a la .inglyc. la lojban. ja'e zoi .gy. da .gy. then you could have (possibly we could think of something better latter, works for now) >krasi/valsi/xuzoko'avAlsifilalOjban.ja'elugo'i.anago'ili'u The lines in this file might partially be written by hand, but it is thought that eventually this file will be written to based on actual input and output. then in this file (specific bridi) you would have lines looking like: >xu zo valsi fi la lojban ja'e lu go'i li'u >xu zo thn fi la lojban ja'e lu na go'i li'u General Bridi, and Specific Bridi, would have at least a few forseable uses: * verification of functions (if you get a new function off the network, that say works faster, or takes up less room, has some security fix, the Function Manager, that would be doing this update, can stick the function in a sandbox and test out what it outputs, and makes sure it doesn't give false output, or try to access any files(to avoid malicious software)) * creation of functions (by humans): the input and output of the command would definatly be very helpful in creating a new function, as well as seeing the general function to understand what is happening. * creation of function (by AI): because the input and output is so well defined as well as the format, it is forseable that you could evolve functions to preform the same operation with smaller executable size/faster speeds. you wouldn't let it work with all input and output, you should have some to see if it could predict the input output (not something like fanva though, where it's just translation) * simulation of function (by skami): If the function for some reason broke, or no longer exists and you have previous input and output, you could then just give the output when you see the input. Now comes the rather obvious problem of what do you do with functions that are not sateless (that can give different outputs with the same inputs). this is a little more complex, but the idea is to have the skami monitoring the program upon execution, and trying to see which environment variables seem to influence the output and then correlating them. so something like cusku could have a General Bridi of: cusku ko'a zo'e la skrin. ja'e lu la skrin. ca vasru ma ja'e fo'a .i fo'a vasru lu cusku ko'a zo'e li'u li'u now this is all great for if you have very small applications but say you want to have a mode or something, for editing documents, vi style: >kavbu la'i zoi zoi j zoi lerfu fi function >ce zoi zoi k zoi lerfu fi function2 >ce zoi zoi d zoi lerfu fi function3 >ce zoi gy. : .gy. lerfu fi function 4 or something of the like, really will depend on the actual implementation once more code get written. I was thinking that optionally you could also have a MUD, that would help navigate through the API, and large programs, and make it really easy to change the current view, modify or add in new links in the chain of output from one function to another. also optionally you could make a transitional-programming language in lojban, though i don't mean to actually have a lojban programming lojban language (that would be most of the above described) i mean a translation for current programming languages, so that you don't have to remmber that in bash you use if [[ a==b ]];then ;fi and in java you use if { a == b } {}, just have it so you could translate from java, to this transitional format, and translate back into java, or perhaps a different language in the same class, it could (conceivably) be achieved. lojban programming language, if such a thing will really exist as a whole, would probably be a more or less pure functional programming language. like Haskell The planning of this development environment / interface, is still in development so please feel free to contribute. i got some of the sources available: http://lokiworld.org/mediawiki/index.php/Funcysam note: have to edit the website to include this description probably will put this email there, this is probably the first time i've summarized most of my ideas for it. 9/24/06, M@ wrote: 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&blo gID=130868121&Mytoken=26C6508D-0CAC-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 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_002B_01C6E031.8AACFD50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

So, as I understand your overall desig= n you’re talking about a unifying application framework with some fancy= (or simplistic depending on your POV) recursion to take care of chaining things together.

 

Forgive me for sounding cynical, but h= ow is that different from .NET (and its IL)?  I suppose the positivist tr= anslation would be “what problems does this system address?”

 

--M@

 

From: lojban-list-bounce@lojban.org [mailto:lojban-list-bounce@lojban.org] On Behalf Of Andrii Zvorygin
Sent: Sunday, September 24, = 2006 1:36 PM
To: lojban-list@lojban.org Subject: [lojban] Re: my opi= nion on why lojban isn't specifically well suited for human-computer interaction=

 

I=
t all depends on how you design the interface. I agree that classical compu=
ting wouldn't work with a lojban interface in an intuitive way. Because cla=
ssical computing is very haphazzard, we have monolithic applications (thoug=
h many of them are modularizing). Our computers aren't really wholes, they =
are just a bunch of standalone applications, thrown together. with lots of =
duplicate code. Sure linux is improving we have libraries, but the problem =
is we have libraries for every single programming language that more or les=
s do the same things.




if we broke up the programs into functions, then we could re-use functions =
from one program in another program. If you say, ran programs in a lojban i=
nterpreter, and

say the function printed to it's stdout "cusku lu .ui roda drani li'u =
zo'e la skrin."


that would be recieved by the interpreter, and it would (assuming la skrin.=
 was actually a handle for the screen),

it would print to screen: <function name> cusku lu .ui roda drani li'=
u

or whatever the user or implementation defined as should be done with that =
kind of output.




so say then we need a way of handling these large amount of bridi and selbr=
i and all their possibilities. so we could (while files still exist), make =
a few files in a directory structure to describe what is happening,




say we have a  head directory lokrasi/selbri/

this directory will contain directories of all the selbri (including lujvo =
and fu'ivla, or anything with a function)



so going with our cusku example

>lokrasi/selbri/


>lokrasi/selbri/cusku/



in each selbri we could have a description file for what this function does=
 say

>lokrasi/selbri/cusku/cusku



now cusku could contain, the input and the possible output, perhaps just a =
generalization, and specific inputs and outputs can be handled later. lets =
take something a little less complicated than cusku temporarily (because it=
 doesn't have any real ouput.




so

>lokrasi/selbri/valsi/valsi

could say on some line:

>xu zo ko'a valsi fi la lojban. ja'e lu go'i .a na go'i li'u

which would allow for you to use the valsi function to ask for wheather or =
not it is a word.




some other examples of  General Bridi:

>zo ko'a valsi ma la lojban ja'e lu da li'u

in :

>lokrasi/selbri/fanva/fanva

>zo'e fanva zo ko'a la .inglyc. la lojban. ja'e zoi .gy. da .gy.



then you could have (possibly we could think of something better latter, wo=
rks for now)


>krasi/valsi/xuzoko'avAlsifilalOjban.ja'elugo'i.anago'ili'u



The lines in this file might partially be written by hand, but it is though=
t that eventually this file will be written to based on actual input and ou=
tput.


then in this file (specific bridi) you would have lines looking like:

>xu zo valsi fi la lojban ja'e lu go'i li'u

>xu zo thn fi la lojban ja'e lu na go'i li'u







General Bridi, and Specific Bridi, would have at least a few forseable uses=
:


* verification of functions (if you get a new function off the network, tha=
t say works faster, or takes up less room, has some security fix, the Funct=
ion Manager, that would be doing this update, can stick the function in a s=
andbox and test out what it outputs, and makes sure it doesn't give false o=
utput, or try to access any files(to avoid malicious software))<=
/span>


* creation of functions (by humans): the input and output of the command wo=
uld definatly be very helpful in creating a new function, as well as seeing=
 the general function to understand what is happening.

* creation of function (by AI): because the input and output is so well def=
ined as well as the format, it is forseable that you could evolve functions=
 to preform the same operation with smaller executable size/faster speeds. =
you wouldn't let it work with all input and output, you should have some to=
 see if it could predict the input output (not something like fanva though,=
 where it's just translation)


* simulation of function (by skami): If the function for some reason broke,=
 or no longer exists and you have previous input and output, you could then=
 just give the output when you see the input.



Now comes the rather obvious problem of what do you do with functions that =
are not sateless (that can give different outputs with the same inputs). th=
is is a little more complex, but the idea is to have the skami monitoring t=
he program upon execution, and trying to see which environment variables se=
em to influence the output and then correlating them.




so something like cusku could have a General Bridi of:

cusku ko'a zo'e la skrin. ja'e lu la skrin. ca vasru ma ja'e fo'a .i fo'a v=
asru  lu  cusku ko'a zo'e li'u li'u



now this is all great for if you have very small applications but say you w=
ant to have a mode or something, for editing documents, vi style:


>kavbu la'i zoi zoi j zoi lerfu fi function

>ce zoi zoi k zoi  lerfu fi function2 

>ce zoi zoi d zoi  lerfu fi function3

>ce zoi gy. : .gy. lerfu fi function 4



or something of the like, really will depend on the actual implementation o=
nce more code get written.




I was thinking that optionally you could also have a MUD, that would help n=
avigate through the API, and large programs, and make it really easy to cha=
nge the current view, modify or add in new links in the chain of output fro=
m one function to another.




also optionally you could make a transitional-programming language in lojba=
n, though i don't mean to actually have a lojban programming lojban languag=
e (that would be most of the above described) i mean a translation for curr=
ent programming languages, so that you don't have to remmber that in bash y=
ou use if [[ a=3D=3Db ]];then ;fi and in java you use if { a =3D=3D b } {},=
 just have it so you could translate from java, to this transitional format=
, and translate back into java, or perhaps a different language in the same=
 class, it could (conceivably) be achieved.
<= pre>

lojban programming language, if such a thing will really exist as a whole, = would probably be a more or less pure functional programming language. like= Haskell



The planning of this development environment / interface, is still in development so please feel free to contribute. i got some of the sources av= ailable:

http://lokiwo= rld.org/mediawiki/index.php/Funcysam

note: have to edit the website to include this description probably will pu= t this email there, this is probably the first time i've summarized most of m= y ideas for it.

 9/24/06, M@ <matthew.dunlap@gmail.com> wrote:

First, a disclaimer; while I have put a significant amount of time into thinking a= bout this kind of thing I'm certainly not an expert.  I'm still going for m= y 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 potentia= l uses of a syntactically unambiguous language (SUL for brevity) in a compute= r 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.  <= /font>

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 le= arn (it is much smaller after all) and every bit as versatile as a cross-programming-language interaction framework as lojban could possibly b= e 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 f= ind the system is as unintuitive as any other digital language processing syste= m (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 a= ny real beauty there is always a converse beast, which in this case is the fac= t 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 k= nows 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 linguistica= lly interfaced classical computers.  Yes, the first command could have bee= n simplified to "la zgikeC.mp3 ripperprogram la cdrom0 le mp3" and = it probably would have worked, but what if there was some desired functionalit= y that fukpi provided (a cvs push or something)?  That aspect of the operation would then have to be done in a separate command.  To interp= ret 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 make= s that impossible without understanding the meaning of the words in the x4 pl= ace, simple recursion won't do it.

The second thing I'm pointing out here is that 90% of the people I sit at a mod= ern 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 ar= e frustrated when it doesn't work.  It's freaking hilarious sometimes (<= a href=3D"http://blog.myspace.com/index.cfm?fuseaction=3Dblog.view&friend= ID=3D77851792&blogID=3D130868121&Mytoken=3D26C6508D-0CAC-43BB-BDA1B= 437DCB0AA7811819937" target=3D"_blank"> http://blog.myspace.com/index.cfm?fuseaction=3Dblog.view&friendID=3D778= 51792&blogID=3D130868121&Mytoken=3D26C6508D-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 understa= nd lojban.  Assuming such an auto-associative system could be made hardwa= re wise, there would be absolutely nothing preventing it from being a perfectl= y 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.<= /p>

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_002B_01C6E031.8AACFD50--