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.
Scheme is not "fully functional". Neither is Common Lisp. No one will say they are mostly imperative either. But they work; before AI winter there were many machines and OS's built on top of them and their immediate predecessors.
If this author's definition of "does not work" means that they can't be used to build operating systems or high level AI programs well...
No runtime consing of closures either!
In fact, in Common Lisp there is a style of writing call-with-foo that takes a closure and wrapping that with a macro with-foo. Since the macro abstracts that detail of having call-with, it is much more flexible. For example the macro could expand some stuff known at compile time and do some compile time computation too., instead of the closure consing function.
the article brings up a good point with 'systems language'. What is a systems language anyways? I guess C is, but whats the definition? Is common lisp a 'systems language'? After all, a good number of operating systems have been written in common lisp, but is it too freewheeling and high level to be considered a 'systems language'? Is java a systems language?
Semantically, I'm writing in common lisp. If you mean the syntax, that's an ad hoc thing that comes up when writing in an HTML text box and emacs isnt here. But the syntax is shallow and unimportant compared to the abstraction presented. (it's just normal lisp syntax with implied parentheses anyways, so it's a bit ambiguous)
Sure, ruby has nice syntax for lambda, but the entire point is not even having to worry about what goes into blocks and what not. Syntax is a bad excuse for abstraction. Lisp has higher order functions too, but a deceptively short (or "natural") syntax can easily sweep ugly semantics under the rug. I know no one would ever write your defclass hof anyways because of the extreme runtime overhead that causes. If you wanted to reimplement your defclass macro more efficiently, I don't see how you would be able to do so while not breaking all of a users code relying on that function. The point of a macro is so the implementation detail is hidden, and the interface doesn't have to change when you change the implementation. Lisp has higher order functions too. Hell, that's where ruby got it from. Higher functions have their uses, but they are not for abstracting patterns in code like macros are. They are for abstracting procedures in code on arguments received at runtime. The difference is macro expansion happens lexically, at compile time, while functions are part of the program at runtime.
If you haven't seen a practical example of what it's useful for, that's akin to the attitude of a C programmer not understanding the usefulness of higher order functions. They say, I get 95 percent of the way their with good old functions and function pointers. We would find that absurd, just as how I find the claim that a 'simple practical example of where added power of a macro is useful does not exist' is absurd
For example, see 'A unit testing framework' in 'practical common lisp' available online by Peter seibel. I can't possibly imagine how you'd be able to create a unit testing framework abstraction in Ruby as nice or efficient as the one presented with higher order functions in 26 lines of code. But it'd be cool if anyone could prove otherwise.