[elwin]

The article shows an interesting illustration of the disconnect between programmers and normal computer users. Like the author says at the beginning, any experienced developer knows that automating interaction with a GUI is a crazy idea. It's a painful, fragile way to move data around. But to the author and anyone who's done data entry, it's an improvement to their workday that demonstrates the power of programming.

So much programming instruction seems designed to teach people who already understand programming how to solve problems that nonprogrammers wouldn't even understand. A tutorial that started with automating tasks like this might be more effective than all the ones that start by demonstrating how to do basic arithmetic in $LANGUAGE and go on to a detailed explanation of $LANGUAGE's object system.

[lstamour]

This is why I like http://www.sikuli.org/ and Mechanize-style DSLs so much. They translate programming, web requests and parsing/processing into plain english "click [here]" concepts.

[yason]

I know several places where software components or systems software is tested against real-world applications, games, and whatnot, and... guess how it's often done? Yup, with a combination of injecting artificial keyboard/mouse inputs and looking things at the screen. And these guys aren't beginners but professionals. You can't really automate something that doesn't have the APIs for it.

[blackbagboys]

I'd be interested in seeing an accompanying article by the author or another developer laying out how you would solve the same problem if you were an "experienced" developer; I have done a little of the same type of programming at my job, and a side-by-side comparison of the 'novice' and 'pro' approach would be extremely helpful.

[elwin]

Maybe I was too vague. I meant that a programmer would always use an API rather than scripted interactions with a GUI. An ordinary user might assume that programs use interfaces designed for humans, because the concept of an API doesn't even have a place in his mental model of how computers work.

[beachstartup]

> all the ones that start by demonstrating how to do basic arithmetic in $LANGUAGE and go on to a detailed explanation of $LANGUAGE's object system.

the fact that i knew exactly what you're talking about as soon as i read it is pretty good evidence that you're right.

the best tutorials i've ever seen are ones that start with a moderately complex program and step through it line by line, explaining in plain english why things are being done. this is how both human beings and computers parse programs, so i'm not sure why a tutorial writer would do it any other way!

i think the current trend of embedding documentation within your program as markdown on github is a pretty close approximation of that.

[hjAETGHs]

seems like everyone forgot about vba and vb6 already....

[Shog9]

No, but not for lack of trying.

I can imagine trying to solve a problem like this in either; in theory, this is exactly the sort of thing the automation APIs should be good for...

In practice, you would get close and then hit a wall because something critical isn't exposed by the object model and the language itself offers no way around save for the ability to call down to components written in something else. At which point you're dealing with a lot more headaches.

The author illustrates something I think many of us too often forget: ease of use is often determined not by the intended use of the tooling, but by how easily they can be put to unintended uses - which in turn depends heavily on the ability of user to try stuff and observe what happens as a result.

I see more and more people - not programmers - poking around with JavaScript in their favorite web apps for the same reasons: low barrier to entry, low cost to failure, immediate gratification when they hit upon something that works.