This article has a good discussion on tool mavens vs language mavens. OP is obviously a tool maven. I'm a language maven. I also think that being able to have the typing happen without having to think about it makes coding a lot more natural and enjoyable. But then I use emacs...

It is true that South Africa has a high homocide rate (near 40 per 100000, with the world average at about 7 per 100000), but it is not quite the highest in the world, which is El Salvador according to that Wikipedia page. Even Nationmaster thinks they're only second.

You have the same problem with written exams: how do you compare a student who knows the work intimately but froze in the exams with one who didn't study? Probably the only good things that you can say about written tests is that they are harder less effort to grade and harder to cheat at outright. They are notoriously easy to game by working old papers and such and present a totally unrealistic situation for most disciplines, with the added stress of ticking timer. Give me a good project and oral examination any day for quality assessment.

This is really the old domain specific language argument. Why go for a DSL when you have a good general purpose language and you can add functionality with libraries. In the end, it's all about notation. You can add a matrix library to Java and write A = B.times(C).plus(D).invert().transpose(), or you can have a language that allows you to write A = inv(B*C+D)'. In R, the data frames are a really rich way of handling data, and the things you can do form a great working environment. For what it's worth, there are R wrappers for many languages (like Perl and Python), but once you have gotten used to the full R environment, using the engine from other languages grates.

Copyright is not an immutable part of nature that we just have to deal with. Laws can be changed and they only get changed by people speaking out against them and buy garnering support for them. When Stallman voices his opinion that people should be allowed to share programs, he is not suggesting that everyone unlock their doors. His focus is pretty much on software, which has only enjoyed legal protection quite recently. Algorithms are still not patentable in many parts of the world and copyright, while pretty universal in spirit, is quire differently applied in different countries. If everyone just accepted the law as it was and refused to try to change it, we would still have many laws that are crazy to imagine today. Also, note that Stallman has never advocated breaking the law -- he works within it to implement open software equivalents to closed software.

Python's way around that is to make it trivially easy to implement stuff in C or Fortran.

For completeness it is worth noting that the DVI/HDMI video uses TMDS to mitigate data loss, although there isn't all-out error correction on the video line. In practice this means that your cables have to be spectacularly bad or long to really lose bits.

On a deeper level, how much of Clapton's style was ripped off of the blues greats that he idolizes? How much of their style came from the people they emulated. The myth of the unique is so strong that people really start believing in "creative genius". At some point we will realise that all music is a reshuffle of frequencies subject to some biological constraints in our hearing and perceptual system. Might as well try to copyright 1+1=2

I've listened to some excellent music composed by Emmie, a computer program that does much of what you describe (analyses parameters,etc). David Cope is far more prolific this way than composing "by hand". At some point we are going to realise that "creativity" is not about creating anything at all, but rather about generating and recognising interesting permutations. I have every confidence that machines will be producing new and listenable music in the near future.

Another layer of abstraction is easy to dismiss as encouraging sloppy thinking and "magic", but C encourages this in the same way with anything allocated on the stack. Dynamically typed languages get some heat for not forcing users to decide on the type of their variables. By writing the same program in many different languages, you get a much better feel for what is part of the problem itself and what is part of the stuff you need to do for the computer. From hand-crafted machine binaries (preferably avoiding any operating system "magic") to a quick shell script, it's all a question of where your problem space is. I'm all for learning multiple languages, but abstraction is really a good thing, so I would add "implement the exact same thing in Python/Ruby/Lisp" to that as well.

As an educator myself, I have grappled with this problem. Shared vernacular is hard to find. Just look at your own example: you used "for each" assuming that someone would understand what that meant. I have spent many hours trying to explain the concept of a for loop to very smart Chemical Engineering students, some never get it. I suppose we could conclude I was a bad teacher unless we consider that no course that I have heard of has 100% pass rate. There is a lot of active cognitive research into the best way to teach things, but I firmly believe that application of math is not enough -- it poses the danger of letting people think that the math is constrained by the application. I hear what you're saying about adapting to the incoming skillset, and you'd be surprised: most educators try pretty hard to do that. But perhaps the lack of consensus as to the end goal is part of what makes it hard to find a single good method of teaching that works for everyone in your class. If your goal is to find students that are gifted in math, you may decide to pose hard, puzzling questions. If your goal is for everyone to have some rudimentary knowledge, you may teach more simple rote work. So perhaps your experience of people trying to make it hard was a manefestation of a math department with a strong postgraduate group that benefits from a tough selection. It's hard to believe people teaching a subject have made no effort to try and achieve their goals.

Strangely, I am very happy with the shuffle. I use it for running and find the on-wire controls far easier to use than on device ones. Turns out that I am not alone, as the shuffle seems to be selling well. The only real measure of product failure is bad sales.

This is one of the front-page features of xmonad, which appears to be able to play with a desktop as well