This page lists ways in which programming languages resemble the EnglishLanguage, or other natural spoken languages. One purpose of this exercise is to determine whether such features really do improve readability.

CeeLanguage (and CeePlusPlus):

	* Operators "and", "or" "not" etc. in addition to "&&", "||" and "!"
	* Side-effects of short-circuit operators: "PrivoxyWindowOpen(file) or die();"

''The first feature is very obscure. I had never heard of these and/or/not aliases before, and when I first saw them here, I thought it was a mistake! The second feature, while it will work, is simply not idiomatic C or C++. I think this page should only have idiomatic examples, because it talks about "which programming languages resemble the English language", not "which programming languages can resemble the English language if you really, really stretch for ways to make it resemble English". - Kef Schecter (FurryKef)'' I have seen the 2nd form before; true enough, it's not idiomatic, but it definitely does occur in production code. -- SamuelFalvo. That way round is very common in shell scripting, and I'm fairly sure that this application was explicitly pointed out in both the old introductory C and C++ books I have. Using it with "and" is very common, especially in object-oriented C, with a test for nullity and some operation on the pointer being quite commonly combined.

PerlLanguage:

	* Postfix conditionals on single statements: "print if /spam/"
	* Implicit variable "$_" avoids counter-intuitive temporary variables. Implying things is a trait of natural languages, though this resembles more of a pronoun-by-omission that's not present in English. (See JapaneseLanguage)
	* Operator and statement "unless" makes "if (!(...))" more readable: "print unless /spam/"
	* Boolean operators "and" and "or" in addition to "&&" and "||"
	* Side-effects of short-circuit operators: "open file or die"
	* Alternative prefix method notation: "$bear->kill" becomes "kill $bear"
	* Right-grouping of space-separated expressions, e.g. "foo bar $baz" parses as "foo(bar($baz))" but "foo $bar, $baz" as "foo($bar, $baz)"
	* Sigil changes from singular to plural on subscripting, e.g. "my @list = (1, 2, 3); print $list[0];"
	* Expressions mean different things in different contexts.

RubyLanguage:

	* Postfix conditionals and short-circuit operators work as in Perl.

SmalltalkLanguage:

	* All statements are imperative noun-verb. ''Are all statements really imperative? And aren't all object-oriented languages noun-verb? [Not if they support MultiMethods.] And aren't imperative sentences in English usually verb-noun?'' [Not in sentences of the pattern "Robot, go east" or "Dungeon Master, give me the sword."]
	* Multi-word method names can be used as prepositions. (from:to:do:)
	* The employment of punctuation characters in Smalltalk is analoguous to that in English. (Semicolons and especially periods.)

CobolLanguage:

	* This is too easy. Most statements are designed to look like English sentences. Grammar is even described in human-linguistic terms, with paragraphs, sentences, clauses, and verbs. (Yes, "IF" is a verb.)

PythonLanguage:

	* use of "is" and None: if theElement is None: return
	* use of "in": if theElement in myArray: print theElement
	* use of for and in: for eachStudent in theClass: kiss(eachStudent)
	* List comprehensions which combine the above with a postfix "if": goodStudents = [eachStudent for eachStudent in theClass if eachStudent.grade > 90]
	* the "is not" and "not in" operators, in place of "not _ is _" and "not _ in _"

ForthLanguage:
	* Make up your own "syntax" to be as English-like as you want.
	* Comments are in parentheses.
	* PostfixNotation often looks less "mathematical" than prefix-function-application syntax.

StructuredQueryLanguage:
	* The use of a "word" can often precede its declaration, despite the fact that the meaning cannot be inferred without the declaration.
	* With "as", you can define your own synonym for any name or expression.
	* The language is structured generally around a single "verb" with a list of objects and several "prepositional clauses", and indeed the overall structure of a query resembles an English sentence.

CommonLisp:
	* Keyword arguments fill the role of prepositions, so that programmers need not remember the order in which arguments are to be provided, or change that order when the function changes.
	* Expressions have a uniform verb-noun syntax, like English-language commands.

AbcLanguage:
	* You can define functions with prepositions: HOW TO SPLIT sentence INTO verb AND noun

ToolCommandLanguage

	* No reserved words, user defined commands have are treated the same as inbuilt commands so new structures are easily implemented
	* space separated arguments
	* many commands have optional parts to make them seem more English; e.g., if {} then {} else {} the then and else are optional sugar
	* redefining unknown lets you assign a funtion to a pattern rather than a whole name e.g can be used to change the normal tcl prefix notation to postfix or infix

InformLanguage (version 7 onward)
	* Designed to be English like (much like CobolLanguage) but perhaps works a bit better due to the narrow application domain (interactive fiction), and by virtue of being a logic language (where statements of fact really do correspond to statements of fact.)

----

Ways in which not enough programming languages are like English:

'''Prepositions'''

Function calls in most modern languages tend to have nothing but commas separating them. Witness VbScript programs that have to deal with MicrosoftWord documents in terms like this:

 Word''''''App.Documents.Open File''''''Name,1,1,0,"","",1,"","",0
There are little-used conventions in this and similar languages that allow you to explicitly name parameters, but they are seldom used because they tend to be so verbose. And in VbScript's case, you can't use built-in constants anyway, so it doesn't help much.

 Word''''''App.Documents.Open File''''''Name, Confirm''''''Conversions = 1, _
	Read''''''Only=1, Add''''''To''''''Recent''''''Files=0,"","", Revert=1,"","", Format=0
