= 27d567bc2d48d9f40e9ccc20ea370b15)
eurg 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.
I haven't heard of any studies in that direction, although a few people try to do find something, like "how long are the programs comparatively" etc., similar to this quickly googled IEEE paper.
I assume that because
such a study is unfeasible, i.e. too much effort, too expensive. And probably not that much related to programming language features (as most popular languages converge to some degree, especially on the most important axises). Also, "fewer symbols/lexemes/special-purpose-constructs" is an advantage only under certain conditions, meaning: the question asked may very well already determine the answer.
That's the short version. The full paper is here. I found it while looking for a similar comparison that I remembered seeing mentioned several times when I had been interested in Common Lisp and it turned out to be a follow-up to that. Oh, and those things actually looked at time spent programming, so they didn't measure only silly things like program length.
Why is program length a silly thing?
It was excessive to call it "silly" but program length still seems very imperfect way to measure the ease of writing programs in a given language. Better to directly measure things like programming time or number of bugs.
It's silly when you're measuring it in "lines of code", because "line" is a somewhat arbitrary construct, for which "chunks of text delimited by newlines" is a worse approximation than most people think. (Quick proof: in many languages, stripping out all the newlines yields an equivalent program, so that all programs are effectively one-liners.)
Then it's a good thing I didn't measure it that way, or use that term in this entire thread! Whenever I did refer to measures of program length, it was with constructions such as:
Thanks for digging that up! Also, I did not want to imply that only silly things are measured, but rather that the most interesting questions are still unanswered due to various constraints.