Introducing the Pennsylvania Computer Science Teaching Certification Langauge

This past June I got involved with a project to improve computer science teaching in Pennsylvania. As a teaching assistant at a CSforAllPA Boot Camp, a week long training for teachers to learn computer science, we found a need for an interpreter for the language defined by their certification exam. The creators of this exam defined a new programming language, specifically for displaying questions on their exam, but with little consideration for how teachers would be expected to familiarize themselves with the language or the test. Coming off the success of my senior project, started by a friend of mine to build a programming language pretty much from scratch, I suggested instead of attempting to substitute Java for the exam language, we not-so-simply build our own interpreter for it.

During the boot camp, we taught in both Java and the exam language. While this exposed teachers to both the "code-test-debug-repeat" cycle and the exam language, the rapid exposure to two somewhat distinct languages seemed quite rough, especially for those who were learning programming for the first time.

Here is a comparison of the exam language and Java, side by side. Syntactically, you'll notice that exam language is not a "curly brackets" language, instead opting to use keywords and indentation for marking code blocks, and it lacks the public class Factorial { class declaration which Java requires. It also uses keywords for logical operations: and, or, and not, instead of &&, ||, and !. To an experienced programmer, this is very superficial, although I must confess to having had long arguments over such minutia in the past. Semantically, its easy to notice (perhaps on a longer block of code) that both use weak static typing, pretty much following C. A deeper look, you'll notice both are missing all the unsigned types. What this amounts to is that while you cannot change the type of a variable, the language will automatically change the type of values within certain expressions. This behavior can be contrasted to Python or JavaScript which respectively have strong dynamic typing, and weak dynamic typing: meaning that variables don't have types at all, it is values which carry the type, and in Python, a value must be explicitly casted and JavaScript will do its very best to implicitly cast everything even where it doesn't make sense.

int fact(int n)
    int result;
    if(n == 0 or n == 1)
        result <- 1
    else
        result <- fact(n - 1)
    end if
    return result
end fact

public class Factorial {
    public static int fact(int n) {
        int result;
        if(n == 0 || n == 1) {
            result = 1;
        } else {
            result = fact(n - 1);
        }
        return result;
    }
}

Of the established mainstream languages, I believe, and clearly the professors leading the boot camp too, that Java is the nearest substitute for the exam language. So why then do we want to look into alternatives to Java? The boot camp was incredibly fast paced. by the second day we had them working through nested loops, and for some, the delineation of different scopes was unclear, in part due to the changing scope delimiters: keyword(...) { [scope] } versus keyword(...) [scope] end keyword. Over the past four years as a teaching assistant, I've noticed that learning how scopes work is often times one of the more difficult tasks in learning to program, and I've also noticed how not understanding how scopes work can completely set a student up for failure, because they will struggle to understand their own programs structure. Seeing two different forms of scope delimiters seemed to confuse students, especially those without any prior programming experience. In my mind, this is the biggest reason to teach the boot camp in only a single programming language.

To remedy this split, I've been working on an interpreter for the exam language. In order to avoid trademark infringement on the specific exam, I've been calling the project Pennsylvania Computer Science Teaching Certification Language or PaCSTCL (pronounced like "obstacle") for short. The hope is that with a single language for their training and examination, teachers will more easily pick up programming, and also be confident in their ability to apply programming concepts to lessons in their classrooms.

To conform as closely to the exam language, I'll be using the guidelines set out in the exam's study companion, on pages 13 and 14, as well as evaluating against all of the code examples in the study companion, and any other resources I can find. Because the study companion's guidelines leave a lot to be desired, I've been instructed to mimic Java's semantics where clear semantics are not given by the study companion. I'm also planning to define a formal language specification, to trace PaCSTCL's behavior back to the behavior defined in the study companion and in Java.

Development of this project is not an easy undertaking. I'd like to thank Dr. Tammy Pirmann for bringing me to the CSforAllPA Boot Camp as her TA, without which I would not have gotten involved with this project, and who also has provided much clarification on the intended semantics of the exam language. I'd also like to thank Prof. Mark Stehlik for actually believing that I could do this, and of course making the introductions necessary to start this project. Lastly I'd like to thank the Pennsylvania Training and Technical Assistance Network (PaTTAN) and Lancaster-Lebanon Intermediate Unit 13 (IU13) for funding this endeavor.