I've come across a project, a software that aims to teach object oriented programming through 3D objects in a virtual world.
For example, you drag a skater onto the snowy mountains, right click to her and invoke her methods like move, turn, roll or whatever. Then you go to the little code window, and drag her methods into a list to execute them in order. You have some containers like 'loop', 'if', or 'do together' for parallel execution. You drag and move methods around, move them inside containers and put together a program that controls the movement of the skater.
It brings no new teaching approach to programming model. It only removes the hassle of type-written languages and compiler-oriented problems. I wouldn't let any student to spend time on such a tool, but the ones in primary school. Programming world is big enough not to waste time on such toys; and teaching programming is not hard anyway, if you have people who really understands it and knows how to express the knowledge correctly.
Object Oriented Lobotomy
Another terrible failure is teaching an object oriented language like java or c# to a newbie for his first programming experience. Later in their careers, they'll eventually need to learn low-level stuff anyway, and they'll be scared to death. They can't live in that abstract world of managed runtimes forever. On the other hand, these languages are designed to be coded, reused and maintained easily, through the years of experience. They're not designed to be learned easily. Yes, there's a difference between "easy to code" and "easy to learn how to code".
First of all, it's harder to appreciate something, if you don't know the lack of it. The inventors of the assembly language were possibly bored enough of combining numeric instructions together, so they have used mnemonics to represent instructions. That's why we call the Assembly language a 'second generation language'. And in time, because writing assembly code is mostly dull work, and maybe because it's also hard to read and follow, they have decided to write a program which writes assembly through easier expressions, hence came the compilers and 'third generation languages'.
This is exactly why some fresh programmers hate writing getters/setters. They don't know how messy things can get if you don't do this. They don't know why it would take times and times longer to maintain a code that uses some variables which are accessed and manipulated by large numbers of lines.
Teach them assembly first!
Start simple, and teach them how to program assembly. They don't need to go in details. Indeed, basic concept of assembly programming is a lot simpler compared to higher level languages. Just a set of basic instructions will be enough to teach what it is like to program a computer to do what you want. MOV, ADD, INT, CMP, JNZ... None of them asks for more than one line of explanation. Registers are the only variables they have, and they'll naturally learn pointers which are considered as one of the hardest concepts to grasp for beginners.
As they write loops in assembly, the pattern will be obvious, and they'll appreciate why that 'for' statement has three sub statements as initialization, termination and incrementation. Then they'll know what is happening during the compilation of that for statement, and they're free to analyse the machine code.
When they're fluent with a procedural language like C, they'll again notice patterns and drawbacks of it. Some of them will appreciate object oriented, and some of them will develop their own solutions and stick to procedural model until they are pushed to switch to object oriented by a teacher in school or team leader at work.