SE-G23-HW2-3-GameofLife

Group 23 Software Engineering Fall 2020 Game of Life Repo for HW 2,3.

Overview

This repo contains implementations for Conway's Game of Life in 3 languages: Julia, Scala and Kotlin where bugs have been planted at specific locations throughout the code. The tree representation for the repo is as follows:

code
   |
   |___ Julia
        |___ game_of_life.jl
        |___ README.md
   |___ Kotlin
        |___ GoL.kt
        |___ README.md
   |___ Scala
        |___ GameOfLife.scala
        |___ README.md

The instructions to run and debug code in each language can be found in the README.md inside each language's folder. For quick navigation, visit the below links:

Logic for in-place implementation of game of life

In Kotlin and Scala, we have implemented the game of life using an in-place logic. (i.e. without using a new matrix for next generation.) The logic is as follows:
As usual, live cell is represented by 1 and dead cell is represented by 0. But when a live cell becomes dead, we replace '1' with '-1' instead of '0'. Similarly, when a dead cell becomes alive, we replace '0' with '2' instead of '1'.
When we look for live or dead neighbors, we consider '-1' as live cell. (Because, it represents that the cell was live in previous genration but it will be dead in next generation). Similarly, we consider '2' as dead cell.
At the end of loop iteration (i.e. when all the cells are updated and we are ready to move towards next genertion), we replace all '-1' with '0' and all '2' with '1'.
For better understanding of this logic, see 'Approach 2' on this page.

Experimentation script (to guide the session)

Code directory contains the GoL implementations which are almost similar in nature. Each code file contains 2 bugs: 1 compilation bug and 1 runtime bug. We ask you to identify and resolve these bugs from our life so we can live peacefully :)

As a subject in our experiment, we have listed the general steps you will need to follow for each language. Please share your screen with the moderator throughout the session which will aid us in analyzing your interactions with each of these languages.

Visit the ReadMe files from the links provided in the above section.
Follow the instructions in those ReadMe files and find the bugs in the implementations. If you are able to find both the bugs, you will see an output message that shows that compilation test has passed and if logical test is passing or failing.
Once you have discovered the bugs for all 3 languages or the session is coming to an end, you will need to fill this google form: https://forms.gle/ZBSEVTSdRgGMewXd9.

Data collection tools

We leverage a google form filled by the subject and our manual observations to gather the data required to draw insights on. We use the subject's token to identify the subject's responses and do not ask for any personal details anywhere.

Google Form inputs

Programming languages familiar to the subject: Measure how a subject's experience with a similar language aided the understanding of language L.
Time spent working with language L before the experiment: Measure how bug solving effort changes with background experience of the subject in that language.
Time since language L was last used: Measure if it was easier for the subject to solve bugs because they worked with language L recently.
Things helped to solve the bugs: Somtimes compiler messages, familiarity with some other language, etc. may become very useful to solve bugs in some language. so, we ask participants to mention what helped them.
Difficulty level of bugs introduced: Even though we have tried to keep the difficulty level of bugs similar in the different languages' code, we want an input from the subject as to whether they felt any disparities in bug difficulty level among the 3 languages.
Quality of introduced bugs: Qualitative input from the subject on the quality of the bugs.
Ranking the 3 languages based on ease of debugging: Subject's ranking of the 3 languages based on how easy a language was to debug than another.
Ranking the 3 languages based on the interestingness measure: Subject's ranking of the 3 languages based on how interesting they found a language to be.

Manual observations

Time taken to debug bugs in each language: Direct measure of how easy it is to understand code in a language.
Number of bugs solved in each language: Whether the subject was able to solve both the bugs in a language.
Number of times the code was run in the online compiler: Measure of the ease of following the error stacktrace shown by the compiler.
Other remarks: Anything which is not covered in above mentioned observations.
These manual observations will be recorded in this google sheet.

Team Members:

Suraj Patel (sjpate22)
Jay Modi (jmodi3)
Omkar Kulkarni (oskulkar)
Chintan Gandhi (cagandhi)
Nirav Shah (nshah25)

cagandhi / SE-G23-GameofLife