[Cialug] GUI Programming

[Matthew Nuzum]

On Mar 7, 2013, at 9:25 PM, Todd Walton wrote:

> But look at those methods with the eye of a novice and tell me one way
> in which they differ from any other method that isn't event driven,
> that are explicitly called by some other bit of code?  There isn't a
> difference.  The syntax is exactly the same.
> 
> *That's* what is confusing.  How am I supposed to know what's going on
> with this if there's nothing to indicate what's going on??  I have
> more learning to do, and I have a feeling that an essential component
> of it will involve simple rote recognition/memorization, versus logic.
> That's fine.  We are dealing with machines here, after all.  But I
> have yet to have an instructor or a book that explained it in a way
> that conveyed what I need to know.  So if the language isn't going to
> indicate it, and the books don't indicate it, it just means the going
> is difficult.

Well, at this point you're using a framework that has special methods that it expects and these methods have magical properties. You learn about these special properties by reading the API documentation or taking a tutorial or class.

I have a tool I use for testing. When you write tests, if you create a special method called setUp() then it will run before every test. If you make one called tearDown() then it runs after the test finishes. What is the difference between those methods and anything else? Nothing, they're just special methods that the docs explain. If I accidentally created a method called TearDown instead of tearDown then it would not run and I would scratch my head until I noticed the incorrect capitalization.

There is a concept in the programming world called "cargo culting," which means to take some code and reuse it without really understanding how it works. Look up the phrase "cargo cult" for the history behind the phrase, it's very interesting.

In my opinion, most programmers start out by cargo culting. They copy some code, tweak it to meet their needs but don't really understand it. They get the job done. Eventually as they continue the code becomes a mess and they either start to understand what they're doing or get a nice job as a business analyst.

My point here is that it's OK to not really understand it all. You can treat it like a black box where if you feed x in one side you get magic out the other.