Team Project: Little Language Interpreters

In teams, write a program that implements three seemingly different applications that use a small programming language to operate one or more turtles to move or draw with. Each program should share a common interpreter based on the similar syntax that allows users to enter programs interactively to be evaluated and visualized in various ways.

The first application below is required and the team can chose to do two of the remaining three options.

• Logo (required): a programming language with commands for drawing
• L-Systems: a programming language for drawing growth processes, such as in plants, fractals, or tiles
• Darwin: a programming language for modeling different creature species
• Karel: a programming language for controlling robots

Start early and simply, with strong tests in order to verify your understanding of the project's core features. Then refactor your code to help it serve as a foundation for the more diverse functionality expected.

The programming language, graphics visualization, and desktop or web display is your team's choice.

Submitting Your Work

Use GIT to push your team's implementation to the main branch of the provided, shared, interpreter_teamNN repository hosted in the course's Gitlab group for each Phase:

• Your code should follow your language's coding conventions, be reasonably commented, use logging (rather than print statements)
• Submit gitignore and gitattribute files, as well as any properly attributed resources (images, sounds, configuration files, etc.) your program needs
• Submit tests that follow these naming standards that achieve at least 70% line test coverage overall
• Submit an updated project README file at the top-level (no separate folder)
• Tag the commit representing the submitted version of the code as PhaseN_Complete
• Submit a 2-4 minute video using your program, with a voice over explaining how the code works.
  In addition to simply using Zoom, there are many free screen capture tools available for any platform or free trials of some pretty powerful tools as well.
• Submit the log output produced from the program's run that you recorded in your video.
  Note, name it phaseN_log.txt so it is not recognized by your gitignore file.

You are responsible for ensuring that all files are correctly pushed to the repository on time.

Individual Responsibilities when Working as a Team

Although this is a team project, everyone has individual responsibilities to the team that can be summed up as follows:

• actively participate in all team meetings
• regularly contribute clean code to the shared repository in reasonably sized chunks
• solving and coding at least one "interesting" design problem
• helping teammates at least once by going above and beyond

Your team's project GIT repository should reflect this by with many small purposeful commits using commonly formatted commit messages from all team members rather than just one or two large "kitchen sink" commits and marathon merging or redesign sessions. Specifically, we will be looking for deliberate attempts to regularly:

• close assigned Issues
• integrate each other's branches via Merge Requests
• refactor code to improve its design
• test your functionality

Unfortunately conflicts are likely to occur, so please let the Teaching Team know as soon as possible — even if it has happened just once or twice since it is better to deal with the situation early rather than having a disaster at the end when little can be done to get back on track.

Specification

Turtle Graphics was invented as part of the Logo programming language designed to teach programming to children by allowing them to control a physical robot. Users could issue commands such as FORWARD 50 to make the robot actually move 50 steps or RIGHT 90 to make it turn ninety degrees. The turtle robot carried a pen to produce drawings on paper put down under the robot. The turtle, which has since moved on to the computer screen, has become Logo's most familiar feature. Additionally, it has helped people think differently about teaching geometry, social science, and especially programming.

Since Logo is used by children internationally, a feature of the syntax is that the language in which commands are given can be configured (i.e., FD represents the word Forward, which in Spanish is Avanzar, abbreviated as AVA). Your interpreters should support this flexibility as well (here are some example translations).

Most modern systems are configured using data files or command line arguments rather than hardcoding values into the source code. These values should have appropriate defaults (in case no file is provided) and be checked for validity (never trust user input). In addition to the application specific values, all program(s) should allow configuration of at least the following values:

• language to be used
• file(s) of code to run
• image(s) to be used for the turtle(s)
• default Home position

The exact format and content of your configuration file should be determined by your team, but it must be a standard file type with a parser (rather than developing your own) such as:

• Properties File, a list of key/value pairs
• Comma-separated Values, CSV, like those used to represent spread sheets
• JavaScript Object Notation, JSON, an open, industry standard, flexible format
• eXtensible Markup Language, XML, an open, industry standard, flexible format

You have the flexibility to create one program that handles all the applications or separate programs that handle a single application. In either case, they should reuse a common API for the backend interpreter. Your program(s) should not crash or hang, no matter what input is given, by handling errors and providing a reasonable response to exceptional cases. Consider using Exceptions to communicate errors in a thoughtful, intentional, manner rather than returning null or other error prone values.

Most modern languages, and even some platforms, have a Turtle Graphics implementation, including being the core of the current modern children's programming environment Scratch:

• Python
• Java
• JavaScript
• C/C++

An interactive User Interface for each application is not required, just the ability to display the results of running a program file.

Optionally, you can build a more complete UI that allows the user to:

• enter and run programs interactively
• display the results of executing the commands visually
• see errors that may result from entered commands in a user friendly way (i.e., not just printed to the console or crashing the program)
• load a program from a file
• save the current program to a file
• reset the environment back to its starting state
• set the size of the display area
• see commands previously entered and reuse them again easily (perhaps by clicking on them rather than having to copy/paste them by hand)
  
• view any turtle's state (i.e., xy-location and heading)
• set a color and thickness to use for the turtles' pen
• pause the animation or set how fast the animation updates the simulation
• set an image to use for the current turtles
• set a background color for the display area
• set the Home location to a specific xy-location (default is the center of the display)

All text displayed and styles (colors, font, borders, etc.) used in the User Interface must be customizable.

Design Specifications

You should design your program design such that adding new features becomes easier (or refactor your code better to accommodate changes). Specifically, your design should be thoughtful and intentional: clearly avoiding duplicate code structures and making it easy to add more of these kinds of applications without changing the existing code.

The following Design Goals should help guide you:

1. Clean code. Write your code primarily for communication: to avoid duplication, to support your team mates, and so that it can be easily understood by others
2. Use multiple classes. Divide your code into several classes that each have an active, useful, purpose (i.e., non-get/set methods)
3. Avoid hardcoded values. Move typical "magic" values or displayed strings into files, rather than compiled into your program, using resource, configuration, and style files
4. Separate Model/View. Create a cleanly structured GUI that is separated from the model and what information (including errors) needs to be returned from the model
5. Application Programmer's Interface (API). Provide a well-defined API for your shared interpreter that hides its internal workings
6. Encapsulation: Create classes, based on their behavior rather than their state, to hide the each part's implementation decisions
7. Exceptions. Communicate errors in a thoughtful, intentional, manner rather than returning null or other error prone values
8. SOLID Design Principles. Structure the core of your project with single-purposed, substitutable abstractions to help your design be more understandable and flexible

Phases

Working together as a team, collaborate to create your planned functionality using the priorities decided on by your team to determine when the features should be implemented (expressed as Gitlab Issues).

An obvious ordering would be one application per phase. Our suggested ordering for your phases is:

1. Basic, well-test version of one application to build the core features of the project and learn about the design issues
2. Basic, tested versions of the other two applications to validate your API and clarify your design plan
3. Final, refactored versions of all three applications with proper error handling