A lot of conceptual changes have been made during the course of our research. It is important to know that some concepts have been proven to misguide and deceive readers and are since deprecated. The terms in question are "archetypes" and "perspectives". Please read this page to gain further insight on what they represent and why they should not be used anymore.
In the winter semester 2016/2017 on my Erasmus+ exchange in Vienna, I have conducted a project under the mentorship of Dr. Paolo Petta (from the Austrian Research Institute for Artificial Intelligence). The project was titled: ”The Effect of Programming Paradigms on Problem Solving” and it tried to answer the research question: ”How do programming paradigms affect how humans tackle problems”. To put it shortly, the main focus of the project was to determine the aspects of programming paradigms that influence human problem-solving process and to determine the effects of these aspects.
During the first phase of the project literature was collected and comprehended. Of significance was the literature from the psychological point of human problem solving, the computer-science’s view of logic programming and programming/engineering standpoint on code analysis. After this phase, a detailed review of two selected programming paradigms was formed in order to better understand them and determine the aspects in which they differ. The selected paradigms were: (1) Object-oriented programming paradigm for its prevalence in programming community and (2) Logic programming paradigm for its unique approach to programming (and still being reasonably known). These two were thoroughly examined during the course of the project.
Our work was heavily influenced by works of Herbert A. Simon, presented in the article: Kotovsky K. and Fallside D. (1988).
For more information, see their ground-breaking study, explained here: Size or Depth ball change.
During the course of the project a short pilot experiment was conducted, in which subjects were asked to write a code that will solve the Tower of Hanoi problem. They were asked to write it for each selected programming paradigm in their respectable programming languages (for (1) language Java was selected and for (2) Prolog). The experiment procedure used was Think Aloud. This experiment provided some critical insight on our research, as the thinking process and code produced for each perspective differed substantially.
Subjects were provided with a laptop computer with Eclipse IDE running on Ubuntu-Mate 1.12., a couple of blank pages, several colored ball-point pens and the rules on a piece of paper (as seen below)
This is a simple puzzle, containing 3 disks of different sizes and 3 poles.
The objective of the puzzle is to move the entire stack from the starting
pole to the goal pole, obeying the following simple rules: (1) Only one
disk can be moved at a time. (2) Each move consists of taking the upper
disk from one of the stacks and placing it on top of another stack i.e.
a disk can only be moved if it is the uppermost disk on a stack. (3) No
disk may be placed on top of a smaller disk.
and were asked to write a program, for each of specified programming paradigm individually. The program must be able to solve the problem - provide a solution, but the solution itself has no other specifications (eg. it is not needed to be optimal).
Additionally, the Think aloud method was used. Subjects were asked to describe every thought out loud that occurs during their problem-solving process in detail. They were also encouraged to write and draw in case their thoughts can not be fully
Three subjects participated in this experiment, all of them male with Bachelor degree in computer science. The criteria for their selection was basic knowledge of both specified programming languages. One subject was later partially discarded, due to usage of Logic programming paradigm in both parts of the experiment.
When undergoing the experiment with the Object-oriented programming paradigm (using the language Java) subjects firstly set up the internal representation of the problem space using programmable objects. Afterwards, some form of graph theory was implemented - stable states were identified (positions of disks on poles) and moves between them. As the problem space was set up, some search algorithm (usually depth search) was executed over the problem graph, that produced the end solution. Solutions obtained this way were sub-optimal, but the physical representation was very clear and though the code was long (mean: 120 lines of code) and it took long time (average: 2.8 hours) to produce, it was subjectively easily readable.
When undergoing the same experiment with the Logic programming paradigm (using the language Prolog), the initial process of designing the code took longer, but the whole programming process was concluded in a much shorter time. The idea subjects used here was double recursion (to move unwanted disks away) and a move of the desired disk. This procedure produces an optimal solution in an shorter period of time (average: 28 minutes) and with less written code (mean: 22 lines of code) compared to the Object-oriented programming paradigm, however the code is subjectively much harder to read.
The whole experiment could have taken place in Java, as one participant pointed out.
The effect of language difference, however great it is, may surely not be the leading factor in the differences between solutions produced! Those can be largely ascribed to paradigm change.
For better understanding, I encourage the reader to check two Java implementations of Tower of Hanoi problem, one for each paradigm used.
This pilot study has provided us with evidence that under different programming paradigms, the problem-solving processes and solutions can differ substantially. With the help of our experiment, some crucial ’ideas’ were identified in the problem-solving processes. These ’ideas’ were marked as archetypes and they play a crucial role in the shaping of a problem-solving process in a specific paradigm. In the Object-oriented programming paradigm, an Object representation (using mental images of physical objects), Graph-space (representing the problem in form of ”stable problem states” and actions to move between them, preferably in a graph visualization) and Depth-search archetypes (searching through move sequences in a deepening manner;in contrast to breadth-search) were mostly observed. On the other hand, in the Logic programming paradigm the archetypes used were mostly: Sub-problems (splitting problem into smaller problems) and Recursion (using the same function inside the function).
Each of these archetypes provides unique design (of problem-solving process) and solution features, that may or may not be desirable, and a set of these archetypes fully defines a paradigm. This new model was also applied to some other problems, outside of the frame of programming paradigms. Each time a same set of archetypes was used, the problem-solving process and the solution features were similar. However, when using a different set of archetypes, both the problem-solving process and the solution features differ substantially. How much they differ depends on the difference between archetype sets.
Support for our theory can also be found in works of Kotovsky K. and Fallside D. (1988) (former associates of Herbert A. Simon) where they observed difference in internal representation of a problem. Subjects were presented with a changing ball on a computer screen - one group was told the ball is increasing / decreasing in size (”size” problem) while the other was told that the ball is coming closer / retreating further (”distance” problem); while both groups were observing the same stimulus. The internal representation subjects made had strong impact on their problem-solving process and transfer (”Transfer” marks the application of knowledge, gained from solving a specific problem, on a novel problem and thus improve its problem-solving process. (Kotovsky and Fallside, 1998)), as subjects who were solving the ”size” problem preformed better and their knowledge was better transferred, compared to subjects who were solving the ”distance” problem. Their research can be easily applied to our archetype model; archetypes are transferable entities that contain some individual features, which are ultimately reflected in the problem-solving process.
I really enjoyed working with Dr. Paolo Petta on this project. Discovering something quite novel and creating a whole new framework to enclose this knowledge into, gave me the momentum to power through seemingly endless set of articles, framework design problems, ethic issues and other unpleasantries that arose. I fell in love with the project and therefore it was easy to put in all the work and extra hours that exceeded project plan.
We had a lot of problems during the course of the project, but thankfully Dr. Petta was always there to help. Sometimes it took him longer to respond, which is understandable due to sheer amount of work he probably has; however when we did meet to discuss our project, he contributed much more time and knowledge than I expected. Admittedly, initially I was taken aback with all the issues and advice he had given me on our first meeting about initial project layout, disregarding it as unnecessary and retreating to my way of work. Oh boy, was I wrong. All of the issues he talked about had arisen during the course of the project and I only wish I had taken his advice before. Although some slip-ups did occur, I did listen and take his advice to deal with problems on hand and tried my best to follow it. I am used to working alone and in that mindset I often make important decisions without consultation with others involved. I did this on a couple occasions during this project, and I deeply apologize for each and every one of them. Dr. Petta was very understanding and without intruding, has always pointed me in the right direction to deal with the mess I created. For one, I really enjoyed those long talks we had and on this point, I would like to thank him again for all of his time, patience and contributions to our project. My experience with him was outstanding and I really recommend Dr. Petta for future mentorships.