Google was designed for the larger-than-Altavista web, but the web is now too big for Google. I saw the oversized-internet problem first when teaching English overseas. Whereas in 2007 I could find a prewritten lesson on most topics within about 10-20 minutes on Google, in 2012, the game was generally a bust as I could spend an hour filtering through dozens of irrelevant lessons (due to people using far too many tags) and hundreds of variations on the same theme. The lesson sites by then were flooded with innumerable basic and amateurish lessons that a teacher could throw together in twenty minutes anyway, and the whole efficiency drive in sharing was rendered moot.
This has happened with all sorts of information. The internet is now filled with tutorials that are basically just rewrites of other people's tutorials, and YouTube is full of videos of people who read a tutorial on the internet and decided to make a video of themselves doing it. I recently tried to search for information on a particular part of bicycle maintenance (changing headset bearings), and there are several different types of headset. Because I didn't know the exact name for my type of headset, I couldn't search for it specifically, and instead I had to just run a general search, which quickly grew tiresome, as I ended up seeing 13 different videos for changing one particular type of headset, and a couple of videos that had nothing to do with headsets whatsoever. I gave up and went to the bike shop instead. As it turned out, the problem was the bearing race, not the bearings, so I couldn't have fixed it anyway, but in a well-indexed internet (early to mid 2000s), I would have most likely found the information I needed to check within about 15 minutes, and I would have known to go to the shop sooner.
Casual phone games have come up with an interesting variation on procedural generation -- I suppose you could call it "shuffling". One of my favourite examples is called "Platform Panic", and it looks like a very retro flick-screen platformer on first play. On second play, however, you notice that the screens are in a different order. As you play and get further, you get more screen types, and more variations on them, and they generally get more difficult as you progress. I've seen this same approach taken with games using one-touch flying interfaces (flying snakes, rocket ships etc) where you run a continuous track made of predefined blocks that have been shuffled, and rolling-ball balance games moving from one predefined problem block to another (again shuffled).
What makes this approach interesting is that your game now gets more challenging without necessarily taking any longer to play, but as most people will still want to see their high score increase over time, you have to balance the increasing difficulty carefully to ensure that games do still get longer.
The interesting point to draw from this is surely how the internet has really, really, dumbed us down. I'm constantly infuriated by the amount of repetitive superficial crap that pops up in computer tutorials, and lament the fact that even expensive programming textbooks are seemingly less sophisticated than the magazines of the 80s.
While I agree that it's wrong that our current environment makes this sort of stuff into front-page news, surely we should at least be thankful that there are materials on interesting problems, and we should look at how we can expand on that to try to improve the quality of programming education...?
I see this as an interesting programming problem for learners. In the past, room placement would have been the sticking point for most beginners, so while physics engines are overkill, they get the job done. Let's call that the "blunt instrument" solution, and once it's in place, we can start using modular programming techniques to come up with alternative strategies, which can then lead to discussions over execution time and efficiency, and even the trade-off between programming time efficiency vs execution efficiency.
That's a different issue. There's a discussion about whether there is such a thing as "interpreted languages" and "compiled languages", and in the strictest sense, the answer is no, because some normally-compiled languages can be run in an interpreter, and most normally-interpreted languages can be compiled; but there is also a philosophical debate that allows an imprecise use of the terms. Java is what I'd consider a "compiled language" because of its architectural design -- I don't care that the target architecture is rarely seen in hardware form. The limitation this leaves you with is execution speed, which was a genuine concern in the early days of Java, but that's not a feature of the language per se.
Python is a scripting language. It's almost fully dynamic, in that you can (if you want) rewrite class definitions during execution time based on user input. This is, on my philosophical level, an architectural feature of an interpreted language, and any compiled version of Python is going to have to include a compiler and/or interpreter to deal with these quibbles at run-time.
My point, in short, is that these architectural features aimed at the interpreted environment are a source of potential errors, and that they don't compile well; therefore Python is not a good candidate for use in compiled code. Python is was specifically designed for running in an interpreter. Why would you want to use it anywhere else?
Python is a useful language for prototyping things, or trying out some new algorithm.
It allows me to test these things out without worrying about all kinds of details like I would if I were programming in C.
Of course if I want performance for whatever it is I'm doing, then yes, I'll rewrite in C eventually.
And yet you don't need to be able to dynamically rewrite entire class definitions in order to do most of the useful stuff that Python lets you do quickly. And if you do use a lot of the stuff that makes Python Python, it will be a tough job to rewrite into C at a later date. As such, I personally feel that Python is a double-edged sword, and I would like the core of it without the ultra-dynamic, self-modifying stuff that (for my purposes) only serves as a source of potential errors.
HOST SYSTEM RESPONDING, PROBABLY UP...