Absolutely not. Czech orthography is beautiful. Latin letters, clear featural marking of palatal consonants (č, š, ž, ď, ť) and simple marking of vowel length (á). The spelling is even morphophonemic!
Machine translation is AI-hard. If this happens in 30 years we might as well have reached the singularity as computers will understand natural language and all of its meaning completely.
NLP is a domain specific problem. Of course it shouldn't be under computer science. Pure computer scientists are much less useful than linguists for these things. That's like arguing that building physics simulations is under the realm of computer science. You'd want your team to be mostly linguists, some which specialize in computational linguistics. A vanilla computer scientist, to be frank, is almost useless, especially at the PhD level.
Elisp would still a better much better language than python or Ruby (for emacs), especially now that lexical binding is becoming standard. Emacs people would like to move to scheme, if anything. (even RMS wishes emacs would move to scheme.)
On the flip side, most of the world is multlingual or have at least been exposed to one other language. If you speak more than one language, mixing words from two or more basically renders dictionary attacks impossible, especially with number of languages and type unknown. I have words from non native languages in my passwords and they are just as easy or easier to remember.
I think you're confusing syntax and semantics. The claim is that C is not really semantically well defined, but your toplevel posts talk about the fact that C has well defined syntax, which is true. However, that's besides the point. Syntax is roughly the surface form, whereas semantics refers to meaning. The problem is that a well formed program (ie a syntactically correct program; this is actually the precise definition of well-formed) in C yields undefined behavior on a semantic level, exactly what we don't want to happen. You need to maintain a clear separation between the syntax and meaning. When parent said that its legal C, he meant syntactically. The point is by definition you cannot tell from the surface/lexical form of C what is semantically valid and what is not semantically valid, ie what is well defined and what is not. So by saying its undefined behavior you are proving parent's point, that a syntactically valid piece of C yields a semantically not well defined chunk of code.
In Common Lisp, you write to source code files and then use ASDF/Quicklisp to compile/load that project. If you feel the need to create a standalone executable you can dump the image with an entry function specified. It's essentially the same as python, although standalone executable are less prominent than in-image programming.
No, programming languages are completely different from natural languages. You are conflating some concepts here. There are artificial programming languages which are context free and express computation more or less. Then there are artificial and human languages which express statements in real life and are not context free. Its obvious that some methods of expressing computation are easier for humans to comprehend than others and are formed on a much more mathematically logical basis. For example, the lambda calculus is much more readable than a turing machine and has 3 easy mathematical rules, although it is harder to implement on a von Neumann model.
Sapir Whorf applies strictly to natural languages and to some extent constructed ones, but here most modern linguists agree it in its strong form has been discredited in the same way that race instrinsically influencing behavior has been discredited. People are people, and looking at historical sound change should convince that sound changes over a long period of time do not change any absolute measure of "complexity" in a language in a well defined way.
Please tell me this is sarcasm! It's hard to tell. If it isn't, then all I have to say is that hacker news is written in the lisp dialect arc of Paul Graham, who got rich off of a customer facing site written in common lisp...
It's not a question of inherent difficulty, which doesn't make sense to quantify absolutely. It's all about how similar it is to the random person's native language, phonologically, morphologically, syntactically etc... Obviously Portuguese would be faster for a Spanish speaker to learn, since they are very similar in many aspects (in fact, they are both very conservative Iberian Romance languages) than it would be for a Spanish speaker to learn Polish. On the other hand, Polish would be easier to learn than Spanish for a Czech speaker. None of these are objectively more "difficult" or "complex" than one another. They are just "different".
The central axiom of linguistics is that no language is inherently more expressive than another. Yes, that means that conjugation and declension is no more complicated than strict word order. Grammatical gender provides redundancy, and conjugation allows for subject pro-drop. Orthography has nothing to do with the actual spoken language and things like "phonetic" pronunciation are not really an intrinsic feature of any language. Any language can be matched with a phonemic orthography; the only reason written English hasn't been is due to historical inertia.
Good Common Lisp doesn't use lists. A Lisp app does nothing like processing lists; in fact, Common Lisp only uses list-processing for processing source-code (aka macros). It is much more like a faster, more functional Ruby or Python in that it uses classes, looping, but encouraging good functional abstractions. Real-world Common Lisp looks nothing like scheme.
SLIME emphasizes interactivity. Coupled with the fact that it uses the full power of Emacs (which is a small lisp vm, though a different dialect of lisp), you can do things like inspect any object or package in your system on the fly, view class hierarchies of your image, live documentation access, live disassembly of a function, incremental compilation into another buffer, arglist inspection, easily add amazing tools like paredit, autocompletion, inline macroexpansion utilities, source location lookup for functions and global variables, with Common Lisp spec lookup of any symbol all with with two keypresses or so. While many IDE's provide some or even all of these features, they are rarely as coherent and easy to use as they are in SLIME. Plus, SLIME itself is more easily customizable than something like Eclipse, because it uses elisp and common lisp as the backend language. A downside though, is that learning emacs is a prerequisite to using all the features of slime.