The obvious solution would be to name your arguments after prepositions, but in many languages, prepositions are reserved words. In VB, "for", "to", and "with" are all reserved. RubyLanguage may be a little more flexible, since it claims "reserved words aren't", but I do know you still can't use "for".

SmallTalk gets around this by making prepositions and other argument specifiers a part of the symbol name. ''If I had Squeak installed, I'd check now to see if you could have a method called self:super: legally."

Several languages offer KeywordParameterPassing, which addresses this issue.

'''Adverbs'''

Many functions have true/false parameters that specify how the function should be performed. Others have a big bitmapped integer that can be boolean-mathed into all kinds of flags. But don't you wish you could just do something like this:

 MsgBox "Can't open this frightfully important file!" Urgently
----

Being unlike English is not necessarily a bad thing. The English language (like other natural languages) leads to a lot of redundancy and ambiguity. Anyone who has programmed in a language that tries to be a lot like English (CobolLanguage, AppleScript) usually finds the necessary phrasings to be too verbose. (For example, "set the x-coordinate of the top-left-corner of window to 0" rather than "window.topLeft.x := 0".) A terse domain-specific notation has benefits. Think about how algebra and calculus would be if we had to do it in English. -- KrisJohnson

Perhaps, but there are some things English has that are both efficient and familiar. But you're right, and in fact when I created this page, I noted that I couldn't think of any examples offhand for PythonLanguage, which is considered one of the most readable of the current generation of scripting languages. Indeed, this supports that the things which make languages readable are not the things which make it like English, and fights against the CobolFallacy. Just look at the popularity of ForthLanguage, despite how its stack-based syntax and reverse-Polish notation create rather mind-bending word orders to the uninitiated. ('''X @ 3 > Y @ 5 < OR NOT''') -- NickBensema
----
The syntax of one routine calling a subroutine is not only hierarchical, but dictatorial because the communication between caller and subroutine is dictatorial in nature. The caller commands the subroutine to act and gives it all the required arguments. The caller must be smart enough to know what arguments the subroutine requires, e.g., f(x). 

However, in the universe, not all communications are dictatorial, some are dialogs. A caller says, "come on over and have dinner with me and my wife." The callee says, "That sounds good. What time?" The caller responds "7:30ish." That dialog is basically f(x) = come-over(7:30ish). 

A language can be designed to use peer to peer communications between caller and called? Moreover, that language can have an infinitely variable syntax, like English. Is that language already classified? Does this language constitute a new paradigm?

-- EdwinEarlRoss

''You appear to be informally describing a casual mix of ActorsModel, FuzzyLogic, and NaturalLanguageProcessing, which smacks of StrongAi. I'm not aware of any language that supports infinitely variable syntax -- not human languages even variable syntax are infinitely, though perhaps some natural languages close-ify. :-) To be a new paradigm, there would need to be some core distinguishing characteristic upon which the language (or a family of languages) is based, preferrably with a formal theoretic foundation.''

Perhaps I characterized this argument passing process inappropriately, I'm not a language pro. Just a programmer who has used a lot of languages over the years.

A metalanguage called TACL has the ability for a routine to get its arguments, character by character, from the caller line. See: http://docs.hp.com/en/NSGSeries.html, "TACL Reference Manual." Pages describing #ARGUMENT 9-21... and pages describing ROUTINE 4-9... describe how a TACL ROUTINE can get its arguments, including a character at a time, from the calling line. 

This process of calling and getting arguments seems like a dialog to me, instead of a command call with all the arguments pushed on the subroutine. 

Since a ROUTINE can get characters from the call line, it can parse whatever argument syntax for that ROUTINE that its programmer wants (maybe infinite syntax variety is an overstatement). In this particular language, the arguments must always be trailing the routine name on the call line. But, that is not an absolute restriction on all languages.

-- EdwinEarlRoss

P.S. I don't understand the math in http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-194.pdf (re: ActorsModel). But, the distributed environment is familiar to me. TACL runs only on Non-Stop(tm) computers, which is a distributed network of fault-tolerant multi-cpu nodes communicating over a network. I programmed on a Tandem (now HP) for many years. My comment about caller-callee dialog is not only applicable to a distributed environment.

For me, the division between writing a subroutine and writing an application server has become blurred. Whichever one you write, the purpose is similar, to make an object that does something for you when called. The difference between the two is not what the object does but how the call is done. What syntax difference is required between calling a subroutine and calling a server? -- EdwinEarlRoss 

''Sorry, not quite following you here.  Various forms of RemoteProcedureCall require no syntax difference between calling a local procedure and a remote procedure.  E.g. CORBA, Java RMI, .NET Remoting, WebServices, etc.'' 

Thank you, I wasn't sure and had to ask the Q. You have confirmed what I believed to be true, "no syntax difference between calling a local procedure and a remote procedure." -- EdwinEarlRoss

PPS My comment about caller-callee dialog is not about ActorsModel, FuzzyLogic, NaturalLanguageProcessing, or StrongAi. -- EdwinEarlRoss
--------
See Also: TheRightWayToDoWordyBlocks
----
CategorySyntax