Event-driven or polling for beginning programming environments? In beginner programming environments, I have noticed an essential difference in style for handling user interaction. Scratch and Alice are event-driven, while Processing and Greenfoot, for lack of a better term, are poll-driven. In the event-driven case, when the user clicks the mouse on something or types a key, a method is called to handle the event. In the poll-driven case, in order to respond to user actions, the programmer puts if statements into an update method that is called every frame to poll the input.

I like to use these beginning programming environments in beginning classes, especially for game programming. I'm not sure which approach is better, though. Event-driven programming is easier for programming GUIs, but poll-driven programming is better for simulations. Neither one seems best for all types of games.

Which approach will work the best for programming games for beginners? If I wanted to design my own environment, which style should I use? Are there any other styles?
On the face of it, event-driven programming seems far easier to explain. "This code will run when the button is clicked" seems obvious, and similarly, visual environments that favour this technique seem relatively intuitive:



It would seem obvious to explain that the code below that block runs when the sprite is clicked.

Similarly, in Node.js, an event-driven programming language:

app.get('/', function (req, res) {
  res.send('Hello World!')
})


With some basic knowledge of the framework used (Express), you can tell that when the / route is accessed, Hello World! will be sent.

So, without looking too deeply, event-driven programming is the obvious choice. But, this isn't the end of the story. If you're not used to event-driven programming, the fact that your code might not run in the order you expect is very confusing.

fs.readFile('foo', 'utf8', function (err,data) {
    console.log(data);
});
console.log('Hello!')


Two things will print here: the contents of foo and the word 'Hello!'—but which prints first? The answer is: you can't tell, despite the intuition that many students have that would suggest the order is file then 'Hello!'.

Event-driven programming starts to encounter a lot of these 'gotchas' because it's difficult to predict in which order things will happen. Ideally, each event wouldn't need to consider any other event happening, but in practice it is necessary.

Let's say you wanted to end the game if your spaceship was touching two others at once. With events, you could need to subscribe to 'Touching [spaceship1]?' and 'Touching [spaceship2]?' and synchronise them (not terribly straightforward). But polling like so would be far easier—for each update loop, just test if(touching(spaceship1) &amp;&amp; touching(spaceship2)).

Getting to your original question, I would personally introduce event-driven programming first, since it's so straightforward for trivial use-cases. As the problems start to appear with events, then introducing polling in an update loop would be wise. Most of the major introductory programming environments seem to follow that (Scratch -> Greenfoot, etc). The same principle should apply to your own environment, I think—consider your audience and what they'll be using your own environment for, and you'll have an answer that suits you.

You might also find Polling vs event driven input on Game Development Stack Exchange interesting for reference on the problems faced by professional game designers regarding events vs polling. 

The only alternative, perhaps, would be to batch events from inputs so that they can be handled in the next update loop—that's something to consider if you're looking for another way of handling the issue, but it is more complex than the others.