Slashdot Mirror
English Language And Its Effect On Programming?
jasno asks: "I've been wondering lately about the effects that the English language has had on programming languages. Have the limitations/ambiguities/peculiarities of the English language changed how we might have created, for instance, C if we spoke, perhaps, Swahili? Since English is my only language I'm curious to see what my multilingual companions have to say about this." Interesting thought. What would Perl be like if it was coded by a native Japanese speaker?
Contrary to what you seem to believe, Japanese don't go creating new characters all the time.
There are approximately 2000 "daily use" kanji officially sanctioned by the government, out of a total of around 30,000 Chinese characters. All words in the Japanese language are usually represented by a combination of these 2000 daily use characters, or by using one of the phonetic alphabets. There are, of course, a few exceptions when dealing with names, advertising and the like.
However, these characters still carry significantly more information than English letters. Japanese books are much shorter in length than their English counterparts, simply because it takes fewer characters to relay the same amount of information. On a related note, Japanese can typically read their native language much faster than native English speakers can read English, because it is very easy to "scan" the characters and pick up what is being conveyed. When I was learning Japanese my professor would always chide us for speaking the words (aloud or in our heads) while we were reading, as it was actually slowing down the intake of what was on the page.
At the lowest level, each character in the phonetic alphabets (hiragana and katakana) typically represents a combination of 2 English letters. At a much higher level, a single kanji character can represent an idea, with combinations of these expressing more complex concepts.
As far as computer languages are concerned, an interesting language to check out might be Ruby, which was invented in Japan. I believe it is a souped-up scripting language, kind of like Python, but I hear that it has a number of unusual features.
Not quite. Programing languages are all turing compatable, and it can be proven you can translate from one to anouther correctly. Bablefish doesn't do a very good job of translating english to german (or back), and both those languages are based from latin roots.
What this means to you is that if I teach you C, to the point that you become good at it, I can teach you perl, APL, and several other languages in very little time. (In school I had a class that covered 12 languages in 10 weeks) If I tought you german it would help you to learn Danish, but it would still take you a while to learn Danish. I could then to Spanish and Portageese (very close), and you would learn faster. If I went on to Korean, Russian and (american) Indian, you would have little advantage over someone who had never learned anouther language. Some only because you wouldn't expect it to look like english.
In the last year I've used about equal amounts of TCL, Spanish, German, and C - almost no usage of any of them, and I used to know them all. If I needed to pick up one again I wouldn't have a problem picking up C or TCL, because I've been programing even though it is in a completely different language. Even though I spend more time speaking english then programing I'd have a hard time getting back to proficant with Spanish or German.
Controlling people is something that can be done in any language
Which is preceisely why I find the Churchill argument doubtful. If the langauge is good enough to give orders on factory floors, I doubt military work requires less ambiguity.
While many Japanese industrial processes were adopted from abroad, borrowing words has nothing to do with it. Most of the English words found in Japanese non-technical dictionaries were borrowed before WWII. Furthermore, adopting English words does nothing to change ambiguity. Anything that can be accomplished using an English word could be accomplished using a Japanese one, so long as the speakers agree to that code.
You can say a lot of things in Japanese that you would think could only be parsed by a computer... For example, Japanese tolerates unusually long strings of negations, of the type: if !(i=!(!x)) like: sore wa fukanou de wa nai to wa hitei dekimasen ne. "You can't deny that it is not impossible, can you." "fukanou", "nai", hitei", and "dekimasen" are all negatives. Another interesting bit is how deeply-layered embedded phrases can get: Daisuke no heya no tonari no isu no shita no gaban no naka no hon no hyoudai wa "The Story of Ping" (desu). "The title of the book of the inside of the bag of the underside of the chair of the side of the room of Daisuke is 'The Story of Ping'".
"Reactionaries must be deprived of the right to voice their opinions; only the people have that right." - Mao
It would look like Ruby.
Ruby is written by a Japanese programmer, and to me it looks just like a kinder, gentler perl. If you read the docs comparisons to Perl are frequently made.
I wouldn't know how Japanese as a natural language influenced the Ruby language though.
Actually, this isn't true. While children in this country these days do learn to read phonetically, research shows that most adults read by recognizing whole words at a time, just after pre-attentive processing, by recognizing the 'shape' of a word. This is an extension of "chunking", which is how we recognize simple components of a more complex syntax in language we may have never heard before.
Check my Go-related blog for beginners: DGD
By using English to describe any concept that couldn't be clearly expressed in Japanese. Keep in mind, most Japanese industrial leaders (in the 1950s), and much of their middle management, were trained in America. This is for their post-war development, and the eventual introduction of "quality" to Japanese work (which didn't exist prior to the 1960s).
As for productivity? Well, the other side of it is that the Japanese have an affinity for management and control systems that's far more efficient than ours. Controlling people is something that can be done in any language.
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
I bet Japanese coders would find a way to make it have really big eyes and/or breasts.
BilldaCat
Most kanji have more than one reading, and many times more than one reading is valid in a given context.
Hmmm... and in Perl, There's More Than One Way To Do It. Go figure.
Nope - the two are entirely reversed. In Perl (and pretty much any computer language given a sufficiently complex task), there is more than one way to phrase a single solution. In most human languages, any given single statement has multiple meanings.
Many beautiful phrases are nonsensical in mathematical or computer terms. Oftimes that is because you are leaping into connotations rather than meanings. "Revenge is a dish best served cold". Revenge is not a dish, and cold here does not refer to temperature.
Other times, you are referring to multiple meanings to create ambiguity - not a useful thing when telling a computer what to do, but a condition that the human mind seems to enjoy parsing, either as humor or depth: "A man walks into a bar. Ouch." That last word forces the mind to have to reparse the previous sentence, and realise its inherent ambiguity.
And then there is the pure nonsense that causes the mind to attempt to parse using all past experience a new item: "Twas brillig and the slily toves did gyre and gimbal in the wabe". Or a justiposition of inappropriate timing: In Clerks the Animated Series, at the end of the Anime sequence, as they stand in victory, give a hearty thumbs up and jubilantly yell "Oh, No!". That's what makes reading poor translations fun.
--
Evan "Who intentionally misspells his handle for a unique string"
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
I had the interesting experience of having my first-ever CS course when I was on a semester abroad in (then) West Germany.
The course was taught using Pascal, which gave me an advantage because, as the post mentions, it's basically English. Of course, the course was taught in German, which took that advantage away again...
I think that you'll find that it's the higher level languages that take the most content from the spoken language of their author. Assembler, while mneumonically based on English, is simple enough that that shouldn't be a problem. And, of course, machine language itself has no real influence from spoken language. Also, something highly mathematical (and abstract) like APL will probably have little language-related learning curve.
LISP is an interesting case as well. It's higher-level, but pretty abstract. It's reportedly impossible to learn if you come from a culture that doesn't have parenthesis, or one that pronounces them as a "click".
-
bukra fil mish mish
-
Monitor the Web, or Track your site!
Eloi, Eloi, lema sabachtani?
www.fogbound.net
I can see some severe problems in communicating in Japanese with lousy radio voice equipment. Often, one missed or slightly mispronounced syllable can completely change the meaning, and speaking clearly and loudly in Japanese is slower than doing the same in English (you might have heard emergency warnings in anime, and know that the very generic "ABUNAI!" (danger) tends to be used where a more specific "DUCK!", "RUN!", or "BEHIND YOU!" is likely to be used in English); it lacks some of the natural redundancy of English and the handy Anglo-Saxon selection of clear, short emergency words. Terseness in Japanese is achieved by leaving out words that are clear by context (by this method, often a rather astoundingly complicated concept can be expressed in only a few words, which is why you can sometimes read several paragraphs in English that explain a phrase used as a name for something in Japanese), and there isn't always a lot that's clear by context in short commands. Speed is achieved by abbreviating groups of syllables as rather subtle compounds that can be difficult to hear under bad conditions. Furthermore, back in the days before transistor radio and TV Japanese was strongly dialectized, which would surely have added to their problems.
I suspect that this might have added somewhat to the top-down military structure, and further restricted the ability of individual units to improvise in a coordinated manner. Of course, that's hard to say, as this was already something of a feature of the Japanese military. This isn't to say that it's strictly a negative thing, there are advantages and disadvantages to having troops either more or less willing to strike out on their own when they think they know better than their commanders (either way, any military operation usually has some spectacular screw-ups caused by this feature).
As for those other replies that dismiss Churchill's comments as wrong in principle or "just plain racist", with the implication that all languages are alike, I would insist that there are very significant differences in the capabilities of languages. This requires different amounts of training to learn the specialized sub-language of any new field. There's a reason you can't understand what the drill sergeant is yelling, or the impenetrable babble of doctors in emergency surgery ("sew up that hole", "give him some painkillers", "saw off his foot", "he bumped his noggin").
If daily Japanese speech is more different from Japanese military commands than daily English speech from English military commands, it's going to take more training to learn a large and flexible vocabulary, so this ability will tend to be restricted to higher ranks.
Churchill was exaggerating, if not flat-out wrong (after all, ambiguity is a special feature of Japanese, but it is also purely optional), but IMHO it's at least plausible that the features of the language were a factor in the organization of the Japanese military.
---
Despite rumors to the contrary, I am not a turnip.
Sanskrit is essentially a simplified form of proto-indo-european (the mother of all indo-european languages). Essentially, much of the tense structure was lost (my Sanskrit grammar is a bit rusty but I seem to remember that the optative and subjunctive hardly had any other tenses than the present), the syntax was slightly altered (for example, the genitive case has gobbled many of the uses of the other cases) and the morphology evolved (all vowels merged to 'a'; a new 'e' and 'o' were formed from vowel+sonant diphtongs, and consants multiplied by palatalization among other things).
Anyway, the point of my saying all this is not merely to brag about my knowledge of Sanskrit philology, but merely to point out that Sanskrit is a rather ordinary ancient indo-european language. Much of what you point out about it could be said of ancient Greek or even Latin. And, more importantly, being an indo-european language, it does not differ that much from English in its basic ideas. So I don't think it would bring you closer to "enlightenment" (in the sense of losing your linguistic prejudices) except perhaps in the spiritual sense of the word (Sanskrit is a "sacred" language :-).
I speak fluently arabic (native speaker), french (nearly native) and english, I can say for sure that english has absolutly no influence on programming languages. The structures used in programming languages are in rather primitives (while, repeat until, if then else, etc) and I guess might be universal. Well according to Turing and Church, Goedel and consors, "all universal, which include human languages are equal :)" what might be different is the way they express thing.
:). The difference might rather sociologic tha intrinsec in my opinion.
But I believe that the "pragmatic" nature of english has really influenced the way people think and solve computer problems. Eglish is really efficien compared to Arabic and French which tend to be much more "constipated" languages, as they feel attaqued by english, they don't tend to evolve very quickly and tend to be conservative, they don't adapt naturally to technologic evolution, as the pramatic and conquerant english
I've also heard, but it's not necessarily true, that a Japanese communiqué was dispatched that would have convinced the Americans not to bomb Hiroshima, but due to a double-entendre, the meaning did not get through.
I watched a two part documentary entitled "Hiroshima" on the nuclear bombings and the events that led up to it recently and actually what did happen was this:
1. The Emperor, the Japanese Prime Minister, and basically everyone in the Japanese Government except the Army wanted to end the war and accept the allies unconditional surrender, but the Army seemed to have a stiff control over the government.
2. The Japanese Prime Minister addressed the millitary over the radio, and when asked what he thought of the allies unconditional surrender ultimatum he used the word (if I remember correctly) Matsato, he said it to appease the troops and didn't think the allies would listen. He wanted to end the war.
3. The allies were listening and couldn't immediately translate it, they brought in a Japanese linguist who said the word meant "to silently refuse", or it could have meant "to silently refuse in hopes of a better offer", but that was unlikely, Truman accepted the first meaning, and then signed off on dropping the bombs.
-- iCEBaLM
If English language should have had any impact on the design of a structural language, the syntax would be more like.
Consider this:
old_a=a;
b=func(&a);
if (a>b)
a=old_a;
Well if the language should be more natural it would look more like this:
old_a => a. /* put old_a into a. */ /* give addr. of a to func and
execute and put the return
into b. */ /* Is a > b ? then put old_a
into a. */
&a @ func => b.
a>b ? old_a => a : .
The abstraction in the (C like) programming language comes from math more than from the natural language and is far more infruenced by math notation than English.
Even OOP is far from the natural language (maybe except Perl). If we try to write a sentence like "Peter gave his Mother the basket" would likely look like this in C++
Peter->give(basket, Mother);
But despite the order of words, the logic is quite different. What is "basket" here? it is a variable holding a reference to an object. Why is it name basket, a part from giving us a clue here? Well, it probably is a generic object pointer that could refer to anything else than the basket. How is basket related to Peter? Is it part of his "inventory"?
object = Peter->loose_item_by_name("basket");
Peter->give(Mother, object);
Now more like it, but we are now leaving the abstraction, that natural language gives. Experiments have been made to make a language less formal, but often they strand on being ambigeous, an issue we deal with in everyday communication without a thought, but if our language wasn't ambigeous, we would be very longish and convoluted in expressing even simple meanings.
Our language consists of three basic kinds of utterations: Statements ("I am hungry.", "The boy was naughty to his Mother"), questions ("Are you hungry?", "To whom was the boy naughty?"), and imperatives ("Pass the butter!", "Please be nice to your Mother!"). Even when questions are expressed like statements ("I wonder if you know how it hurts.") or imperatives like questions ("Would you mind to be more causeous?") we still destinct them quite well, and no further kinds utterations exists.
But computer languages are often separated into query languages, declarative languages and imperative languages and they don't mix well. Look at the C++ example; the imperative language cannot express a (real) statement: I have come to know, that Peter gave his Mother the basket. Even questions are not questions, they are requests for boolean evaluation.
AI is getting better and better results in simulate a conversation, but it is not suited for programming languages, because a program is not a conversation. I ask the computer a question in a program, but an intelligent answer requires an understanding of the context and can hardly be used as a condition, since the answer may be "It depends on other premises."
An idea is, that programming should within time be substituted with communicating values and wishes, that in a fuzzy way gets to actions by the computer that will make us happy, like a manager communicating with his secretary. This may happen some day.
:-) = I am happy
:^) = I am happy with my big nose
C:\> = I am happy with my OS
Not a single Perl Haiku to be found? C'mon people!
Wah!
Top 12 things likely to be overheard if you worked with a Klingon Programmer:
"The urge to fly from modern systems, instead of moving through them to even greater, fairer things is, I think, an indi
Programming languages aren't closely based on natural languages. The first thing to notice is that a programming language only has imperitive verbs (imperitive languages) or is just an absurdly long noun phrase (functional languages).
Most programing languages don't have cases. The first basic I used had two (numeric and string). Unix shells have two (assignment and reference). Perl has several, but English speakers have no more trouble with this than a native speaker of a language with cases. Larry Wall probably knew what he was doing: he studied linguistics, and probably realized that a case system makes it easier to recognize mistakes.
Spelling and phonetics don't matter in a purely written programming language, so the most important classification for natural languages that would apply would probably be word order. Most programming languages do roughly follow English's SVO word order, like "x equals 4". They tend to put modifiers like array indices at the end, like english uses postfixes.
If we read "function(x)" as "ask function x", we can read namespace::object->function(x) as "ask namespace's object's function x", but in another language, we might have to change the order to "ask the function of object of namespace x".
Consider "program arguments out_file". You can read it in english as "program arguments from in_file to out_file". In japanese, you would say, "in_file from out_file to arguments program".
But, if you look at non-imperitive languages, you would think they aren't designed by english speakers. Most assembly is VSO, and is difficult to read aloud in english. Lisp is more or less VSO, and has a complicated syntax that allows you to build phrases of indefinite length. Lisp might make more sense to a German speaker than and English speaker.
Variables and functions can be considered a type of pronoun, where any word that isn't in the language is assumed to be a pronoun.
Just some ideas.
Q: What do you call a person who speeks 3 languages.
A: Trilingual.
Q: What do you call a person who speeks 2 languages.
A: Bilingual.
Q: What do you call a person who speeks 1 language.
A: American.
Last night I was reading Jorge Luis Borges' collection of short stories, Labyrinths. One story involves (amongst other things) a language without nouns like "moon", instead using verbs to describe the action of "to moonate" or the state of "mooning".
It struck me whilst reading that this wasn't too far from a stack-oriented language, like RPN or Forth. Unusually this is a case where a concept was probably more familiar to me now than it was to Borges (famously fond of obscure references) when he wrote it.
There's more to a programming language than the words (or lexical tokens) that describe the syntax. The interesting difference is not whether the reserved word is spelled IF or SI, but the semantic differences of the language's underlying structure. Don't confuse the semantic data model with the mere serialisation (as you chose to mention XML).
Does German's infamous "verb at the end" form encourage functional programming ?
Is the Chinese context-dependent re-use of an pictogram a model of polymorphism ?
Are languages without a first-person inherently supportive of multi-processor systems ?
Could you program in Welsh, just by adding the suffix "io" to all the machine code opcodes ? 8-)
What would Perl be like if it was coded by a native Japanese speaker?
Well, to an English speaker, it would probably look like line noise.
Rather like it does right now.
Tarsnap: Online backups for the truly paranoid
I believe he is more referring to the alteration of the form, relative to various languages, than just converting the tokens. An example, would be Korean, which could be thought of as a natural language RPN, where the general syntax is:
,,, ) convention, which I assume stems from the difficulty in parsing ,,, ,,, ;)
clause -> [object].. verb [tense]
sentence -> [object].. [clause conjunction].. clause term
While there are a few special cases, the overall language is extremely precise, and while fairly position independant when considering object position, specifies that the verb always concludes the clause.
A programming language stemming from a Korean-oriented mind might result in a language with a function call like such:
( "The time is: %t":fmt, [()time]:data )fmtstring;
-which is equivalent to-
( [()time]:data, "The time is: %t":fmt)fmtstring;
As opposed to English, which is relatively position-dependant in syntax:
fmtstring( "The time is: %t", [time()] )
Of course, it's interesting to note that many procedural languages have adopted the (
Weapons of Mass Analysis
points of dispute
"There is absolutely no ambiguity."
You have got to be kidding me. Take a look at 3 or 4 translations of the same passage from the Upanishads, for example. There are often wide variations in interpretation. It its later years, sanskrit words were intentionally layered with multiple meanings, and authors used these to create richness of texture which is impossible to translate. Few translators catch all of the references, even in a common text such as the Bhagavad-gita.
Perhaps, but also with an incredible amount of irregularity. The nominal cases you are talking about are monolithic forms of what we would use combinations of connecting words for. For example, rather than having a locative case of the noun 'house', we say "in the house." There's a reason languages became more modular: modularity makes things more flexible, easier to deal with and to understand.
Note that computer languages have evolved in much the same way, especially if you view the object-oriented paradigm as an extension of modularity.
Don't get me wrong, I love sanskrit. (is it obvious?) However, I think all in all it's just as well we don't speak it much anymore.
Sanskrit is essentially a simplified form of proto-indo-european
Simplified??????
When you make generalizations about declinsions that were lost and so on, remember that there were many various periods of sanskrit, and certain cases that were more prominent earlier on got lost later on, and so forth. In this aspect, there may be more differences between early & later sanskrit than between sanskrit and another language.
what you're all missing....
Look at sanskrit, where is all the power? In the noun. Look at spanish, where is all the power? In the verb.
For example, in the entire 180-some-odd verses of the yoga sutras, there are something like 2 verbs.
Just like in computer languages, we have the Object-oriented approach, (noun) and the functional approach (verb).
I have a lot more to say about it, but this message is long enough!
check out my mp3 page
An interesting paper about this can be found here. While it doesn't address the what-ifs asked about, it's an interesting look at at least the english side of it. Not surprisingly, Smalltalk is a big example throughout.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
http://www.geocities.com/connorbd/varaq/
Be afraid. Be very afraid.
The only real difference is that there is no compiler for the spoken language.
--
Wooden armaments to battle your imaginary foes!
I happen to work with a woman from Thailand, and her variable names are all but impossible to determine meaning from. I would have thought that Thai could not exist with only the latin alphabet, but I've been proven wrong.
As for how things would be different if the majority of code was written in a different language (that a majority of programmers understood, much like English is today), I really think it would make very little difference. True, some languages express certain emotions, situations, etc. a little more precisely than English, but usually an example can be given comparing the same language in which English has a more detailed expression in describing something.
As for Perl, show my mom a program written in Perl and a French poem, and I guarantee you the Perl will look more foreign to her than the French. It's all perspective.
Source code is a lot like a parachute; it needs to be open in order to function properly.
I once read that good chess players learn to recognize patterns on the board, and build up a simpler model based on those patterns.
I am now going to speculate that what may make a good programmer is the ability to build up a mental model of a problem using a similar thought pattern. Basically, you break down the problem into chunks that you understand and, more importantly, you know how to glue those chunks together. You then create a program out of those chunks, and the optimized glue. The emphasis on algorithms and object-oriented programming supports this notion (though it is only a notion).
So, how a native language would effect programming would be more in what sort of natural chunks does the native language have? I don't know enough linguistics to answer this.
Programming languages were developed by English speakers, and reflect concepts represented in English.
:P) The idea of regular expressions is a good example. It's mathematical, not 'natural' (not to be confused with "Natural" in the Kleene-star sense). We all understand regexp, but how much 'natural' language did this understanding cost?
If we were able to divorce ourselves from our language, and design a language centered on computational concepts, rather than linguistic ones, then that language would likely look a lot like APL, or LISP, or those funky squiggles we saw in The Matrix.
It's a hard thing for people to do, separating ourselves from language. Even those of us who speak more than one language fluently, tend to THINK IN A LANGUAGE. Yes, we all perceive concepts abstractly, but we formalise and represent them, inside our own heads, using a language. Communicating is something we do naturally, and we communicate with sounds and printable characters. It's just a part of our biological wiring.
One interesting line from The Matrix sticks out when we think about this: The first 'Matrix' failed because, "some thought we lacked the language to represent your puny little world".. Or something to that effect. The machines considered creating a new language that would have a greater level of semantic richness to describe the problem.
This is an interesting idea, since human languages, all of them, evolved to describe the 'natural world'. We have no problem with understanding the causality of if-then, do-while or has-a and is-a... Even the concepts of OOP are 'natural'. Encapsulation, inheritance, aggregation, these are all natural concepts derived from the natural world and described with natural language. Any human language should be able to describe the world, and so any can be used for programming. The structure of programming languages would not be very different, because they are developed by beings who think in a language used to describe the natural world. {whew}
Now the neat part: What would a language be like if it were designed from the ground-up to be centered on computational concepts, and not those of the 'natural' world?
It would look like APL, with it's huge number of characters used to describe complex ideas that take many words to explain to people. If-Then is easy to explain to a newbie. How do you explain tail-recursion, or semantic closure? How do you concisely respresent a colored-tree (tertiary or more) without using the metaphor of trees and colors?
A language developed in a natural language other than English would not be all that different that what we're used to. (Not that PERL looks anything like English to begin with.
A language designed around computational concepts would look cryptic and superbly compact. The idea of programming patterns could potentially be represented as a single character, or a small set of glyphs which would require a long verbalization to translate into a human language. Such a language would likely be LISPish in structure, where instructions and data would blend seamlessly into each other.
This language would probably use coding-time translation tables and run-length instruction encoding in source, and would build complex concepts from little ones whenever needed; much like we do with functions, but from a much finer, to a much broader scale. This language would be self-referential, self-describing and self-modifying.
A langauge like this could not be designed by a human, because we are by definition prejudiced towards 'natural' languages. A computationaly centrered language could only be written by a machine which itself would have the capacity for manipulating abstract concepts. A pretty tall order.
A programming language designed by the ancient Celts, the Arabs, the Japanese or Babylonians would certainly APPEAR very different from Java, but after translating it - it would be simple to understand. A language built on un-'natural' concepts might not be comprehensible because it might include concepts we can not conceive of.
Time to re-read "Godel, Escher, Bach" one more time.
-- What you do today will cost you a day of your life.
I can imagine this conversation between two native speakers of Japanese:
"English is a really ambiguous language. It doesn't have words for politeness levels."
"Actually, it does have words like 'sir', 'madam', and 'boy', but for some reason, people don't use them. I guess they just deduce the politeness level from context."
And if this were the 1980s rather than the 2000s, the conversation could go on: "Maybe that's why Japanese manufacturing firms are kicking the Americans' butts -- since the English language doesn't mark politeness distinctions clearly, American workers don't respect their bosses as much as Japanese workers do."
--
send all spam to theotherwhitemeat@ropine.com
I speak a little Japanese from what I took in college, and there are some unique features of the language that might effect syntactical structure.
For instance, the acting verb in a sentence almost always occurs at the end of a sentence. To use English with Japanese grammer, the sentence, "I use Perl," would roughly reconfigure as, "I Perl Use."
This may have the effect on function definition and usage. Perhaps this would be the case:
{
argument++;
} function (&argument) increment;
i = 0;
((i)increment)print;
I think the one other good way to trace or guess as to the syntactic etomology of a programming language would be to look at that nation's written mathimatic syntax, as many computer languages stem from math notations.
-AP
I just finished (re-)reading Steven Pinker's "The Language Instinct" where he 1) explains Chomsky's theories and 2) expands on them with his own theories. (I'm no linguist, so expect this post to be followed by a lot of "you are an idiot", "do some research" or "that's not quite right" posts)
First, people don't think in the language they speak in. When you think about a dog eating ice cream you don't literally think the words "The dog is eating ice cream". There is some "mentalese" that you are actually using. When you decide to speak aloud, you translate this mentalese into your language of choice (English, for me). My understanding of Pinker's explanation of Chomsky is that everybody has the same mentalese.
That said, here is my addenda to Pinker's explanation of Chomsky's theory (with help from Church-Turing) would be: All programming languages are equally powerful and isomorphic. This indicates that there is some abstract "algorithmese" that all programmers (can) think in. Therefore, while it may be the case that C is especially close to English*, but if so it doesn't really matter.
*I doubt this is the case. C is very verb-oriented: printf(the_data). C++ is very noun-oriented: the_data.print.
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
We probably would have ended up with much the same constructs, just with different words representing things. Why? Because it's not really based on english - it's based on machine code, logic, and math. English is just what we use to represent these things (if, while, whatever function calls, etc...)
Addlepated - punk & metal
In his The Second World War (a six-volume set mainly of his memos as Prime Minister and Minister of Defense for GB during that war) he attributes the collaspe of the Japanese Navy's offensive strategy in the South Pacific (particularly the setback in the Coral Sea in 1942) to the ambiguties of the Japanese language. In substance he said the Japanese had to withdraw and regroup whenever a tactical plan met with an obstacle because of language ambiguities, while the English-speakers could communicate in clear, definite fashion to make ad-hoc adjustments as needed.
IANALinguist, but I found Churchill's comments fascinating. If some Japanese-speaking /. community-members want to refute this notion, please do. (I'm not proposing it is true, only reporting what the Prime Minister said).
Now hiring experienced client- & server-side developers
-- @rjamestaylor on Ello
One of the original design intentions of Smalltalk was to create a language which resembled english more than other programming languages of the day, but remaining terse and effecient enough. While Smalltalk doesn't look exactly like english, it follows a similar syntax as basic english sentences- noun verb and noun verb noun.
To me, I see Smalltalk as resembling the language of the Ojibwe people, a Native American tribe which lived in parts of Minnesota, Wisconsin, and Canada. While I'm not an expert in Ojibwe (having only one semester worth), I have a basic understanding of the general mechanisms of it. Ojibwe is very modular and simply sytactically, much like Smalltalk, whereas english is simple sometimes, but there are many gotchas even in simple constructs.
Ojibwe has the concepts of a pre-verb, that is, a one syllabal modifier of the verb, to change context. They declare future and past tenses, as the desire-to-perform-the-verb, the probability-the-verb-will-happen and others. It'd be an interesting idea to introduce to a language- small messages to an object to change context it's recieving it. Perhaps something like "(anObject become: somethingElse) doThis". Currently not used often, using them as a fundament of design might develop a new way of solving problems and coding the solution.
Nindigoo ojibwemong Enigoons. Giga-waabamin!
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
In my opinion, programming languages mirror natural languages only loosely. But there are certainly some things which makes programming
languages similar to natural English:
(1) English is almost inflection-free, which means
(2) that it has to have a strict word ordering
(3) which make programming languages simple to parse
German, however, has case markers and therefore
free word ordering.
So, in principle, you could exploit that feature
in a natural-language-like programming language:
ASSIGN value TO variable
WEISE der Variablen den Wert ZU
WEISE den Wert der Variablen ZU
which would be unambigious in German.
However, the case markers in German are in many cases bound to the articles, and usually, one just would have something like
ASSIGN b TO a
WEISE a b ZU
where the case markers have disappeared, so
even the German version would have to rely on a
(previously agreed upon) word order.
Thus, the strict word ordering of today's English-like language seems pretty inevitable to me.
However, if we leave the realm of Indoeuropean
languages with its "a does b to c" scheme, the
question would certainly be a different one.
Agglutinating languages? Non-ergative languages?
They probably might have developed a totally
different concept of writing down algorithms
(or might even have developed a non-von-Neumannian
machine).
Damian gave a talk on the module at the O'Reilly Perl Conference, but unfortunately neither the talk nor the module is available on-line. He said he was going to post the module to CPAN, too... Maybe it's time to bug him about that.
Anyway, a person who attended the conference faxed me his paper for the speech; if you're interested, e-mail me (after de-spam-proofing my address), and I will fax it to you.
Vovida, OS VoIP
Beer recipe: free! #Source
Cold pints: $2 #Product
If perl were written like Japanese, it would have different forms depending on the computer's relationship to the coder. If the computer were older or higher in social status than the coder, the coder would have to use elaborate formal endings on all suggestions (commands would be forbidden). If the computer were younger or lower in social status, the coder would be able to use short, direct commands, and would not have to address the computer by title, or bow after each statement.
Men and women would also have different vocabularies. It would be considered improper for a male to use "Ladies' Perl" in most computer environments (except perhaps the Mac).
---- "If we have to go on with these damned quantum jumps, then I'm sorry that I ever got involved" - Erwin Schrodinger
Of course, the opposite would happen with German Perl. You'd create new words by concatenating existing ones, so you'd have a word 4,000 characters long which would do everything related to a specific task -- change one of the component phrases and the new word does something related yet different.
Moreover, I'd say that the only difference would be the names of the keywords.
Languages like Japanese (for example) have a completely different grammatical syntax than English. But then again, so does programming... The difference between coding in one langauge or another is mainly syntax and vocabulary, just like with the differences in spoken languages.
However, all programming languages are meant to make it easier for the programmer to communicate with the machine. Since it all gets converted into machine language anyway, most programming languages have a syntax that is more mathematical. So, even if our founding coders spoke a completely different language, the syntax would probably have been based on mathematics.
This leaves only the vocabulary to be a little different... meaning that we would probably only have different keywords.
"If we knew what we were doing, it wouldn't be called research." - Einstein
The grammar of Sanskrit is very tough to learn since it is very vast and there are a lot of things to remember than in a language like English (somewhat like C++ being more complicated than C). But it's all very very logical and straightforward. The main thing is that there are a lot of forms of the same word. For example, udyanam means garden; udyanasya means "of the garden", udyanat means "from the garden" , and so on. There are several forms of the same noun. Each form has a unique meaning, and each meaning has a unique form. There is absolutely no ambiguity. Same for verbs and adjectives and other language constructs.
One beauty of this uniqueness is the fact that now the order of the words in the sentence doesn't matter at all. For example, consider that you want to say "I am going to the garden." Aham is I, udyanam is garden, gacchami is going. So I would say, Aham udyanam gacchami. Now I could also say that udyanam gacchami aham or gacchami aham udyanam or any permutation, all of which mean exactly the same thing. Taking this one step further, I could simply say udyanam gacchami since the verb gacchami implies the "I". If it was somebody else who was going to the garden, I would have to say gacchati, and if it were you, I would have to say gacchasi so the verb form implicity determines the subject.
This is just a novice example of the fact that a lot of semantic information is built into the syntax of Sanskrit in a very elegant way that would appeal to purists and compiler designers. I believe that natural language parsing of English and other European languages is much tougher than parsing Sanskrit would be. The downside to adopting Sanskrit would be the vast number of grammar rules and verb and noun forms that have to be learnt.
Professors in the few universities in India where Sanskrit is still being taught strongly advocate the use of Sanskrit for computing. I just know high-school level novice Sanskrit, so if there are Sanskrit gurus among you, speak out with more relevant details.
Anoop Iyer
Apple Computer released the original version of AppleScript in 1992 with 3 dialects: English, Japanese and French. Not only did they all have native keywords, but the AppleScript engine was able to do automatic translation between them. And it worked, too -- word order, proper syntactical constructions, plurals, masculine/feminine, etc. etc.
This made for a really, really cool demo, especially for Japanese people who read little English. I did this a number of times for people and their eyes lit up rreally wide, and I could tell they were thinking "so that's what all that gobbledygook programming stuff means... "
Non-English dialects were killed from AppleScript two years ago, likely because it was too much effort to support. But it was way cool.
- Olof