One problem I had in preparing the curriculum for this fall is how to balance teaching programming languages versus the features that exist in programming languages. Some analogs to my course have generally been surveys of programming languages, for example - Michael Hewner's course. In such a course, study is focused strongly on learning a diverse set of languages, particularly pulling from logic and functional programming paradigms.
In general, the problem is that the each feature needs examples from programming languages to illustrate how it is used; however, many of these languages have never been previously taught to the students. Therefore, I could spend the first month teaching the basics of Ada, Fortran, Pascal, et cetera. But in doing this, essentially the class starts as a language class. I had considered this approach; however, the non-survey courses and the textbooks do not begin with the languages. These examples all begin with the features. Furthermore, I have taken the further approach to avoid focusing on specific syntax of languages and instead devote my time to teaching features and design.
Having then accepted that the textbooks had a purpose and were rational in design, I followed their structure. And in retrospect I can see that having upper-level students provides a base of knowledge about programming languages such that the need to cover specifics is avoided. I have still taken some class periods to delve into specific languages; however, this is the exception rather than a rule. I do note that in the future, I would spend some time teaching / requiring specific languages. Without this requirement, I have been faced with grading a myriad of languages and find myself unable to assign problems / questions based on specific languages.
Showing posts with label course design. Show all posts
Showing posts with label course design. Show all posts
Tuesday, December 1, 2015
Monday, August 17, 2015
Course Design Series (Post 2 of N): Choosing a Textbook
Having now read both Programming Language Pragmatics, Third Edition and Concepts of Programming Languages (11th Edition), I have settled on the former as my textbook for the fall. I do not find either book ideally suited, and I wish that the Fourth Edition was being released this summer and not in November, which is why it still hasn't arrived.
For the choice of which textbook to use, it was "Concepts" to lose and having 11 editions, the text should also be better revised. I dislike reading the examples in a book and questioning how the code would compile. Beyond which, the examples felt quaint and contrived.
(edit) For example, I was reviewing the material on F# and copied in an example from the text:
let rec factorial x =
if x <= 1 then 1
else n * factorial(n-1)
Does anyone else notice that the function parameter is x on the first two lines and n on the last?!
Before the Concepts book is written off entirely, there are many valuable aspects. I enjoyed reading about the history of programming languages, especially for exposing me to Plankalkül. The work also took a valuable track in the subject by regularly looking at the trade-offs between different designs and features. This point certainly helped inform my teaching of the material.
Fundamentally, when I looked at the price of the two textbooks, the benefits of using the newer Concepts textbook could not outweigh the nearly doubled pricetag. Most of the positive points are small things and can be covered as addendums to the material.
(FCC note - Concepts of Programming Languages was provided free to me by the publisher.)
For the choice of which textbook to use, it was "Concepts" to lose and having 11 editions, the text should also be better revised. I dislike reading the examples in a book and questioning how the code would compile. Beyond which, the examples felt quaint and contrived.
(edit) For example, I was reviewing the material on F# and copied in an example from the text:
let rec factorial x =
if x <= 1 then 1
else n * factorial(n-1)
Does anyone else notice that the function parameter is x on the first two lines and n on the last?!
Before the Concepts book is written off entirely, there are many valuable aspects. I enjoyed reading about the history of programming languages, especially for exposing me to Plankalkül. The work also took a valuable track in the subject by regularly looking at the trade-offs between different designs and features. This point certainly helped inform my teaching of the material.
Fundamentally, when I looked at the price of the two textbooks, the benefits of using the newer Concepts textbook could not outweigh the nearly doubled pricetag. Most of the positive points are small things and can be covered as addendums to the material.
(FCC note - Concepts of Programming Languages was provided free to me by the publisher.)
Wednesday, May 13, 2015
Course Design Series (Post 1 of N): Why Study Programming Languages
Obviously, there are some practitioners and researchers who base their living on programming language design. But what of the rest of us? The Communications of the ACM ran a short article on why: Teach foundational language principles. Language design is increasingly focused on programmer productivity and correctness. As programmers, are we aware of the new features and programming paradigms?
Particularly, let's look at three aspects of programming languages: contracts, functional languages, and type systems. By introducing each to budding programmers, we improve their habits, just as presently I include comments and other style components in project grades. First, contracts provide a well defined mechanism for specifying the requirements of each component in a system. Not just commenting each component and interface, but doing so in a manner that permits the compiler / runtime system to verify and enforce it.
Functional languages are well known, and whether or not you may ever use one, they teach valuable techniques and mental models regarding programming. A programmer should use pure and side-effect free procedures, rather than interleaving logic across different components. Other practices, such as unit testing, also trend toward clean interfaces; however, being forced to obey these rules via the underlying language is great practice.
Type systems are treated by the authors as a panacea, as they call for language designers to be "educated in the formal foundations of safe programming languages - type systems." Panacea or not, reasoning about functionality within the bounds of types leads to code that is clearer and more maintainable. Even in a weak language, such as C, one can use enums rather than everything being "int".
As these aspects are being increasingly used in various forms in current language design, programmers need to be knowledgeable of them in order to be effective and use the languages to their full potential. It is therefore incumbent on me, and other educators, to appropriately include these aspects when we teach about programming languages.
Which leads me back to writing a course description and learning objectives for my fall course. Maybe later this month once I figure out why one of the textbooks still hasn't arrived.
Particularly, let's look at three aspects of programming languages: contracts, functional languages, and type systems. By introducing each to budding programmers, we improve their habits, just as presently I include comments and other style components in project grades. First, contracts provide a well defined mechanism for specifying the requirements of each component in a system. Not just commenting each component and interface, but doing so in a manner that permits the compiler / runtime system to verify and enforce it.
Functional languages are well known, and whether or not you may ever use one, they teach valuable techniques and mental models regarding programming. A programmer should use pure and side-effect free procedures, rather than interleaving logic across different components. Other practices, such as unit testing, also trend toward clean interfaces; however, being forced to obey these rules via the underlying language is great practice.
Type systems are treated by the authors as a panacea, as they call for language designers to be "educated in the formal foundations of safe programming languages - type systems." Panacea or not, reasoning about functionality within the bounds of types leads to code that is clearer and more maintainable. Even in a weak language, such as C, one can use enums rather than everything being "int".
As these aspects are being increasingly used in various forms in current language design, programmers need to be knowledgeable of them in order to be effective and use the languages to their full potential. It is therefore incumbent on me, and other educators, to appropriately include these aspects when we teach about programming languages.
Which leads me back to writing a course description and learning objectives for my fall course. Maybe later this month once I figure out why one of the textbooks still hasn't arrived.
Thursday, April 2, 2015
Course Design Series (Post 0 of N): A New Course
This fall I will again be Instructor of Record. My appointment is to teach CS 4392 - Programming Languages. This is an unusual situation in that the course has not been taught for over 5 years (last time was Fall 2009). Effectively, the course will have to be designed afresh.
The first step in course design (following L. Dee Fink and McKeachie's Teaching Tips: Chapter 2) is to write the learning objectives using the course description, along with prerequisites and courses that require this one. Let's review what we have:
Course Description: none
Prerequisites:
Undergraduate Semester level CS 2340 (which has the following description)
Object-oriented programming methods for dealing with large programs. Focus on quality processes, effective debugging techniques, and testing to assure a quality product.
Courses depending on this: none
Alright. Now I will turn to the CS curriculum at Georgia Tech. Georgia Tech uses a concept they call "threads", which are sets of related courses. CS 4392 is specifically in the Systems and Architecture thread. This provides several related courses:
CS 4240 - Compilers, Interpreters, and Program Analyzers
Study of techniques for the design and implementation of compilers, interpreters, and program analyzers, with consideration of the particular characteristics of widely used programming languages.
CS 6241 - Compiler Design
Design and implementation of modern compilers, focusing upon optimization and code generation.
CS 6390 - Programming Languages
Design, structure, and goals of programming languages. Object-oriented, logic, functional, and traditional languages. Semantic models. Parallel programming languages.
Finally, the ACM has provided guidelines for the CS curriculum. Not only does this provide possible options for what material I should include, but they have also provided several ACM exemplar courses (c.f., http://www.cs.rochester.edu/
To summarize, if my first step is to write the learning objectives, then I am on step 0: write the course description. In a couple of weeks, I plan on finishing my initial review of potential textbooks as well as the other materials covered above. That will provide me the groundwork for the description and then objectives.
The first step in course design (following L. Dee Fink and McKeachie's Teaching Tips: Chapter 2) is to write the learning objectives using the course description, along with prerequisites and courses that require this one. Let's review what we have:
Course Description: none
Prerequisites:
Undergraduate Semester level CS 2340 (which has the following description)
Object-oriented programming methods for dealing with large programs. Focus on quality processes, effective debugging techniques, and testing to assure a quality product.
Courses depending on this: none
Alright. Now I will turn to the CS curriculum at Georgia Tech. Georgia Tech uses a concept they call "threads", which are sets of related courses. CS 4392 is specifically in the Systems and Architecture thread. This provides several related courses:
CS 4240 - Compilers, Interpreters, and Program Analyzers
Study of techniques for the design and implementation of compilers, interpreters, and program analyzers, with consideration of the particular characteristics of widely used programming languages.
CS 6241 - Compiler Design
Design and implementation of modern compilers, focusing upon optimization and code generation.
CS 6390 - Programming Languages
Design, structure, and goals of programming languages. Object-oriented, logic, functional, and traditional languages. Semantic models. Parallel programming languages.
Finally, the ACM has provided guidelines for the CS curriculum. Not only does this provide possible options for what material I should include, but they have also provided several ACM exemplar courses (c.f., http://www.cs.rochester.edu/
To summarize, if my first step is to write the learning objectives, then I am on step 0: write the course description. In a couple of weeks, I plan on finishing my initial review of potential textbooks as well as the other materials covered above. That will provide me the groundwork for the description and then objectives.
Subscribe to:
Posts (Atom)