(Originally appeared in Lognet 93/4)
I read with great interest the “Toward A Loglan Speech Community” piece in Lognet 93/3. I discussed with my wife, Helena, the possibility of spending two weeks in Florida during our vacation. Since she is not a Loglan enthusiast (although she is a curious observer and a staunch supporter of my right to pursue my interest in Loglan) it was not clear how much of our vacation we would be spending together if we decided to go. She and I both work full time and go to school, so the prospect of not getting much time to be together for the only two weeks of the year that we can be didn’t make the prospect overly appealing. I suspect other logli and their covivants1 may have had similar reactions.
But I realize that unless I can begin to speak Loglan with others, I will never be able to dream in Loglan. I believe that the most profound changes in world view and intellectual capabilities may not be accessible to me until I can dream in Loglan. I remember how excited I was when I had my first dream in Italian. At that point I felt I had acquired the Italian worldview. Others may have had similar experiences with their sutori languages.
So, despite the inconveniences, I would really like to be able to participate in such an experience. So how could I make that possible? Well, I thought, why am I limited to two weeks? The answer was brutally obvious: because I work. OK. What if I worked for the Loglan Institute instead of the software development company I currently work for? Not likely. The Loglan Institute couldn’t afford me. (Or perhaps I couldn’t afford to work for the Institute!)
I let my mind drift back to my master’s thesis (which is where it goes these days whenever there is nothing more pressing for it to do). I remembered an idea that I had discarded: the contention that a software development company that conducted its business in Loglan would have competitive advantages over Englishbound companies. The argument went as follows:
Companies don’t usually plan the software development effort adequately because the product development cycles (see figure at right) have no direct connection to pseudocode or real code.
People misunderstand each other during this planning cycle and they tend to change the plan during actual development without updating the documentation.
Consequently, companies can’t properly test software because, by the time the prototype gets to test engineering, there is no viable test plan. This in turn is true because the requisite documents haven’t been updated. In addition, the user documentation is now incomplete and inaccurate for similar reasons.
A company that used Loglan in all of its specification documentation could avoid many of these problems for at least two reasons: Loglan texts eliminate syntactic ambiguity and they qualify as pseudocode.
If written in Loglan, marketing’s Product Description and Requirement Specification would be unambiguous, displaying their logic (or illogic) conspicuously. The engineering response—the Functional Specification, also in Loglan—could use that document and build on it. The Technical Publications group could use the Functional Specification to write a Documentation Requirement Specification, in Loglan, to drive the English language user documentation development cycles (Technical Review Draft, etc.).
Engineering’s final Detailed Design Specification, in Loglan, would now be much more detailed and yet still be unambiguous. And it could be understood by Marketing, Test Engineering, and Technical Publications!
If the Detailed Design Specification consisted of Loglan texts that could be taken as source code for a compiler, then there would be an intrinsic reason for keeping the Loglan documentation current throughout the rest of the product development cycle.2 Then, the test plan would be very easy to write and just as easy to follow. The user documentation would have to be written in English but at least the writers would have unambiguous, uptodate engineering documentation to work from. Questions would suggest themselves wherever predicates contained unspecified arguments, etc.
In short, the process of planning a product would meld into the actual development of that product in an organized, trackable, cooperative manner. And the development would meld into the testing and documentation of the product in a similarly smooth way.3
When I first thought of this scenario, it seemed absurd. What software development company would ask all its employees to learn Loglan in order to put it into practice? But after reading JCB’s piece, another possibility presented itself. What if interested members of the Loglan Institute were to found a company, call it SoftDev Inc., to design and market software? In that case, the problem of motivation would disappear; everyone involved would be involved because they wanted to use Loglan for these business purposes!
But the problem with this plan is that we are all so spread out that it would be a hardship for many (not to speak of the economic risk) to move to some location where a physical facility could be set up.
I let my mind drift back to my master’s thesis...Wait! That’s it! The Master’s program that I am involved in is run entirely via computer conferencing. Students and faculty are dispersed worldwide and interact asynchronously. Murray Turoff, the software engineer that designed the original ConnectedEducation computer conferencing application, used computer conferencing to enable programmers at remote sites to work together to design and implement that application. SoftDev Inc. could do the same thing. This way, we could design and implement the first software products in a virtual environment. Once they become successful, we could begin to pay ourselves salaries. At that point, the two week allLoglan get togethers could be company funded sabbaticals!
Since we have several software developers among us and at least one professional technical writer (yours truly), this seemed to be a viable option. It would require one 486DX class PC clone with a goodly amount of RAM and disk space and a connection to the Internet or to one of the packet switched networks.4 There is commercially available software that would implement the computer conferencing system.5 We would need a system/network administrator. Then we would need some time from wouldbe designers and developers and a product or two.
We might want to start by writing the utilities that would turn Loglan into C. 6 With that bootstrap approach, it might be easy to get started. Then we could move on to...an electronic version of Careers, perhaps! Or a good video game. Dr. Brown tells me that there is even a space exploration and development game that he and some British friends invented and played some years ago that would be ideal for computer development. Eventually, we might be able to provide software that would translate from Loglan into English. Then from Loglan into German, into Spanish, etc. This could then become the basis of a software utility that would translate Loglan into multiple foreign languages. That software could provide the infrastructure for yet another line of business products. The Loglan Institute could develop a certification program for people wanting certificates in translation into Loglan. These people could take technical documentation originally written in Spanish or Greek, say, and translate it into Loglan. The utility could then translate it into any or all of the currently supported languages. You will all be able to supply other ideas along these lines, I am sure.
So, that is my idea. If we build on our strengths (software design and implementation, documentation, translation, computer conferencing, etc.), we may find an economic path to the Loglan Speech Community. If we can provide ourselves with work, then we really may be able to dream in Loglan.
Notes
1. This is a new word that Djim and I both like as a replacement for all the awkward phrases we’re using so unhappily now to refer to those who are living together and important to each other regardless of their legal status. Djim tells me that the inventor is a New England English teacher by the name of Lederer.
2. For example, Charles Rich and Howard E. Shrobe of MIT wrote a report entitled “Design of a Programmer’s Apprentice” (Artificial Intelligence: An MIT Perspective, Volume 1, The MIT Press, Cambridge Massachusetts, 1979) in which they describe an approach to the software crisis. The software crisis, they say, is a consequence of the problems programmers encounter as the size of programs increase. A barrier seems to have been reached: as the size of the programs increase, the rate of interactions among modules increases much more rapidly. Their approach is somewhere between languageoriented programming tools (such as the programmer’s workbench) and automatic programming. “Given knowledge of basic programming technique and the ability to assimilate application domain concepts, it becomes possible for a computer system to understand a user’s program in a much deeper sense and therefore to cooperate with him (sic) more effectively in the design, implementation, and maintenance of the program.” (p. 140). To explain the programmer’s apprentice, they present an imaginary dialog between a programmer and the programmer’s apprentice that traces the design, coding, and later modification of a hash table deletion program. At the time they wrote the piece, the only major part of the scenario that was not part of their research goals was the use of free English dialog as the metalanguage. “Although we feel certain that the system we are designing will be able to support a sophisticated natural language ‘frontend,’ we have made no efforts in this direction.” (p. 141).
Their system is based on three levels of program description: (1) Deep plan; (2) Surface plan; (3) Code. The most significant effect of the omission of a natural language frontend is the lack of a viable means for specifying the deep plan for the program. The scenario they provide does this in a single English paragraph.
The substitution of Loglan for the metalanguage would permit this system to accept the Engineering Detailed Design Specification as a deep plan. Since the cooperative development and maintenance of the program involves the continual synchronization of the plan and the code, this system would enforce documentation updates as required.
3. The use of Publish and Subscribe in a networked Macintosh environment or the use of OLE (Object Linking and Embedding) in a networked Windows environment would ensure timely updates of “parent” documentation during the course of the product development cycle.
4. Naturally, we could substitute one of the new network servers from Apple. The Apple servers seem costly by comparison and since Netware now supports X.25 and Ether Talk connections as well as AppleTalk Remote Access, the added expense may not be required.
5. In “Computer Mediated Communications” by Matthew Rapaport (John Wiley & Sons, Inc; 1991) virtually all of the systems that can run on hardware that we could afford are described and compared.
6. Or, we might want to investigate providing a Loglan frontend to the programmer’s apprentice and using it as the defacto inhouse programming environment. This is another bootstrap approach.
Copyright © 1993 by The Loglan Institute. All rights reserved.