Finish generation 1 section of introduction

bibliography.bib

@@ -393,6 +393,23 @@
   file = {/home/charlotte/sync/Zotero/storage/UWSG2P4L/Bernius et al. - 2022 - Machine learning based feedback on textual student.pdf;/home/charlotte/sync/Zotero/storage/TLLKP87F/S2666920X22000364.html}
 }
 
+@article{berryGraderPrograms1966,
+  title = {Grader {{Programs}}},
+  author = {Berry, R. E.},
+  year = {1966},
+  month = nov,
+  journal = {The Computer Journal},
+  volume = {9},
+  number = {3},
+  pages = {252--256},
+  issn = {0010-4620},
+  doi = {10.1093/comjnl/9.3.252},
+  url = {https://doi.org/10.1093/comjnl/9.3.252},
+  urldate = {2024-02-07},
+  abstract = {This paper examines the possibility of using automatic grading programs for checking some of the practical work of students on a Numerical Analysis course. Two existing programs for checking root-finding techniques were tested to gain experience in using grader programs. A program to check solutions to a system of n first order differential equations was written.},
+  file = {/home/charlotte/sync/Zotero/storage/M66WNCES/berry1966.pdf.pdf;/home/charlotte/sync/Zotero/storage/WEVW8H9W/Berry - 1966 - Grader Programs.pdf;/home/charlotte/sync/Zotero/storage/34CCGYRS/406256.html}
+}
+
 @inproceedings{bethkeryExploringExploratoryProgramming2017,
   title = {Exploring Exploratory Programming},
   booktitle = {2017 {{IEEE Symposium}} on {{Visual Languages}} and {{Human-Centric Computing}} ({{VL}}/{{HCC}})},
@@ -561,6 +578,13 @@
   file = {/home/charlotte/sync/Zotero/storage/LNLEXLHZ/Børte et al. - 2020 - Barriers to student active learning in higher educ.pdf;/home/charlotte/sync/Zotero/storage/ZHKF2YD4/13562517.2020.html}
 }
 
+@book{braden1965introductory,
+  title = {An Introductory Course in Computer Programming},
+  author = {Braden, Robert T and Perlis, Alan J},
+  year = {1965},
+  publisher = {{Clearinghouse for Federal Scientific and Technical Information, US {\dots}}}
+}
+
 @book{brooksNoSilverBullet1987,
   title = {No Silver Bullet},
   author = {Brooks, Frederick and Kugler, H},
@@ -1267,6 +1291,22 @@
   file = {/home/charlotte/sync/Zotero/storage/4IGJ3LIJ/Forsberg and Shultz - 2009 - Perceived Fairness of a Background Information For.pdf}
 }
 
+@article{forsytheAutomaticGradingPrograms1965,
+  title = {Automatic Grading Programs},
+  author = {Forsythe, George E. and Wirth, Niklaus},
+  year = {1965},
+  month = may,
+  journal = {Communications of the ACM},
+  volume = {8},
+  number = {5},
+  pages = {275--278},
+  issn = {0001-0782},
+  doi = {10.1145/364914.364937},
+  url = {https://dl.acm.org/doi/10.1145/364914.364937},
+  urldate = {2024-02-06},
+  file = {/home/charlotte/sync/Zotero/storage/4WT3CXI4/Forsythe and Wirth - 1965 - Automatic grading programs.pdf;/home/charlotte/sync/Zotero/storage/6E4CRJY3/forsythe1965.pdf.pdf}
+}
+
 @article{gibbsConditionsWhichAssessment2005,
   title = {Conditions {{Under Which Assessment Supports Students}}' {{Learning}}},
   author = {Gibbs, Graham and Simpson, Claire},
@@ -1550,6 +1590,24 @@
   file = {/home/charlotte/sync/Zotero/storage/CRBJ9RWK/Hernández-de-Menéndez et al. - 2022 - Learning analytics state of the art.pdf}
 }
 
+@article{hextAutomaticGradingScheme1969,
+  title = {An Automatic Grading Scheme for Simple Programming Exercises},
+  author = {Hext, J. B. and Winings, J. W.},
+  year = {1969},
+  month = may,
+  journal = {Communications of the ACM},
+  volume = {12},
+  number = {5},
+  pages = {272--275},
+  issn = {0001-0782},
+  doi = {10.1145/362946.362981},
+  url = {https://dl.acm.org/doi/10.1145/362946.362981},
+  urldate = {2024-02-06},
+  abstract = {A discussion is given of alterations that were made to a typical university operating system to record the results of programming exercises in three different languages, includeing assembly language. In this computer-controlled grading scheme provision is made for testing with programmer-supplied data and for final runs with system-supplied data. Exercises run under the scheme may be mixed with other programs, and no special recognition of exercises by the operators is necessary.},
+  keywords = {automatic grading program,programming exercises},
+  file = {/home/charlotte/sync/Zotero/storage/542L4HBY/hext1969.pdf.pdf;/home/charlotte/sync/Zotero/storage/MCQ2FCYW/Hext and Winings - 1969 - An automatic grading scheme for simple programming.pdf}
+}
+
 @mastersthesis{holeProgrammingIntroductoryPhysics2020,
   title = {Programming in {{Introductory Physics}}: An {{Online Learning Platform}} to {{Support Teachers}}},
   shorttitle = {Programming in {{Introductory Physics}}},
@@ -2563,6 +2621,24 @@
   keywords = {asynchronous discussion forums,fully online course,quality framework}
 }
 
+@article{naurAutomaticGradingStudents1964,
+  title = {Automatic Grading of Students' {{ALGOL}} Programming},
+  author = {Naur, Peter},
+  year = {1964},
+  month = sep,
+  journal = {BIT},
+  volume = {4},
+  number = {3},
+  pages = {177--188},
+  issn = {0006-3835},
+  doi = {10.1007/BF01956028},
+  url = {https://doi.org/10.1007/BF01956028},
+  urldate = {2024-02-06},
+  abstract = {The report describes an experiment on automatic grading of student algorithms, using an ALGOL compiler. The experiment is based on an evaluation of the efficiency and logical completeness of the algorithms, not on their formal correctness, which is supposed to be checked in advance by the individual student. The technique used is to embed the student algorithms within a larger grading program structure, which supplies test cases and performs checks and evaluation. The complete text of such a grading program is given. The experience gained through the experiment, and suggestions for further developments, are discussed.},
+  keywords = {Complete Text,Computational Mathematic,Formal Correctness,Individual Student,Program Structure},
+  file = {/home/charlotte/sync/Zotero/storage/7XRCLVIF/naur1964.pdf.pdf}
+}
+
 @inproceedings{navratOnlineProgrammingExercises2014,
   title = {Online Programming Exercises for Summative Assessment in University Courses},
   booktitle = {Proceedings of the 15th {{International Conference}} on {{Computer Systems}} and {{Technologies}}},
@@ -3482,6 +3558,23 @@
   file = {/home/charlotte/sync/Zotero/storage/NXAQCTYB/Svetnik et al. - 2003 - Random Forest  A Classification and Regression To.pdf;/home/charlotte/sync/Zotero/storage/KLIJU6B7/ci034160g.html}
 }
 
+@article{temperlyGradingProcedurePL1968,
+  title = {A {{Grading Procedure}} for {{PL}}/1 {{Student Exercises}}},
+  author = {Temperly, J. F. and Smith, Barry W.},
+  year = {1968},
+  month = feb,
+  journal = {The Computer Journal},
+  volume = {10},
+  number = {4},
+  pages = {368--373},
+  issn = {0010-4620},
+  doi = {10.1093/comjnl/10.4.368},
+  url = {https://doi.org/10.1093/comjnl/10.4.368},
+  urldate = {2024-02-07},
+  abstract = {A procedure to supply test data for a number of undergraduate programming exercises in the PL/1 language and check the validity of the programs is described. The procedure provides diagnostic information to the student and performs all necessary output, as well as maintaining complete records of student performance on magnetic disc storage. The procedure differs from many previous grading routines in being called as a precompiled library subroutine, and is the first known grading procedure for PL/1. The initial set of class problems and specimen output listings are appended.},
+  file = {/home/charlotte/sync/Zotero/storage/KUPEZD7J/temperly1968.pdf.pdf;/home/charlotte/sync/Zotero/storage/YN8PSZBD/Temperly and Smith - 1968 - A Grading Procedure for PL1 Student Exercises.pdf;/home/charlotte/sync/Zotero/storage/DDYSUANU/463937.html}
+}
+
 @inproceedings{thurnerObjectsFirstTests2015,
   title = {An ``Objects First, Tests Second'' Approach for Software Engineering Education},
   booktitle = {2015 {{IEEE Frontiers}} in {{Education Conference}} ({{FIE}})},

book.org

@@ -3,7 +3,7 @@
 #+AUTHOR: Charlotte Van Petegem
 #+LANGUAGE: en-gb
 #+LATEX_CLASS: book
-#+LATEX_CLASS_OPTIONS: [paper=240mm:170mm,numbers=noendperiod,parskip=half,BCOR=10mm,10pt]
+#+LATEX_CLASS_OPTIONS: [paper=240mm:170mm,numbers=noendperiod,BCOR=10mm,DIV=10]
 #+LATEX_COMPILER: lualatex
 #+LATEX_HEADER: \usepackage[inline]{enumitem}
 #+LATEX_HEADER: \usepackage{shellesc, luacode}
@@ -125,25 +125,90 @@ In volgorde van prioriteit:
 :END:
 
 Ever since programming has been taught, its teachers have sought to automate and optimize their teaching.
-This has led to the development of myriad automated assessment tools, of which we will give an overview in this introduction.
-Due to the ever-increasing digitalization of society, this teaching has to happen for larger and larger groups, and these groups will include students for whom programming is not necessarily their main subject.
-We will thus also discuss learning analytics and educational data mining, and how these tools can help us to cope with the growing class sizes.
+Due to the ever-increasing digitalization of society, programming is also being taught to ever more and ever larger groups, and these groups more and more often include students for whom programming is not necessarily their main subject.
+This has led to the development of myriad automated assessment tools\nbsp{}[cite:@paivaAutomatedAssessmentComputer2022; @ihantolaReviewRecentSystems2010; @douceAutomaticTestbasedAssessment2005; @ala-mutkaSurveyAutomatedAssessment2005], of which we will give a historical overview in this introduction.
+We will also discuss learning analytics and educational data mining, and how these tools can help us to cope with the growing class sizes.
 Finally, we will give a brief overview of the remaining chapters of this dissertation.
 
-** A history of automated assessment in programming education
+** Automated assessment in programming education
 :PROPERTIES:
 :CREATED:  [2024-02-01 Thu 10:46]
 :CUSTOM_ID: sec:introhistory
 :END:
 
-Learning how to solve problems with computer programs requires practice, and programming assignments are the main way in which such practice is generated\nbsp{}[cite:@gibbsConditionsWhichAssessment2005].
-Because of its potential to provide feedback loops that are scalable and responsive enough for an active learning environment, automated source code assessment has become a driving force in programming courses.
-This has resulted in a proliferation of educational programming platforms\nbsp{}[cite:@paivaAutomatedAssessmentComputer2022; @ihantolaReviewRecentSystems2010; @douceAutomaticTestbasedAssessment2005; @ala-mutkaSurveyAutomatedAssessment2005].
-Automated assessment was introduced into programming education in the early 1960s\nbsp{}[cite:@hollingsworthAutomaticGradersProgramming1960] and allows students to receive immediate and personalized feedback on each submitted solution without the need for human intervention.
+Increasing interactivity in learning has long been considered important, and furthermore, something that can be achieved through the addition of (web-based) IT components to a course\nbsp{}[cite:@vanpetegemPowerfulLearningInteractive2004].
+This isn't any different when learning to program: learning how to solve problems with computer programs requires practice, and programming assignments are the main way in which such practice is generated\nbsp{}[cite:@gibbsConditionsWhichAssessment2005].
 [cite/t:@cheangAutomatedGradingProgramming2003] identified the labor-intensive nature of assessing programming assignments as the main reason why students are given few such assignments when ideally they should be given many more.
+Automated assessment allows students to receive immediate and personalized feedback on each submitted solution without the need for human intervention.
+Because of its potential to provide feedback loops that are scalable and responsive enough for an active learning environment, automated source code assessment has become a driving force in programming courses.
+
+*** Humble beginnings
+:PROPERTIES:
+:CREATED:  [2024-02-06 Tue 15:30]
+:END:
+
+Automated assessment was introduced into programming education in the late 1950s\nbsp{}[cite:@hollingsworthAutomaticGradersProgramming1960].
+In this first system, programs were submitted in assembly on punch cards.
+(For the reader who is not familiar with punch cards, an example of one can be seen in Figure\nbsp{}[[fig:introductionpunchard]]).
+In the early days of computing, the time of tutors was not the only valuable resource that needed to be shared between students; the actual compute time was also a shared and limited resource.
+Their system made more efficient use of both.
+[cite/t:@hollingsworthAutomaticGradersProgramming1960] already notes that the class sizes were a main motivator to introduce their auto-grader.
+At the time of publication, they had tested about 3\thinsp{}000 student submissions which, given a grading run took about 30 to 60 seconds, represents about a day and a half of computation time.
+
+They also immediately identified some limitations, which are common problems that modern graders still need to consider.
+These limitations include handling faults in the student code, making sure students can't modify the grader, and having to define an interface through which the student code is run.
+
+#+CAPTION: Example of a punch card.
+#+CAPTION: Picture by Arnold Reinhold, released under the CC BY-SA 4.0 license via WikiMedia Commons.
+#+NAME: fig:introductionpunchard
+[[./images/introductionpunchcard.jpg]]
+
+In the next ten years, significant advances were already made.
+Students could submit code written in a text-based programming language instead of assembly, and the actual testing was done by running their code using modified compilers and operating systems.
+
+[cite/t:@naurAutomaticGradingStudents1964] was the first to explicitly note the difference between the formal correctness, and the efficiency and completeness of the programs being tested.
+The distinction between formal correctness and completeness that he makes can be somewhat confusing from a modern standpoint: we would only consider a program or algorithm formally correct if it is complete (i.e. gives the correct response in all cases).
+In more modern terminology, Naur's "formally correct" would be called "free of syntax errors".
+
+[cite/t:@forsytheAutomaticGradingPrograms1965] note another issue when using automatic graders: students could use the feedback they get to hard-code the expected response in their programs.
+This is again an issue that modern graders (or the teachers creating exercises) still need to consider.
+[cite/t:@forsytheAutomaticGradingPrograms1965] solve this issue by randomizing the inputs to the student's program.
+While not explicitly explained by them, we can assume that to check the correctness of a student's answer, they calculate the expected answer themselves as well.
+Note that\nbsp{}[cite/t:@forsytheAutomaticGradingPrograms1965] were still writing a grading program for each different exercise.
+
+[cite/t:@hextAutomaticGradingScheme1969] introduce a new innovation: their system could be used for exercises in several different programming languages.
+They are also the first to implement a history of student's attempts in the assessment tool itself, and mention explicitly that enough data should be recorded in this history so that it can be used to calculate a mark for a student.
+
+Other grader programs were in use at the time, but these did not necessarily bring any new innovations or ideas to the table\nbsp{}[cite:@braden1965introductory; @berryGraderPrograms1966; @temperlyGradingProcedurePL1968].
+
+The systems described above share an important limitation, which is inherent to the time at which they were built.
+Computers were big and heavy, and had operators who did not necessarily know whose program they were running or what those programs were.
+(Engelbart's Mother of All Demos, widely considered the birth of the idea of the personal computer, only happened in 1968.)
+So, it should not come as a surprise that the feedback these systems gave was slow to return to the students.
+
+*** Using scripts and tools
+:PROPERTIES:
+:CREATED:  [2024-02-06 Tue 17:29]
+:END:
+
+We now take a leap forward in time to the 1980s.
+The way people use computers has changed significantly, and the way assessment systems are implemented changed accordingly.
+
+*** Onto the web
+:PROPERTIES:
+:CREATED:  [2024-02-06 Tue 17:29]
+:END:
+
+*** Adding features
+:PROPERTIES:
+:CREATED:  [2024-02-06 Tue 15:31]
+:END:
+
+At this point in history, the idea of an automated assessment system is no longer new.
+But still, more and more new platforms were being written.
+
 While almost all platforms support automated assessment of code submitted by students, contemporary platforms usually offer additional features such as gamification in the FPGE platform\nbsp{}[cite:@paivaManagingGamifiedProgramming2022], integration of full-fledged editors in iWeb-TD\nbsp{}[cite:@fonsecaWebbasedPlatformMethodology2023], exercise recommendations in PLearn\nbsp{}[cite:@vasyliukDesignImplementationUkrainianLanguage2023], automatic grading with JavAssess\nbsp{}[cite:@insaAutomaticAssessmentJava2018], assessment of test suites using test coverage measures in Web-CAT\nbsp{}[cite:@edwardsWebCATAutomaticallyGrading2008] and automatic hint generation in GradeIT\nbsp{}[cite:@pariharAutomaticGradingFeedback2017].
 
-Increasing interactivity in learning has long been considered important, and furthermore, something that can be achieved through the addition of web-based components to a course\nbsp{}[cite:@vanpetegemPowerfulLearningInteractive2004].
 
 ** Learning analytics and educational data mining
 :PROPERTIES:
@@ -163,7 +228,7 @@ Chapter\nbsp{}[[#chap:use]] then focuses on how Dodona is used in practice, by p
 Chapter\nbsp{}[[#chap:technical]] focuses on the technical aspect of developing Dodona and its related ecosystem of software.
 This includes discussion of the technical challenges related to developing a platform like Dodona, how the Dodona team adheres to modern standards of software development, etc.
 
-Chapter\nbsp{}[[#chap:passfail]] talks about a study we did, where we tried to predict whether students would pass or fail a course at the end of the semester based solely on their submission history in Dodona.
+Chapter\nbsp{}[[#chap:passfail]] talks about a study where we tried to predict whether students would pass or fail a course at the end of the semester based solely on their submission history in Dodona.
 It also briefly details a study we collaborated on with researchers from Jyväskylä University in Finland, where we replicated our study in their educational context, with data from their educational platform.
 
 In Chapter\nbsp{}[[#chap:feedback]], we first give an overview of how Dodona changed manual assessment in our own educational context.