I was corresponding with a friend about R being great but having some problems (see here). My friend wrote,
I have this hypothesis, though, that ugly/improper/hodgepodge languages will always bury pretty/proper/curated languages. Ugly languages get things done and attract those who are looking to get things done. These adoptees modify the language to do new things and so the ugly languages quickly evolve to handle cutting-edge problems with little, albeit inefficient, code. We’ve seen this happen with PHP, which is very inelegant, but is the most useful and widely-used language for web development. Unless you are a professional programmer (working on a team, maintaining code, concerned with execution speed) uglier languages are better for almost every project.
I think it has something to do with the way human languages evolve. When a langauge accepts bottom-up adaptations (from the users) it will handle new topics and new problems more efficiently than when it need to wait for top-down approval of such adaptations. For programming languages, this means that the bottom-up adapted language will be less thought out, but in a greater state of readiness for new problems.
I agree that, for my purposes, R is usually better than the alternative. I use R almost exclusively. But I don’t necessarily agree with the categorization “ugly/improper/hodgepodge.” In particular, some of the difficulties with R arise because of efforts to make it “pretty”–I’m thinking particularly of the S4 structure but also of the pain-in-the-butt exception handling and other “paperwork” that take up 90% of the space in functions such as glm().
P.S. I removed the discussions of English and other human languages since they were a distraction from the main point which was about R.
I strongly disagree with the attempted generalization of Gresham's Law to programming languages (and, this IS my professional field): I've seen Python (truly beautiful) and Ruby (not too bad) grow intensely at the expense of Perl over the last few years, a data point that is just too drastically in conflict with the proposed law.
In R (like in statistics and economics) I only dabble (a hobby, not a profession), and from my POV it is quite a hodge-podge — clearly a language "designed" (if that word is even warranted;-) by people who don't design programming languages for a living (don't fret: attempts at statistical models by non-statisticians are MUCH worse, to the point that even I, a dabbling amateur, can often recognize that!-). Fortunately I can use RPy to access R's powerful statistical functionality from elegant, beautiful Python!-)
In fact, you could argue that the causality works the other way. That is, English is an open and flexible language because lots of adults have found it economically beneficial to learn English as a second language.
Guys, be very careful about your generalizations about English vs other languages. There are professional linguists listening in, and they tend to bite people's heads off when they hear comments about English (or any other language) like the one in the original post. Don't say I didn't warn you ;-).
What other programming languages have you used? Dealing with errors is a pain in any programming language.
For it's time, R was very unusual in combining aspects of the functional and objected oriented paradigms of computer programming. Some inelegance must be expected when pioneering new ideas.
So, Latin and (ancient?) Greek are ugly, hodge-podge languages, or the Romans & Greeks didn't get things done?
I'm one of those linguists listening in. Everyone always thinks their language, their field, the time they live in, is different. It's lack of perspective more than anything else. They've been tackling ridiculous statements about language in the press at the Language Log, much the same way this blog's picking up on published nonsense about statistics. Here's a fun Language Log post on why English is(n't) funnier than German.
Ugly programming languages are simply a disadvantage. I've heard people argue Perl is nice because it can be so concise, whereas other people (like me) describe it as "write only". So sometimes ugliness is in the eye of the beholder.
The main reason Perl, R, and other scripting "languages" have taken off is that they have a very shallow learning curve. It makes them easy to use out of the box to get things done. It doesn't necessarily make them the best way to do those things in terms of robustness, efficiency, scalability, etc.
A language isn't extended (even with Perl). Instead, it's about how easy it is to build and use libraries for it. It's actually easy to build libs in every modern programming language. How easy those libraries are to use will depend on the language and, importantly, the user.
Consider the qualification of Andrew's anonymous friend: "Unless you are a professional programmer, …". There are two aspects to this qualification.
First, there's whether you are a professional programmer. If so, you already know C or Java, know how to use version control, know how to organize builds, distributions and unit tests. If you know these things, the relative difficulty of writing a program in C vs. Python is different than if you're a civilian.
Second, there's whether you're working on a professional project. Despite being a professional programmer, I often have to do one-off programming tasks. The decision here is different. Sometimes I can just script it in the shell (or equivalently, interactively in R) and don't even need to write a "program". In these circumstances, even professionals don't write the "paperwork" Andrew's talking about. With more sophisticated languages, like Java, C++ or Python, much of the design is aimed at supporting the paperwork (e.g. namespace control, exception handling, variable encapsulation) required for professional projects.
I'll second Alex on this. I'm a sometime professional software developer (in python) and sometime quantitative social scientist (who has dabbled with R).
Every time I use R, I long for it to make sense like python does. At least it's better than the stata syntax, which often seems rather 'magic'.
I'm glad to see a vote of confidence for RPy, though. I was always afraid it would be too incomplete/non-standard to be truly useful. If it really does give R a pythonic syntax, then I can't believe we aren't all using it.
I am not a programmer, I'm a data analyst.
I find R very hard to use for anything tricky. The help messages are horrendous, the package documentation seems almost deliberately obtuse, and the help list (which I am no longer on), while it has some helpful people, also has people who are deliberately rude to newbies.
In the old days, you could see the code for any function by typing that funtion's name. Now? Well, the code is there, somewhere….. but it isn't immediately available.
Maybe it's different for programmers. I don't know.
Going back before perl, I saw a talk with Brian Kernighan (of K&R) where he said when he designed awk, they thought people would use it for maybe a dozen or so lines at a time, but people wrote far longer awk scripts than they ever intended. Someone once even wrote a 20,000 line Pascal compiler in awk.
To this day, I use awk and sed a few times a year — they're powerful at their tasks.
I looked up the article on Kernighan's visit and I remembered 20,000 lines correctly, but it was a C compiler.
http://web.archive.org/web/19991005054825/hcs.har…
I am a programmer, and after coding in R for a while, I think that R is actually elegant. I certainly don't think R is ugly. (I'm talking about R the language, not necessarily all the things written in it.) For the most part, it seems well designed for its purpose. It is a full-featured, general-purpose programming language whose cost model has been tailored for statistical computing.
R's functional-call semantics, for example, are unusually powerful and exactly what you need if you're writing statistical code, which has loads of parameters, complex defaults, and many options for approaching problems.
R's scoping and binding rules are simple yet powerful, too. The <- and <<- binding forms let programmers bind values to variables in local and outer scopes, avoiding some of the ugly corner-cases that some languages have. In Python, for example, all bindings are equivalent to R's <- form, which in effect makes closed-over variables read only. In Ruby, bindings are equivalent to R's <<-, allowing outer code blocks to accidentally "steal" bindings intended to be local to inner blocks.
R's first-class support for functional programming is also handy for statistical computing, where you often need to alter the behavior of library code in complex ways (e.g., panel functions in lattice graphics calls, by/tapply/aggregate helpers).
If you think "paperwork" coding is a pain in the rear when coding in R, try rewriting your statistical-analysis code in other, "more-elegant" languages. I suspect that R will start to look a lot more elegant then. :-)
Cheers. —Tom
It is hard to separate a language from its library because nobody nowadays would use a language if the available libraries are poor. R does have some nice features but R's libraries are a major hodge-podge. Just look at all those libraries and with their inconsistently named and inconsistently behaving parameters. And the try-catch-exception in R is implemented as a function instead of being a native construct which makes it simply U-G-L-Y.
Python 3 now has syntax for accessing outter scope variables similar to