It has given me a game idea. One where you have to solve code puzzles using only copy and paste. You'd start out each puzzle with a single text of code and have to modify it to do something else, but your only method of transformation would be copy and paste (and maybe cut).

I suppose a more accessible game would be one where you just had to modify text, not code, but perhaps that's where difficulty levels would come in.

Seems like a reasonable idea for a mobile game...

Doing a tedious and painful operation countless times does not make you more reliable at it. We're humans. Meat sacks. We are forever bad at these kinds of tasks.

People don't screw it up because they don't know better. Experienced programmers with 10 years of experience will screw up copy-paste operations if they're doing them repeatedly. Particularly if they're lazy and don't review their patches.

I read up about the Limbo of the Lost. Wow, that was quite the rollercoaster of insanity.

Also, intelligent design, both preliminary, and as the design evolves, is going to control how much additional complexity is from accidental complexity.

I've been reading some interesting stuff lately. There are two kinds of complexity. Accidental and essential. Essential is what's actually going on. The actual problem is X complex. The accidental complexity is what we, in our lack of omniscience to see the problem for what it is and where we're going, is the complexity we add on top of it. Anti-patterns. Doing things that aren't in our best interest because we fail to understand the problem, or the implications of our design choices.

Proper design is about reducing accidental complexity, not essential. The C++ community (and others) has brainwashed itself into thinking essential complexity can be removed with hierachies and abstraction but it's actually the opposite. Encapsulation and abstraction actually increase overall complexity, but allows us to organize the complexity into manageable chunks to keep similar issues lumped together. A programmer can only keep so many ideas in his head at a time, and the more you have, the more likely he or she will fail to notice one or more of the requirements and write a bug, or reduce the rate at which code can be written. We've all been there: Looking at a piece of code and taking the smallest baby-step changes because we're afraid of breaking something we don't quite understand because it's so massive and difficult to reason about.

Also, shrinking functions as small as they can go can actually increase complexity. You're reducing the amount of function calls per function, but at the same time increasing the vertical depth of your program. So you could be going from a "complex" 1-page function, to a couple of one-liners, but now you've got to track 8 different functions across different source files and it becomes very hard to visualize the call graph.

Mike Acton, of Insomniac Games (Rachet and Clank) really struck a chord with me when he did his talk at C++Con about "the software isn't the platform. The hardware is the platform." It was such a different mindset, everyone was either appalled or confused. He said, as an engineer, you have to be able understand how the code you write will be run on the CPU and cache-level. They kept saying "That's complex. We prefer to abstract away the underlying hardware." and he said, [all paraphrased] "That doesn't matter. If the problem is complex, then you deal with the complexity. What you're suggesting is not solving the problem. The problem of the hardware is still there and you're just ignoring it and hoping it doesn't screw you." He basically suggested that if you're not dealing with the entire problem (relying on encapsulation like quick-and-easy STL containers) then you're not an engineer--you're more akin to a mechanic/industrial tech who knows how to use tools but not why they work and how to break out equations and solve them when something "odd" happens outside their experience.

http://www.johnnybigert.se/blog/2012/02/sustainable-software-development-managing-complexity/

This needs to be my new sig.

I just had a copy and paste error in my TINS entry

    event.mouse.x = (event.mouse.x - pillar) * screenWidth / (displayWidth-2*pillar);
    event.mouse.y = (event.mouse.y - pillar) * screenHeight / (displayHeight-2*letter);

Yep