= 27d567bc2d48d9f40e9ccc20ea370b15)
Viliam_Bur comments on Open Thread, September 15-30, 2012 - Less Wrong
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (206)
I'm trying to find the existing research on the topic Paul Graham discusses in this article (regarding the relative merits of programming languages in footnote 3 and surrounding text) and which EY touches on here (regarding Turing tarpits).
Basically, within the realm of Turing-complete languages, there is significant difference in how easy it is to write a program that implements specific functionality. That is, if you want to write a program that takes a bunch of integers and returns the sum of their squares, then it's possible to do it by writing in machine code, assembly, brainfsck, BASIC, C, Java, Python, Lisp, but it's much easier (and more concise, intuitive, etc) in some than others.
What's more, Graham speculates there's a ranking of the languages in which programmers too comfortable in one of the languages "don't get" the usefulness of the features in languages above it. So BASIC-addicts might not appreciate what they can do with recursion or structured programming (i.e. by abolishing go-to statements); C-addicts might not appreciate what they can do with functions as first class objects, and Python-addicts might not appreciate what they can do with Lisp macros.
I'm interested in research that formalizes (or deconstructs) this intuition and attempts to come up with a procedure for comparing programming languages in this respect. The concept is similar to "expressive power", but that's not exactly the same thing, because they can all express the same programs, but some can span a broader array of programs using fewer symbols (due to how they combine and accumulate meaning faster).
Also, the theory of Komogorov complexity holds that "when compressing data, choice of language doesn't matter except to the extent that it adds a data-independent constant equal to the length of a program that converts between the two languages"; however, this still allows that some programs (before the converter) are necessarily longer, and I've heard of results that some Turing-complete formalisms require exponential blow-up in program size over e.g. C. (This is the case with Wolfram's tiny Turing-complete language in A New Kind of Science.)
tl;dr: I want to know what research is out there (or how to find it) regarding how to rigorously evaluate programming languages regarding relative ease and brevity of writing programs, and in what senses python is better than e.g. assembler.
If "enlightening people about better programming languages" ever becomes a higher priority than "enlightening people about superior status of X language users", I think a good strategy would be to explain those possible insights in a simplest possible form, without asking people to learn the guru's favorite programming language first.
For example, to show people the benefits of the recursion, I would have to find a nice example where recursion is the best way to solve the given problem; but also the problem should not feel like an artificial problem created merely for the sake of demonstrating usefulness of recursion.
I can use recursion to calculate the factorial of N... but I can use a for-cycle to achieve the same effect (without risking stack overflow). Actually, if my math happens to be limited to 64-bit integers, I could just use a precomputed table of the first few results, because the factorials of greater numbers would overflow anyway. This is why using factorial as an example of usefulness of recursion is not very convincing. A good example would be e.g. recursively parsing and then evaluating a mathematical expression. -- The idea is that even if some concept is powerful, your demonstration of it may be wrong. But providing no demonstration, or very esoteric demonstration, is also wrong.
Alternatively, we could hold annual competitions between proponents of different programming languages. For example they would have to program a Minesweeper game, and would be rated by (a) the speed of finishing the product, and (b) the elegance of their code.
At this point, proponents of the X language may object that coding Minesweeper is not the fair way of comparing languages, because their language is better for some other tasks. But this argument cuts both ways. If my goal is to write a Minesweeper game, then perhaps Paul Graham's (or anyone else's) opinion about the best programming language is not relevant to me, here and now. Perhaps call me again when my ambitions change. Or tell me in advance what kinds of projects should I do in the X language, and what kinds of projects will rather easily work in any language.
This.