|
Managing a spreadsheet does not equal programming by a long shot, and given large enough complexity, you'll run head first into VBA macros and abominable one-liners with so much different branch points that it only makes sense to its author, who could have written a program that seperated the code from the presentation instead of munging up the two. Sure, it'd get the job done, but the successor would have to rewrite it, as it can hardly be documented, plus, from personal experience, people who are versed in Excel trying to tackle data problems at companies have come up with rather brow-raising solutions. (What's this MySQL you speak of? Does it work with Excel, too?) Programming is not just hammering away in [language], it's deconstructing a problem into smaller, less complicated problems, to generify and abstract away common properties to allow for repetition in similar contexts. It stimulates efficiency, speeds up rote administration tasks, and allows the programmer to learn something new each time he tackles a new problem. More so, the writing of code should enlighten a person to write readable functionality, as code is read, compiled code is executed. Using clear and descriptive terms to state the moving parts in his solution, using verbs in function names, not abbreviating unless absolutely necessary, are all tasks that should allow for a person to better state his problem domain and its intended solution. |
This is exactly what you learn in Excel. How to take some data, transform it slowly (column by column), check your work, save intermediate results, etc.
In minutes you can go from your idea to some crude version of it. Then you refine it.
Look, Excel is like LogoWriter. We're not asking people to design rockets with it. But it's a hell of a lot better than sitting them in front of a terminal and asking them to learn about variables, loops, print statements, etc. Excel is type and go.