Programming. Did that scare you off? Well, it should. LRESULT CALLBACK WndProc(HWND hWnd,UINT message,WPARAM wParam,LPARAM lParam); How about now? Well, pretty much every program in windows needs that line. It will take you forever to figure out what each of those really mean, which you will need to do to for ANY kind of simple windows program. And, when you finally do know how to use each argument, CONGRATS! that was only the first line. you have 9,999 to go to make your tic-tac-toe game. WOOT!
Now you see why the biggest software company in the world have trouble making a new operating system? Yes, you can write "Hello World" in your favorite language. No, you won't be able to write a commercial program anytime soon.
There is a great book on programming, called "the Mythical Man-Month," and in it was an article about the hope of developing a silver bullet that will kill the werewolf that is programming. Programming projects look all innocent and friendly at first, but whenever the moon shines, they turn into creatures that will rip you from limb to limb.
Yet, why does it have to be so complicated? What is programming?
(http://bytes.com) Okay, who knows how to explain how to cook something? What you explained is a plan to solve a problem. You know how to program. Who knows a winning strategy for tic-tac-toe? A strategy is a plan. You know how to program. Who has written a schedule for an assignment? That's a plan. You know how to program. Get the idea? You know how to program, no matter who you are.So why is it so hard to program? Well, let's look back to the example.
... WndProc(...) is a function call. LRESULT is a "long" integer that saves information about how it ran. CALLBACK is to make this function callable by the windows kernel which you'll need to know about whatever happens in the OS.... etc, etc.
and what did you want to do?
Make a 3x3 board, click on the board, making either an "x" or an "o," and display "x wins" when there's a line of 3 x's.
So what is programming? Translation. To "program" your little sister to bake a cake, you have to first know what she can understand, and explain the recipe to her in her language -- "open up this case-y waysee, pour it into the bowl-y wolee, add water and mix-y wicksee". What makes it hard? There are too many details to understand for computers.
In our first example, "LRESULT CALLBACK WndProc(HWND hWnd,UINT message,WPARAM wParam,LPARAM lParam)." You need to know the structure of windows programs. You need to know how to set certain properties. You need to know LRESULT has typically been used for windows procedure return values, but can be #define'd as something else and give you weird error messages when you compile. The problem, the big problem is that how we think about windows isn't how the computer thinks of windows. So when you want to resize a window, you're clueless about what to tell the computer.
Now, some of it is necessary. You need to know that Windows calls each program and sends messages (like mouse-clicks) that you need to respond to. Others aren't. You shouldn't have to know memory management, stacks, scheduling algorithms. They are important, yes. Necessary, no. You should be able to tweak each aspect to work exactly the way you want it to, but you shouldn't HAVE to program the details everytime.
A programming language should allow you to describe the algorithm (how to do it), and a good one should allow you to not worry about anything else. When you're playing chess, you should focus on what pieces to move, and not how you're going to signal your arms and hands to move your pieces.
The solution? Program the algorithm, and not the process. That's it. There's your silver bullet.
Shuffle the cards, then deal out the cards.
-- This is an algorithm.
#include "Cards.h"
int main(void){
Cards myDeck;
shuffle(myDeck);
deal(myDeck);
return 0;
}
-- This is a process. It looks like an algorithm, but this is a totally different animal. It creates an object myDeck, then calls two functions on the object. To the compiler, the names mean nothing. Even though you want to create a set of new "Cards" named "myDeck," shuffle it, then deal it, the computer may understand it as create a nuclear bomb, set it, then detonate it in insert-favorite-city-here. It all depends on what you told the computer "Cards" are, and how to "shuffle," and how to "deal." You see? This is programming a process, it includes EVERY minute detail about how this program will run. Don't be fooled by the compiler, linker, or the included files/libraries. The entire process of register assignment, stack creation, memory allocation is included in this code. They are just hidden for readability.
Let's look at the algorithm again, because I kinda cheated. We didn't specify what "shuffle" and "deal" was. If they are function calls, we've just created another process. What you meant by "shuffle the cards" doesn't mean you do EXACTLY what you did last time you played poker, including scratching your itchy arms (calling some specific function), but "make the cards random", which is what shuffle means. Just as long as you got the cards random, it doesn't matter if you riffled the cards, pulled out a bunch and put it on the top, or played 52 card pickup, just as long as it is done. The algorithm actually means:
Get the cards randomized, then get the cards dealt.
This is goal achievement programming. Specify the sequence of goals to accomplish, and not the functions to call. Tell the computer the algorithm, and let it figure out the rest. Not too hard right?
There's a reason why "Artificial Intelligence" is a programming problem. Intelligence, regardless of its form, at its core, is programming. Anyone intelligent enough to speak could learn how to program IF you can make the computer understand you by only telling it the algorithm. "Open a new window, draw a 3x3 grid, make each box clickable." Your little sister can understand it, so why can't a computer?
1 comment:
Well said.
Post a Comment