Object-Oriented Programming

Up until now we have been learning the basics of object - oriented programming in Python. We have learnt how to create our own objects by creating classes with certain attributes and how to give the objects their own functions known as “methods”. While you can create your own methods that can do anything a function can do, we have learnt about the special python methods. These methods allow you to do things within python like check if two objects are equivalent (with the __eq__ method) and create a string representation of the object when you print it or use the str() function. These special methods are identified by being surrounded by double underscores e.g., __str__. One thing that I always wondered while using Python was if there was a way to make objects and attributes private as you can in most other programming languages, and I found out you cannot but we did learn a way to mimic privacy. This is done using Python’s built-in property() which basically allows you to control what happens when you try to change and access an attribute of an object. In class we used property() to only allow a variable to be set by the user once by controlling what happens when you try to change the value of a variable. We learnt that if you want an attribute to be untouched you up a “_” before the name, this does not actually make it private but it tells the user that it is at their own risk to change it.


The most interesting and useful thing we have learnt in OOP so far was how to make objects inherit attributes and methods from other objects. This was the main focus of assignment 1 and I think it was very helpful for it to be so. Understanding how to make a base class that covers all of the base needs many other classes will need is very helpful as it saves coding time and helps prevent errors from copy-pasting code.

Tracing Recursion

                Last week I talked about how interesting recursion was to me, and since then I have read the SLOGs of many other students who are also very interested in the topic. Among the SLOGs I read was Jesse’s who in his post entitled “Wrapping my head around recursion” took an amusing baked dessert look on recursion. In week four we learned how to properly trace a recursive function so that we can understand how a function behaves with different inputs and eventually prove that any input will work with the function (with certain conditions). This is done by starting with the simplest (or shallowest) input you could input and tracing deeper and deeper calls (one depth at a time). In the processes you do not have to rewrite a depth you have already tried as you have already proved that the function works with that depth.

                I find this method of tracing a recursive function very helpful as it can be used to trace most recursive functions no matter the complexity. Some students seem to find it pointless with the function we have been practising with as you can figure out most of them in your head without this method, but that is not the point of us learning this method. This method is meant to help us with any recursive function that we may come across and for that I find it extremely helpful.

The First Four Weeks of CSC148

                In the first four weeks of CSC148 we have learnt about classes, subclasses (inheritance) and recursion. Although it was very valuable to learn about classes and how to make other classes inherit all of the methods and attributes of another class, in my opinion the most interesting instrument that we have learnt in the first weeks is recursion. At first recursion is a very abstract thing to think about, a function calling its self in its own definition. 

                When you eventually wrap your head around what is happening you will realise that it is basically the same as a conditional loop but a lot cleaner and simpler to implement. Recursion allows you to use a function that would normally only work with a finite number of instances and allows it to be used for an (almost) infinite number of instances. As such recursion makes creating algorithms based on repeating tasks (such as sorting) much easier to implement.

Why Geeks Should Write

                In today's connected world an idea can be shared with anyone almost instantly. This sharing of thought and knowledge makes it possible to lean almost anything you could imagine just by searching for it on the internet, but if you do not know about the existence of a topic you would never know to search and learn about it. This is why geeks should write (more than they do). Although geeks do write and share information, this information is normally found in places where “non-geeks” would never look and is often explained in ways that only another ‘geeks’ would understand. This is why geeks should not only write more but should write in a way that anyone could find and understand the information.

                People in professions such has humanities are great at getting their thoughts and knowledge out to the masses. This means that many people know at least the general idea of the topics in their field and can learn more about them if they please, the same cannot be said about things “geeks” are interested in. The very fact that geeks are referred to as “geeks” shows that what they are interested in is not considered normal, but why shouldn’t it? Everyone in the modern world with a mobile phone uses technology created by “geeks” almost every day of their lives, and very few of them understand how the technology and software that make up their devices function. The fact that people use technology everyday shows that there is a very large following for the things geeks are interested in so why shouldn’t people at least have a chance to understand. In this world of many professions and ways of thinking, sharing is the only way to progress together.