>>52
I happen to agree with this guy, although I do not share the same retarded manners of expressing my point of view.
My opinion regarding the subject is that a programming language is merely the best form, so far conceived in technology, of interfacing the human being with the machine. So many programming "languages" exist merely because no one could really invent a better way to control computers. Also, so many almost-equal languages exist, in almost every aspect, because people have more attitude than philosophy: they think less and do more. No one's interested in inventing really new ways of doing the (old) thing; instead, it's easier to just go straight ahead and write a lexer/parser/interpreter, open a
www.mystupidlanguage.org website, and then write a "library" for the new language that does exactly what -every- library written before already does. The difference is almost totally merely aesthetical, albeit pictored as being "different way of thinking", "different paradigm", "different type system", as if any of these things were anything that -really- mattered.
Most modern languages either lack a real design, or simply copy another language's design, masking the latter fact with a lot of faint "conceptual" arguments regarding "paradigms", "coding style", "identity versus value" and other fandom speech. People don't care about any of these aspects: people just want to do useful things with the computer, and do these things as simply as possible. People don't give a fuck if pointers or templates or garbage collectors exist, or whether "the type system is decidable", or whether the macro system is amazing, or how expressive the damn syntax is. People -really- don't care. People want to just run the whatever damn thing is, surf the web, watch some porn, buy some shit online, then shut off the machine and go to sleep. Honestly, I tend to see the programmers who think otherwise as rather improductive, out-of-the-world individuals, and in practice they really turn out to be so when involved with a large project. Naturally, this does not apply when the individual in question is in a research area, or otherwise not meant to properly "produce" anything else than theory, but this is rarely the case in most work environments outside the academy.
A programming language is an interface, in the same degree that keyboards, monitors and speakers are interfaces, and in the same degree that GUIs are interfaces. They're just designed with different goals: within a music player's interface, it should be easy to start and stop a song, and within a programming language, it should be easy to design a "program", or at least a program of some sort. Ultimately, it's an interface which connects two very different objects: a human being, with all his limitations and traits, and a computer.
It follows that, because a programming language is an interface, it should have the same primary goals that every interface should have: simplicity, utility, straightforwardness. It should respect the -human's- necessities, rather than the machine's necessities. Compilers and interpreters should be smart enough to infer the machine's necessities, be them what they are: performance, stability, memory footprint, responsiveness. Language designers and compiler writers in general use the fact that there are some classes of undecidable problems, or problems that are very difficult to solve, as an excuse to not even attempting to solve them, and throwing back the problem to the user, the human-behind-the-interface. Ultimately, modern languages just walk their path around the same overused patterns, praising mathematical precision in detriment of proper human interaction. We tend to forget the simple fact that most human beings are -not- mathematical beings. Most human beings don't have a friggin' idea of what a closure is, or what metaprogramming is about, or even think rather functionally instead of imperatively. It's not that there is anything wrong with -these- concepts, or that they're by themselves wrong, but that the human being dealing with these concepts start at a position afar from proper comprehension, and he must invest a lot of energy to use these tools -- even more energy if he intends to use them -properly-.
And that's precisely what happens: most (good) programmers inevitably pass, in some period of their careers, through an almost dehumanizing process of reading syntactical structures, processing logical constructs and performing complex inferences as the machines do, because they're required to think as the machine would in order to write a good program. A lot of energy is spent in the initial steps; the learning curve is surprisingly steep. It is as if we had to cut out our hand and replace it with a prosthetic one, just because the handle of a power drill is so different from our hand's shape that we can barely adapt them together, let alone use the tool comfortably.
Programming languages -- at least the lot of them that I know about -- are ill-designed power drills whose handle would not fit a human's hand without a proper surgery. Not that solving this problem is easy, but, in my opinion, is a problem that -exists- and would be very profitable for all of us if we could solve it one day.
Just a side note: theoretically, this "programming language as an interface" does not even need to be text-driven at all -- I feel that this "trend" was estabilished by the compiler research in the Unix era. Nonetheless, that's where the "visual" programming environments come. (Apart the fact that most or all of them are crap, and the so-called "visual programming" is a rather hate-inducing term, they're indeed programming interfaces in their own.) I see some of these attempts as rather good things, instead of sticking with the old prejudice against visual programming environments.
TL;DR: There are no really "good" programming languages, because they're designed to fit the machine, not the man.