Constructed Languages
What do you want from it?
I’ve been looking at some webpages describing Lojban (a fan page, the language reference manual, a crash course, and on HN).
I don’t think we can judge a language (constructed or natural) unless we define what we want from it.
With Lojban, in particular, I want to know its most compelling feature, some killer application, something you can do in Lojban that you can’t do in English or any other language. They say it’s logical and stuff, but I’m not able to see the advantage (from the outside).
Plus, it looks really ugly.
My Wish List
Something that helps prevent naive realism - E-prime, basically. You should not be able to confuse map and territory within the language.
Something that is still English, so that laypeople can understand it. (Though, if the language is good enough, I’m ok with it being something completely different. Each domain already uses a jargon-thick lingo anyway.)
Empiricism: the language should ask me for citations for every major claim. Scientific journal papers and Wikipedia already do this - it’s probably good to have in your everyday language too.
First-class elements. I don’t fully know what this means, but it should be like Haskell. For example, why have five parameters for each predicate (as in Lojban)? That seems ungainly to me. Either have just one or allow infinite number of parameters. Anything in between smacks of poor design (unless you justify it using human cognitive limitations). Do it like Haskell - if you want a function with two parameters, have one function that takes the first parameter and returns another function that takes the second parameter and gives you the final answer.
Bring in category theory somehow? Maybe allow people to wrap up the different sentences and paragraphs and sections and chapters in a book so that it is all still one element of the same type. In other words, allow us to compose different elements of the language. This will let you have deeply nested statements and such. In fact, do concepts form a category? In Haskell, functions are morphisms in the category of Hask. Also, when you have some function that notionally takes two parameters, like map, and you apply it to one argument, you get a function that is also a morphism in some category. Like map f :: [a] -> [b], which is a morphism in the category of lists. That’s why we define map as (a -> b) -> [a] -> [b] not [a] -> (a -> b) -> [b]; we can chain calls to map in the former case but not in the latter - map f . map g . map h. So, use this idea to decide the order of parameters to some “predicates” that have more than one parameter (like “talk” in Lojban - x1 talks to x2 about x3 in language x4). Basically, you’ve decided (in Lojban) to go with function (or predicates). Why not go all the way with function currying and function composition?
In fact, here’s a heretical thought: why not just use Haskell? Why do you need a separate constructed language half-way between Haskell and English? Is it because we use human concepts (like tree or chair or anger) without explicitly defining them? Well, get around it the same way you do in English or Lojban - call these primitive concepts, the indivisible atoms of your language. Hmmm… well, it’s not just that the primitives are fuzzy, even the concepts we build out of them are fuzzy. “Angrily sat on a chair” is made up of primitive words and is still quite vague. So, it seems like the means of combination (h/t SICP) are fuzzy too (and similarly for the means of abstraction).
Maybe this is the key distinction between natural languages and programming languages. Roughly, programming languages are for communication (aka exchanging information) with a computer whereas a natural language is for communication with a human. And sending information is about choosing messages from an ensemble. You need to narrow down a huge set of messages in order to get your point across to a computer; hence the struggle of the programmer. But you only need to give a few short messages to make your point to a human (“Get him!”). You both share a lot of concepts (sometimes you’re the same person and share a history of concepts) and also information about your utility functions (you know “give me some water” is not fulfilled by pouring sewage water).
Wait. If language is all about dealing with concepts (on top of the mathematical foundation of decisions and causal models), then why not design a language that closely matches the human cognitive structure? You want to combine concepts gracefully - why not look at how the human mind does it?
Have optional types too? This can help you define your problem concretely. Like when talking about expected value vs value - actions give you expected value, outcomes give you value. This is the difference between “I want to save my sister’s life” and “I want to administer penicillin to my sister” (h/t Eliezer Yudkowsky). Or taboo :: concept -> situations vs abstraction :: situation -> concept.
Respect human cognitive limitations. All else being equal, a shorter phrase is better than a longer one. (Succinctness is power, as PG says).
However, it’s not just enough that the language let us express things succinctly. It should also allow us to discover things efficiently. A strict language may let your final program be concise, but penalize exploration. (examples?)
Of course, make it Bayesian. Have first-class support for causal models, and force the author to exercise all the possible branches (A -> B and ~A -> ~B). Also, make sure he thinks about locality of causality. Along the same lines, ask for subjective probability estimates for beliefs and predictions - no blanket “maybe”s or “probably”s. Also, make the author think about everything in terms of hypothesis and evidence, nothing else. You’re either talking about a hypothesis or some evidence that shifts your beliefs.
One of the main problems in writing big (2k+ words) essays or big programs (200+ lines) is that things get ugly. I believe this is because we’re working with the unfactorized JPD - thus making it seem like you have a lot of possibilities, when most of them are duplicated. We need to take time to simplify our prose or code and the classic way to do that is through refactoring (in programming) or rewriting (in writing). One common sense way to enforce that is by saying that no function should be over 100 lines of code or that no paragraph should be over 100 words in length (I made this up).
Also, make it support decision-oriented thinking. Never talk about a causal model without reference to the decision you want it to inform.
Somehow make the user taboo each concept. Don’t fall for stuff like “luxury car”, “true love”, or “information”. One way could be to make him specify three exemplars for each category (like I did above).
Helpful PG essays on language design: What languages fix, The Hundred-Year Language (what language will we be using in a hundred years?), Five Questions about Language Design
Language as a Helpful Reminder
Perhaps what I want from a constructed language is that it should remind me or even force me to use certain rationality techniques. For example, E-Prime forces you to think about the map-territory distinction. Programming languages make you realize that your function is ungainly when it gets more than a few dozen lines long. Similarly, a language that only lets you express things as hypotheses or evidence forces you to think explicitly about your current hypothesis and how it handle the given evidence.
Take decision-oriented thinking. I want my language to remind me to ask how any given piece of information changes my decisions. Reading the current posts on a blog will probably not change my day-to-day actions by any amount, nor will the daily news. They have zero value of information, but I don’t realize it even when I know the theory because I’m not reminded of it when I’m checking the news.
Why don’t I just practice and memorize the techniques by themselves instead of trying to bake them into a language? Because I figure out ideas by writing. And my problem is that I fail to use my techniques at the appropriate moments. Wouldn’t it be great if the language I wrote with gently and automatically prompted me to use the right technique at the right time?
Like if I were using a concept label from somewhere (like “climate change” or “world’s best batsman”), it would remind me to taboo the concept and look at the original source (the empirical data on global warming or the actual cricket matches played by the batsman).
Also, it would be great if my language were optimized better for memory. For one, the fewer syllables a phrase has, the less time it takes you to memorize or recall it (AFAIK).
In short, a good language constrains your behaviour. You go from “don’t do that wrong” to “can’t do that wrong” (h/t Brian Hurt). In English, you can write sentences that distinguish between map and territory, just like you can explicitly ask about the empirical citations for some claim (science journals do it). But, by default, you violate all of those rules and several others. In a constructed language, however, you’re forced to use those techniques. You cannot express a poorly-formed thought. In an ideal language, for example, you wouldn’t be able to say “she looks beautiful” you would have to say “she looks beautiful to me”. That’s what I want from a constructed language - make it impossible for me to do it wrong.
A Decision-Oriented Language
At the end of the day, all my writing and thinking is so that I end up taking the right choice for each decision. So, it makes sense to organize my writing in terms of decisions, so that I can memorize each situation-response pair directly and unleash it when needed. To be more emphatic: don’t allow me to move off an essay unless I’ve clearly prescribed what to do for each decision. That is all that matters! The theory is useless if I don’t know what to do in the given situation.
So, make a list of the decisions you care about. Enumerate the available choices for each one. Add more as you keep thinking. And, at each point, have a recommendation for each decision. This, I claim, is the reasoning behind rapid prototyping - you always have something usable. There’s never a point where you don’t know what you should be doing. Yes, it may be suboptimal. Yes, you will probably figure out better options. But, right now, you know what to do in that situation.
The alternative is to just throw information at the reader and leave it to him to figure out what to do. Most of the time, you really do have nothing that can change the reader’s decisions. The information in your essay then has no value. I’m reminded of college courses where the information in the lecture seemed to have no practical impact on my life at all.
One way to do this might be to allow only a few, limited number of language elements: each element will be either a decision, hypothesis (or causal model), correlation, intervention, inference (updating on evidence), differing predictions (between hypotheses), variable, value of a variable (category), exemplars, or cue-memory association. The first eight cover the mathematical necessities and the last two cater to the human cognitive design.
(In reality, for information-processing, you only need hypotheses and evidence. But we have bounded resources, so we need to think in terms of decisions. Also, we judge variables and their values using our native categorization ability - i.e., I don’t fully understand how we do it. And to categorize, we need feature-rich exemplars.)
Do whatever you want with these. Build your descriptions of things with nothing else but these building blocks.
I know that this limited set of blocks will not suffice to describe what seem like complex elements of the world. But it will be a start. Go as far as you can with these elements and only add more if you absolutely need them to solve a problem. For starters, you should be able to fully describe an essay or blog post using your language.
Note: I think each English word (or phrase) represents a category (like “English”, “description”, or “essay”). So, that’s one part of the language covered. But you can’t have a whole description based on just categories. If you want to talk about the effects of interventions (like “eat lots of oily food” vs “don’t eat oily food”), you need causal models.
How?
How do you even get started on the features above?
Get a couple of concrete test scenarios for each feature and test your in-progress language against those. Your aim is to develop your language to handle all of them. If all scenarios pass, your language at least works for those scenarios (and probably others too).
For example, if you want the language to disallow naive realism, then take three common cases where you fall for naive realism, and design the language to make those expressions impossible. Where do we most often fall for naive realism? “That was a great movie” - “greatness” exists in the mind, not as part of the movie itself; yet we have arguments about movies. “A certain candidate is unlikely to be elected” - well, probability exists in the mind, not in reality; different people are allowed to have different subjective probability estimates. “That’s a really hard problem to solve” - again, it is you who think the problem is hard; it may not actually be hard in reality (and thus, not hard for some others).
Now, design your language to eliminate those forms of statements. (I believe E-Prime does this, though I’m not sure how user-friendly it is.)
This way, your language is guaranteed to solve at least these few problems. Otherwise, you can end up with a language that doesn’t solve any problems at all. Saying that Lojban is “designed to be neutral between cultures” and “based on the principles of predicate logic” and “attempts to remove restrictions on creative and clear thought and communication” is all fine, but have you actually tested that? Have you shown how Lojban prose lets you solve problems “more clearly and creatively”? Have you shown that the same contentious argument expressed in Lojban makes you think more logically than in English? How can you make those claims otherwise? I can’t find even a single side-by-side comparison that emphasizes Lojban’s strengths. (I’m yet to go deep into it, though.)
Notes
If every English word represents a concept, then by using commonly used English words (and not jargon), you’re describing everything using only commonly understood concepts. Like, for example, the concepts in the first words in this paragraph: “If every English word represents a concept”. Each of the words in that sentence is understandable by a layman. You’re not allowed to define too many new concepts within an essay - it’s considered bad form because it puts off casual readers, who find it hard to follow.
But that’s like saying you should write a program using only the primitive functions of a language. You’re not allowed to define new functions or anything. Then your problem is duplicated code. It’s why we abstract. We want to factorize the JPD - we want to break our monolithic program into small pieces orthogonal to each other so that our final program is much shorter.
(Our actual aim in programming is to reduce our uncertainty about the program or, roughly, the number of possible states the program can be in. Each function takes you from some set of inputs to some set of outputs. You can look at your program as a giant chain of function calls. A desired function a -> b has b^a possible candidate functions. So, the more values a variable can take, the more the number of states. (I’m not fully clear about this.) But the length of the program is a good enough substitute.)
Aside: This was an example of a different language opening my mind to a property of my everyday language that I had ignored. Lojban apparently lets and encourages you to invent new words, whereas English doesn’t. Learning new languages does help you use your existing one better - you start to question if your existing language’s way really is optimal. Earlier, you just had one data point and you didn’t even notice what was happening. Now that you have an alternative, you notice the difference, you notice the design choice and go “hmmm… which one is better?” (The same goes with culture.)
comments powered by Disqus