Cooking up some new Posts!

Cooking with Code and Logic

I want to apologize to the followers of this blog for its inactivity. I have been working on a variety of projects over the past year but have recently refocused my efforts creating a new eBook for first-time programmers. 

This eBook will be much different than anything I have done before and will focus on small vignettes of introductory computer topics that I hope will eventually be published in the Kindle environment.

I have for some time been talking about a textbook centered on 25 or so primary design patterns used by all programs. My thinking is that the 80-20 not only explains how many things work but how if also applies to programming. In short, with just a little fundamental knowledge (a few design patterns) any programmer, even a new programmer, can create a lot of software applications.

In this new approach, I am also using a new metaphor. Rather than focusing on the techno- babble normally associated with software development, I am instead going to use cooking as the guide for learning how to program.

I have often used the analogy that a computer program is much like a recipe. I intend on taking that one step farther by using cooking (and eating) to explain sometimes complicated programming concepts. This certainly meets the spirit of this blog that tries to help anyone who wants to learn how to write computer programs.

So how was cooking like programming? I already explained how I used a recipe to define programming to new programmers. With a recipe, the instructions are sequential, they must be followed in order using ingredients and measurements as specified by the cook. Programmers must do much the same. The computer will only do what is told (by the programmer) and there's nothing built into the computer that will tell you when you're asked it to do something which doesn't make sense.  Create the incorrect logic steps and you will get a program that not do what you want it to do. A cook faces the same problem with a recipe. The recipe must be followed exactly and if you change the order of the recipe then the result will certainly be less than desirable,

Cook's use seasonings and spices along with utensils and pans to create something to eat. The programmer uses variables, constants. calculations, decisions, loops and expressions in much the same way. 

In my cookbook of code, I will focus pseudo code. Pseudo code looking and acting a lot like a recipe. An emphasis on the sequence of the instructions and not an syntax as is the case with computer programming languages. My hope is that by using something that we all are familiar with, cooking, and pseudo code which is more like English sentences, that this will make programming easier for first timers and perhaps add clarity to those were having problems. Stay tuned, first up will be if statements ( or decision structures).

My programming videos...

I have a number of screen capture videos for Java, JavaScript, PYTHON and Visual Basic available in YouTube at http://www.youtube.com/techtalkies.

You also subscribe from YouTube to post comments and see new videos. They are also available on this blogs sidebar.

Modularization - Important Stuff

Modularization has long been described to a "divide and conquer" approach to simplify complicated program logic.  Modularization requires taking a program with many logic steps and simplifying it by looking for sub routines within the entire program that can stand by themselves (i.e. a sales tax calculation, GPA average calculation).  Sub routines can then be grouped with other sub routines to complete the entire program.  This approach has long been used in engineering. 

For example, when they designed the Space Shuttle, they did not design the entire space craft on a single drawing taking in all of the details in a single design. Instead, they broke the project up into pieces and designed each of those pieces with the idea of integrating them all at the end (i.e.  communications module, thrust module, launch module, space craft controls module, etc.).  

The examples used in this blog are not as complicated as one would find in a typical program (so you may question why they would quality as a module) but the most important point to recognize is that these modules are typical of the blocks of code that exist in every program that really constitute a part of the entire application.

Modularization: Modularization defines the process of reviewing program logic to identify program subtasks. When we divide the program up into subtasks we make the design of logic simpler and more accurate. The logic contained within the subtasks is stored as modules. These modules are combined with statements to make up the program.

 

Modules: A module is a block of code that represents a program subtask. This subtask is a standalone piece of code that performs part of the programs solution but also could stand by itself and potentially be used in other programs. For example, I could create a sub-task that calculates the sales tax of a purchase. It is only part of the logic but is required for the final solution. Because it can stand alone, it could be reused in other programs that have a similar requirement (i.e. other programs also would need to calculate sales tax).

Code Reuse

Code reuse is perhaps the biggest benefit of modularization.  Code reuse can take place within a single program (In the case where lines of logic are called in multiple locations in your application) and also across different applications. 

Taking a sales tax calculation; for a retail business, how many times does a computer need to calculate sales tax.  Could be at the cash register, could be used again to calculate that days sales tax liability, could be used again when printing monthly customer credit card invoices.  Why have the same calculation code statements called over and over again.  Instead, we could take a block of statements and execute that code block as a module in more than one program.

This code reuse is a fundamental part of object orientated programming and a critical concept to understand and appreciate before learning to program with objects. There is also a quality benefit to code reuse.  Can you see it?

An Example

Example the following pseudo code.  There are two modules identified here.  One for sales discount and one for sales tax.  In the diagram the pseudo code on the left is change to call modules that contain the code to be executed.  The new pseudo code that calls the module can be seen on the top right of the diagram.  By setting the code up in modules, the sales discount and sales tax code modules could be executed multiple times. 

---

---

Next up will be some examples of modularization in both Java and Visual Basic.Net.

If you have a question or point to make, send me a comment.