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.
A higher order function doesn't serve the same purpose as a macro. A higher order function is meant to be applied, called, composed etc. A lisp macro is a different type of abstraction. For example, many people think that macros are just hiding lambda's of higher order functions. This is wrong. A macro abstracts over implementation details of a construct to make it read naturally. For example, you can write a function that opens and then closes a file like so...
with-open-file(filename, lambda file: do stuff with file)
but with a lisp macro, you only have to write
with-open-file (filename):
do stuff with file
The point of an abstraction is so you don't have to think about the implementation. Written like the latter, with-open-file is simply more natural to write this way. You only have to think, "oh, its a construct that opens a file then closes it after the body is done", rather than "oh, its a higher order function that i have to pass another function into that takes the file as an argument..." etc.
When you write with-open-file as a macro, it could be implemented as a higher order function, or it could be implemented as a low level set of GOTO statements. It doesn't matter. The macro abstracts away the low level detail, just providing the most natural way for you to use the construct.
It might not seem like the macro is doing much in that particular example, but a construct that defines a class (like defclass) is something you can write as a macro, which can expand into functions that do the actual defining. You could write a class defining construct as a higher order function, but then you'd have to constantly worry about how your construct was implemented as a function. instead of just writing something natural like
defclass tiger (animal):
age init-value: 0
name type: string
which you could write if you implemented defclass as a macro.
otherwise,
you'd have to do something crazy stupid like
how could a higher order function possibly implement that without making people using it tear their hair out?
They have to bend to the implementation, not make the abstraction bend to what's natural.
Well, those functions are pretty much obsolete. No one uses them. They are only in the standard for backwards compatibility (and don't use that as an argument because that is a legitimate reason and those names are easily ignored. they are not taking up a precious name-space). Everyone binds special variables like * print-readably* , * print-circle* , * print-base* which, would you look at that, have nice comprehensible names. Prin1 doesn't have any cognitive load on beginners at all since no code written after 1984 has prin1. I guarantee you that all the names _you_ would find esoteric in Common Lisp have less esoteric equivalents. (car => first, cdr => second etc..) And pprint? well, that's a commonly accepted name even in the python world for pretty-print.
I guess most of the names you complain about is things that you haven't seen in Ruby and aren't familiar with. On the other hand, I can easily argue that in your code snippet above that {|i| ...} looks like garbage to me since every language _I've_ encountered uses lambda(x) = x ... or x, y => ... for something as fundamental as lambda functions. Of course, this would be ridiculous for me to argue since every language has their differences in names and syntax that simply don't matter compared to the actual concepts themselves.
This. Arguing that Common Lisp sucks because the names of functions are not sufficiently python/C/Algol-like is like arguing Chinese languages are never going to become widely accepted because they aren't sufficiently like European languages. People who argue against car/cdr are the same people who will blindly accept printf, strlen, scanf (wtf?), __le__, zip. They accept those names because they actually learned the language and discovered those were trivial details and don't judge something so superficially. (also, ~95% of common lisp names are more like with-open-file, or define-setf-expansion, or make-load-form, or most-positive-float, or standard-input, instead of, what mkStr, <stdin>, isalnum, fprintf, ? :, and the like)
Definitely not. It's almost hard to think of what Lisp doesn't let you change at runtime, since the compiler is always there. Common Lisp is in fact much more dynamic at run time than python/ruby/smalltalk. I would say that Python and Ruby are the more limited ones. You can recompile functions whenever in CL, you can even compile functions that call undefined functions at runtime. Lisp is known for its extreme late binding and reflection, with almost everything redefine-able on the fly (except functions declared inline, you need to recompile to callers afterwards. but only if you declare them inline). Even in defining classes, Common Lisp will redefine a class and update all the _old_ instances of the class as well. As far as I know, Ruby and Python do not automatically update old instances. Ruby, like Common Lisp, does allow you to add new methods at runtime without redefining the entire class, and as far as I know python does not.
> The vast numbers of CL and Scheme compilers are relatively easy to write, exactly because the languages leave (somewhat) less to decide / change at runtime than Python/Ruby/JS.
I would say it's a mistake to conflate Scheme and Common Lisp. Scheme isn't even defined well enough to say something implementation independently about whether the environments should decide things at runtime or not. But Common Lisp as a language has special/dynamically scoped variables and runtime definable macros which make it much more difficult to write a compiler for it. I would say that Common Lisp has way more things to decide at runtime than python or ruby. Maybe they're about the same in terms of difficulty of writing a compiler for, if only because lisp has no parsing/lexing pass. Again, in the end, it's mostly not a language issue. It's how much money and how many compiler experts work on your implementation.
SBCL targets x86, alpha, ARM, x86-64, and PPC in fact. Python doesn't actually target C, it targets a bytecode VM that's interpreted by C. which obviously is much easier to do. (there are many CL implmentations that use this approach as well eg ECL CLISP...) It just doesn't seem like Ruby or Python has the sophistication/resources yet to move their main implementations to native code, aggressively optimized compilers (yet). Which is unfortunate considering CL, Dylan and small talk got there first 30 years ago.
The public domain CMUCL/SBCL line of compilers (as well as most commercial common lisps) are notorious for being the fastest dynamic/interactive systems since the 1990's. Most dynamic languages are still nowhere near the speed of the assembly code produced by most common lisp compilers while still retaining the impressive dynamic & incremental aspect of the language (although every year they are closing in). In the end, it comes down to how much effort was put into these compilers, rather than the language itself. For years DARPA spent loads of money on a highly trained team of compiler experts to work on CMUCL (later SBCL) led by Scott Fahlman. I doubt Ruby and Python will be able to attain JS speed until more effort goes into on these systems, which so far are still defined by a canonical, byte-code interpreted implementation.
Maybe give CL another try? Since the mid-2000's the ecosystem has definitely improved exponentially. (ala Quicklisp, Quickdocs, and related portable libraries)
Threading has a de-facto implementation as well now.