Abstract Data Types: Stacks and Queues

        Python contains many base data types such as lists, strings, integers, and floats. They are generally universal, but sometimes a modified or completely new data type is needed for a certain scenario. For example, in the case of a queue for a restaurant, a list is a perfectly viable way to sequence the numbers while being mutable, however the proper way to modify the list would be that only the front object can be removed, and objects are added to the queue at the back. These restrictions allow for this queue data type to exist as a modified list. In the case of a stack, one may want to represent a sequence of layers placed upon one another. Once again a list is optimal for representing the sequence, however you would only want to be able to add to, and remove from, the last item in the sequence (removing the bottom/ first totem in a totem pole would be impractical, and the pole would collapse).

Recursion

         Many functions act on list objects to produce values asuch as the max value, sum of all values, etc. However when the list has a list within it, functions like sum must be called on the inner list to produce a value computable along with the other values. For example, sum([5, [2, 3], 5]) would result in an error due to the addition of an int and list. what would need to first happen is that sum([2, 3]) is first computed, then sum([5, sum([2, 3]), 5]). We can utilize a for loop in order to cycle through every object in the lowest depth list. If the current object is not a list, return/ process accordingly. However if the current object is a list, run the same for loop on the inner list.

def summer(L):

    if isinstance(list, L):

        return sum([summer(x) for x in L])

    else:

        return L

 On the list [5, [2, 3], 5], the objects of the outer list 5, [2, 3], and 5 will be run through the function. the 5 and 5 are not lists, and will be returned into the outer list, and the [2, 3] will be acted on by summer (summer([2, 3])). On a list with a depth of one the function will simply sum the values as all objects are returned in a list, and are summed. Thus summer([2, 3]) -> sum([summer(2), summer(3)]) -> sum([2, 3]) -> 5. This value is then returned into the outer list. sum(summer(x) for x in [5, [2, 3], 5]) -> sum([summer(5), summer([2, 3]), summer(5)]) -> sum([5, 5, 5]) -> 15. As lists gain a larger depth, the summer function is called more times as it iterates over every internal list.  

Why Geeks Should Write

                Common languages, such as English and French, and their writing can be very ambiguous and free form. It contrasts greatly with programming’s straight forward, unambiguous style. This often raises the question of ‘why geeks should write?’ Although one could plan with flowcharts, planning through writing is as useful and common. In addition writing allows many geeks to share and revise the work of each other. Geeks should write because of the planning benefits and the programming community formed by languages.

                Programming languages are very much reliant on common languages for planning. In the real world, a client will almost always explain what they want through writing, and it will be up to the programmer to understand and plan. If geeks were to not write, the skills processing the common language to programming language translation would be very weak. They need to understand how to filter a client’s writing into a clear, unambiguous order, and then create a map of how to proceed on their project. A geek cannot simply convert any written order into code.  In addition a geek needs to be able to communicate their complex code to others in their community through writing.

                The largest, most vital programs in our world are designed by teams and large communities of geeks. Thus code must be easily explained and displayed for other members of a community. Although code is straightforward and unambiguous, it is difficult for people to process properly as the reason behind the code is not displayed. Through writing one can explain what their code means to others so it may be further refined. Also, one can learn from others more efficiently through the written explanations of their code. These mentor-pupil interactions within a larger community will bind all geeks into a colony, allowing for massive projects to be completed efficiently, and properly.

                Writing allows for a clearer, more efficient planning of a program from an order. The large programming communities are strung together by mentor-pupil interactions via writing. Through the planning benefits, and mentorship brought by writing, geeks should write. This however does not dismiss other vital processes such as flowcharts, as these logical planning routes should be used in sync with written plans.