CPT 307 Week 5 : Newbie to Newbie Blog Part One

For this assignment, we were once again tasked with making a blog post targeted towards a 'newbie' that is looking to pick up programming, specifically, with Java. Java has certainly proven to be less intuitive than Python, but is not entirely unapproachable. This week, we had to explain to our 'newbie' what the advantages are between the different types of data structures and how to choose the best algorithmic design for what they, as the programmer, are trying to accomplish. 

To the uninitiated, programming and coding carries a stigma due to the fact that people refer to it as a language. Ostensibly, people make connotations with learning how to program and code as being as difficult as learning another human language. To be certain, there are new concepts and nuances to measure and master, but it isn't nearly as difficult as learning how to read, speak and write in an entirely new vocabulary. One of the major barriers of entry to programming that a lot of people experience are the simple and abstract concepts that are 'hidden' behind words or phrases. For example, some people can't understand why words would be referred to as 'strings' and why numbers are referred to as 'integers'. Why not just call them what they are? Thus, the importance of native language mastery is necessary in order to even grasp the concept that 'words = strings' and 'numbers = integers'. It truly all begins there. Some titles are not so abstract; 'data structures' literally describes how data or information is structured and, thus, how it can be searched. There is nothing mysterious about it when you know the different types of data structures and what they are built for. Therefore, a programmer can begin to design a program to be purpose-driven, just like any computer system. Just like a system engineer shouldn't insist on putting the latest chipset into a washing machine, programmers shouldn't insist on putting unnecessary, duplicate or incompatible functionalities into programs. A tree would not be wise to have a user to try to navigate where a list would suffice. Well, okay, so you need a list. That much might be clear, but what kind of list do you need. Some sort, function or operate differently, and that's where algorithmic design comes in.

Let's break this down a little more:
Taking a list of user input, let's say, into a standard form, we need to organize and store all of this data for future use. Does it make more sense to have 5 different lists that can be searched any number of different ways based on the type of list we decide to use, or is it a better design choice to include all of that data into a structure ('struct') or a tuple, where all of the information a user would input is held under a single variable? Rather than a general purpose tool, programmers must be selective in their choices of how best to practically apply their craft, and this is done in the program design process. That isn't to say, however, that the scope of the program or design cannot or does not change during this process. So, where we can return the results to the user individually from separate lists or arrays, which will take a longer amount of time to cycle through and find the correct correlating information based on, say, index numbers, we can concatenate, or 'compile' all of that information together in a completely different type of data structure to return all of the information we would need in the least amount of time possible. When we design programs for speed, they will be speedy. When there are a bunch of extra movements or processes that the computer needs to complete that are unnecessary and left in due to a clunky design or sloppy code, there is a performance gap.

Over all, best practice is to write questions and their answers on a piece of paper:
What data is being inputted? How should that data best be stored and recalled? Should it be sorted? What program ideas are already set in stone to give me a better idea of what types of algorithms to use? The most important thing to remember is that algorithms and the different types of data structures themselves aren't inherently better than others; they are very much purpose driven, much like any system, and the duty of the programmer is to realize this and to critically examine each type of data structure and the algorithms that apply to that structure that will best complete the functionality needed. The intended application is something that a machine cannot interpret, and therefore, cannot correct for the programmer. Asking yourself these questions, following the guidelines established by the scope of the program, and building it to be purpose-driven are the critical steps toward successfully building a program.