]]>
I just realized that the copy I sent Pete of my article on Complexity was missing a section. Stupid me. As an exclusive, (and if you care 
) here is the missing section which comes after the Oops, I Forgot section.
No prob, I'll add it to the issue. Where should this go in your article?) here is the missing section which comes after the Oops, I Forgot section.Statistics: Posted by Pete — Wed Feb 01, 2006 10:31 pm
]]>
Statistics: Posted by MystikShadows — Wed Feb 01, 2006 5:16 pm
]]>
If I have one minor criticism it would be MystikShadows' MIDI article. It misses out a couple of key concepts (byte order and variable-length numbers) and spends too much time on stuff like _MOUSEX which is not that relevant to most people. Without knowing about _MOUSEX you can still get a lot done, but without knowing about the number format you can't do a thing. I'm sure it'll be resolved in the next part, but it seemed things were in the wrong order to me.
Statistics: Posted by PlayerOne — Wed Feb 01, 2006 4:56 pm
]]>
Reinventing the Wheel
When it comes to the subject of complexity, less code is better in a program. Any programming language comes with a set of internal functions and subroutines designed to help the programmer accomplish the task of creating a solution to a problem. There is no sense is rewriting an internal function, and adding additional code to a program, if the internal function works correctly.
For a stable programming language, using an internal function or subroutine will result in a smaller, faster and more stable program. The internal function will have been tested and debugged by the language creators, and since they know the internals of their language better than we do, it is a safe bet that their method is better than anything we could come up with in code. This is especially true of a language that has an optimizing compiler or interpreter.
Of course, there are instances where the internal function doesn?t work in the way we need it to work. Rather than rewriting the function, we should first ask ourselves if there is a way to accomplish the same task using a different internal function? Even if we have to use a couple of internal functions to accomplish the task, we are still better off than creating a large, hand-written function that adds to the complexity of the program. Only when we have no other option, should we bite the bullet and reinvent the wheel.
There are also cases where more than one language construct will accomplish the same task. The Windows API has several of these, where we can use either SendMessage or a built-in macro to set a value for a control. Keeping in mind that the goal is reduce the number of lines of code, the simpler method should be chosen. If both methods are equally simple, then clarity becomes the overriding factor in our choice.
A corollary to reinventing the wheel is using a language construct, not because we have to, but because we can. I call this the gee-whiz factor. We finally learned how to use pointers, and suddenly we find ourselves using pointers for everything. Gee-whiz, I can use pointers! For example, using our newfound mastery of pointers we create a pointer-based static array of types, even though a simple array would work equally well. Using a pointer-based array doesn?t add anything to the program except for increasing the gee-whiz factor and making the program harder to read and harder to debug. Simple is always better, and choosing the simple path will, in the long run, create a smaller and better program.
Statistics: Posted by rdc — Wed Feb 01, 2006 11:50 am
]]>
]]>
.....
Moneo, all I can say about your True/False testing tutorial was I wish it was written back when I started programming. It has got to be the best explaination I've seen, in a very long time (20+ some years). Very well explained. Makes the subject you're trying to teach quite crystal clear. Great work. .
Coming from you, Mystik, that's a real complement.Moneo, all I can say about your True/False testing tutorial was I wish it was written back when I started programming
. It has got to be the best explaination I've seen, in a very long time (20+ some years). Very well explained. Makes the subject you're trying to teach quite crystal clear. Great work. .Thanks.
*****
Statistics: Posted by moneo — Tue Jan 31, 2006 9:16 pm
]]>
Moneo, all I can say about your True/False testing tutorial was I wish it was written back when I started programming
. It has got to be the best explaination I've seen, in a very long time (20+ some years). Very well explained. Makes the subject you're trying to teach quite crystal clear. Great work. .Statistics: Posted by MystikShadows — Tue Jan 31, 2006 2:50 pm
]]>
I'd like to thank you for enhancing my plain text tutorial for QBE. It really looks nice now.
Thanks,
Moneo
*****
Statistics: Posted by moneo — Mon Jan 30, 2006 8:13 pm
]]>
Statistics: Posted by RayBritton — Mon Jan 30, 2006 4:37 am
]]>
The <a href="http://www.petesqbsite.com/sections/exp ... l">January issue</a> of QB Express is now available!<br><br>Even though the last issue came out a scant two weeks ago, this eighteenth QB Express is absolutely burgeoning with content. This month, Adigun A. Polack reviews YAGL (Yet Another Game Library) by marzec, QBasic.com's new webmaster Mark Wilhelm writes an article about his site, Xerol previews his game "Untank", Matt2Jones contributes something called "FREEBASIC [As in Free Speech AND Free Beer]." This month's gallery features Nekrophidius' "Black Satin" fighting game, Rattrapmax6 is back with another "QB Horse Humor" comic -- plus as always, we have all the QB/FB news briefs you can handle.<br><br>The Tutorials this month are really in a league of their own. Syn9 gives us "Tree Tutorial: Parts 3 and 4", Wallace teaches us how to use his <i>Wallace Visual Editor</i>, there's "True/False Testing" by Moneo, a tutorial on Picking with OpenGL by MGD, Rick Clark brings us "A Closer Look at Managing Complexity: Program Size and Organization", MystikShadows contributes "MIDI Programming Part 1: MIDI File Basics", and "Pointers in FreeBasic" by Eclipzer wraps up the tutorials this month. A mighty fine bunch indeed!<br><br>Read all this and more in <a href="http://www.petesqbsite.com/sections/exp ... x.html">QB Express #18</a>!</p>
Statistics: Posted by Pete — Sun Jan 29, 2006 10:38 pm
]]>