<p>"Too which I can respond to with: "You must be doing way too much narrow coding in C or Fortran." Take a look at Lisp or Scheme, or hell, any functional language will do. Let me address the points you just made (a lot of these revolve around Lisp/Scheme):"</p>
<p>Granted, I haven't played with Lisp or Scheme, and do use C++ a lot, but I also do higher level programming in Perl or Python (which don't compare to Lisp, but oh well). Let me see if I can defend my point of view...</p>
<p>"Computer languages like Lisp where data and code are one and the same can be used to express a huge variety of ideas that you can barely express in typical spoken languages. So just as you argue that computers can't describe everything, there are tons upon tons of things that the spoken language can't describe (take a look at any advanced AI textbook, most of the ideas will first be explained with Lisp/Scheme code and then they will try to run around the idea with English)."</p>
<p>I'm not sure I know exactly what you mean. Could you quote a passage from an AI textbook for me, since I don't have one here? However, in these cases, is it the programming language itself that is used to describe these ideas, or does the language describe a system which can describe/process/store the ideas? I'm suspicious you mean the latter.</p>
<p>"Unless you use a computer language like Lisp/Scheme where there are so few rules that you are actually encouraged to rewrite the programming language to your own specifications. So if you're working in C, then sure there are tons and tons of rules, but if you are working in an expressive language like Lisp, then you can just rewrite the rules however you like."</p>
<p>Again, not being too familiar with lisp except for a vague understanding of lambda calculus and the excess of parentheses, I might be sounding stupid, but:</p>
<p>When the interpretation/compilation of a program starts, before the first line of code is processed, there are ground rules that have no exceptions. Once you start executing code, the code may change those rules, but each change is spelled out in the code. If you know all the ground rules, for which there are no exceptions initially (making them fairly easy to memorize), then you can pick up some code and understand it. However, in order to read this text right here, even though the text itself doesn't redefine the grammar and syntax of the English language, you had to be familiar with a vast number of rules and exceptions which are built into the language specification, making it a royal pain in the rear to learn in the first place. Also, spoken languages have things like idioms (such as found at the end of the previous sentence), which make it even worse, and are fundamentally impossible in a computer language.</p>
<p>"Actually if you work with many people, overtime you will end up pronouncing most terminology similarly. It's not something very special about spoken languages. It's more an issue of standardization. And just like you use pronounciation to convey subtle messages in the spoken word, you write computer programs with certain styles to better express what you are trying to do."</p>
<p>Still, voice is not a natural way to express a computer program. If I wanted to ask you a question about some code I had written, I wouldn't recite the code to you (unless it was very short), or even read it. I would show it to you on my screen, or print it out, or just write it out on a scrap of paper.</p>
<p>"Sure there can [be ambiguity]! Take any language that has first class functions and you're set!"</p>
<p>First class functions do not introduce ambiguity. They may make it more difficult for a human to understand code, but I challenge you to show me any bit of code in any programming language which will produce different results on subsequent executions given the same input data and initial state.</p>