| Syllabus | Links | Schedule | Grades |
Location and Time - Halsell 228, 11:20-12:35 TR
Professor - Dr. Mark Lewis, Office: HAS 201K, Phone: 999-7022, e-mail: mlewis@trinity.edu. The best way to reach me typically is by e-mail. I check it frequently and try to respond promptly.
Office Hours - 3:30-4:30 M, 1:00pm-4:30pm TR, 2:00pm-4:00pm W, or by appointment. I'm in my office a lot so you should free to drop by. If you are coming from lower campus you can always call or write a short e-mail to see if I'm in and available at that time.
Texts - "Programming in Scala" by Martin Odersky, Lex Spoons, and Bill Venners, "Programming F#" by Chris Smith. We will also be using web resources for X10 and Fortress.
Course Description - This is an upper division course in which we will look at a few of the languages that you might expect to see more of in the future. Even if these particular languages don't make it to the big time, it is likely that the hybrid features of these languages will as these are mixed paradigm languages.
The course involves significant amount of reading and coding. Students will be learning two full languages to a fairly deep level and exploring others to a lesser extent. The tasks in the course are intended to develop student's general understanding of programming languages, their programming abilities, and their writing and public speaking skills.
Course Format - The format for this course will be a bit different than what you normally have had in courses. There will not be prepared lectures on most days. Instead, students are asked to show up to class with a sample of interesting code that uses the topic of the days reading. Only a faction of the students will have to bring code each class day. In addition, all students are to bring two questions related to the reading each day. The class time will be spent looking at the programs of the students who bring in code and having a discussion based on the questions. So the quality of the code and the questions provided by students will have a significant impact on the quality of each class day.
Academic Integrity - The work you submit for this class should be of your own construction. You should feel free to confer with your fellow students or other people you might know about general questions dealing with the design of your programs or about specific syntactic problems. Having other people write code for you, or working from other people's code will be considered cheating and will carry repercussions as dictated by the student handbook. In general, the safest route when you have questions about assignments is to come talk to me. It should be said that this should in no way preclude you from studying the concept of computer programming with your follow students. Only discussions specific to the assignments are potentially risky.
Coding Practices - You are expected to follow certain coding practices for any code that you turn in as work in this course. In this sense I'm fairly lenient. I only require uniform indentation and reasonable documentation. I will not help you to debug any code that it not well indented. I don't care exactly how you decide to align brackets or put in white space (though some white space is helpful), but you have to be uniform, and all blocks of code should be indented beyond what the surrounding code had been.
Grades - The grade for this course will be composed of four components. These components and what they entail are discussed below. This table summarizes how each component contributes to your grade in the course. All items turned in for a grade in this course are to be pledged. For code, the pledge statement should be put in a comment at the top of the code.
| Component | Percentage |
| Projects (2) | 40% |
| Daily Code | 25% |
| Daily Questions | 20% |
| Language Presentation | 15% |
Projects - The biggest portion of your grade comes from two projects. These can be done individually or in small groups. You have significant flexibility in what you do for your project. It can be just about anything of the right scope. I will need to approve all ideas. I have listed a few possible suggestions below. For each project, there are two main things that you will turn in. The first is the code for the project so I can compile and run it. There will be one code base per group if people work in groups. In addition to the code, each person will give me a paper describing the code that focuses on the design and how the features of the language used played a significant role in the design and implementation. This paper should be on the order of five pages. People working in groups will each submit their own paper that details their contribution and how they felt the language features manifest themselves in significant ways in what they did.
Daily Code - As described above, the course itself will revolve around student written code and questions. The quality of the code that you bring in or your days will constitute a fraction of your grade in the course. Each student will have to present code one day each week and the code should deal with the assigned readings for that day. The ideal code sample with have sufficient length or interesting design to be worth talking about for several minutes.
Daily Questions - In addition to bringing in code once each week, every student is expected to bring two questions related to the reading every class day. These questions will provide the basis for our class discussions and a fraction of the student's grade will be determined by the quality of the questions they bring in.
Language Presentation - At the end of the semester we will talk about more experimental languages. These will be explored by students who will give presentations on them.
MUD - Short for Multi-User Dungeon. These were the WoW of old. They are text based RPGs that support multiple players.
Fractal Explorer (include various types of fractals)
2-D Game (possibly networked, not too simple)
Interpreted programming language and environment