Object code the binary form machine language the cpu

Distance Learning

Master of Science in Computer Science

Copyright © 1997 Gary Locklair & Concordia University Wisconsin. No part of this document may be reproduced, transmitted, or stored via mechanical, electronic and/or magnetic means without the expressed written permission of Gary Locklair and Concordia University Wisconsin.
0397

Introduction

Each course incorporates the Christian worldview of CUW. Today, employers are demanding that computer scientists understand ethical and moral implications of computing and information processing. The masters of computer science at CUW integrates ethics into each course.

A unique aspect of CUW's masters degree is the first course, MCS 810. MCS 810 is a broad survey of topics in the computing sciences meant to provide a foundation of the rest of the curriculum. Students have the opportunity to decide what aspects of computer science they will emphasize in the program, and prepare their program accordingly.

Course Purpose

MCS 835 is meant to ensure that you, the student, have the necessary foundation for understanding programming languages. A programming language is currently the vehicle for communicating an algorithm to a computer. Effective problem-solving requires that the practitioner understands the conceptual foundations of programming languages.

Finally this course does not treat computer science as a sterile discipline but seeks to provide a personality for it by demonstrating how a worldview influences the application of the tool and the development of the field.

Course Objectives

• understand human creativity by investigating a variety of programming models developed in specific problem domains

• analyze the current state-of-the-art in programming languages

• appreciate the beauty of various language paradigms

• explain the essence and nature of programming languages

Requirements and Bibliography

Required Texts:

Optional Texts:

Tucker, Alan, ed, The Computer Science and Engineering Handbook, Boca Raton, FL: CRC Press, 1996

IEEE (Institute of Electrical and Electronics Engineers) Computer ISSN 0018-9162

Dr. Dobb’s Journal ISSN 0077-9019

Word processing software (Microsoft Word preferred)

Programming language environments
(you must have one interpreter/compiler in each of the following areas)

Letter grades will not be issued for individual assignments or the final exam; instead, point scores will be provided. Each assignment is worth a specified number of points. When graded, a point score will be returned indicating the number of points obtained out of the total possible (eg, 37 out of 40). The resulting percentage can be used to determine a letter grade.

There are 345 total, possible points in MCS 835.

If you have not completed all requirements for this course after 12 weeks, a grade of I (Incomplete) will be issued. If, at the end of 25 weeks, you have not completed all requirements for this course, the I will be changed to F.

Logistics

On average, 10 weeks are required to complete this module. The exact time frame for the completion of this module will be contracted between the student and the instructor and may be modified during the course of the module.

The Framework

Since this is an independent program, feel free to offer "alternative" assignments for any of those specified within this module. Although your instructor is under no obligation to modify the suggested learning exercises, your instructor may take your suggestions under consideration and use or modify them for your own personal objectives.

Units of the Course and Assignments

0. Assemble all necessary resources and equipment, noting any questions or concerns (to be addressed in assignment 1).

1. Read this entire module, noting any questions or concerns. Read the table of contents of all required texts and skim each book quickly (15-30 minutes per book). Call your instructor and discuss the following: a) any questions or concerns about the resources or course, b) any options you might propose, and c) expectations of the course and a schedule for assignment completion. {Assignment 1 – 5 points}

Maximum length of document: 2 pages. {Assignment 5 – 10 points}

Unit II Programming Structures

2. Answer discussion question 3 and exercises 1c, 1f, 2d, and 10 at the end of chapter 2.

Submit the five answers together. {Assignment 6 – 25 points}

5. Answer discussion question 1 and exercises 1 and 2 at the end of chapter 5.

Submit the three answers together. {Assignment 9 – 15 points}

This unit will allow further analysis of programming language concepts by synthesizing solutions using various programming languages and paradigms.

B. Learning Activities

3. Thoroughly read chapters 9 and 10 in Programming Languages.

4. Using any functional language (eg, Scheme), solve Laboratory Exercise 1 at the end of chapter 10.

Follow professional programming practice. Submit both source and object code. {Assignment 12 – 25 points}

7. Thoroughly read chapters 14, 15 and 16 in Programming Languages.

8. Using any object-oriented language (eg, Java), solve Laboratory Exercise 1 at the end of chapter 16.

Follow professional programming practice. Submit both source and object code. {Assignment 14 – 25 points}

1. Consult with your instructor regarding a “mini-project” for this module. The project should focus on a key area of language design, implementation or application.

Examples: a. Research the question, “Are there general guidelines which could allow a programmer to choose the ‘proper’ language paradigm based upon the problem at hand?”
b. Create an introductory tutorial for the Java language.
c. Using Prolog, create an application to suggest solutions to the “traveling salesperson” problem.

{Assignment 15 – 35 points}

2. Create a document which answers this question: “How do worldviews and ethics relate to programming languages?” Discuss both issues and illustrate with examples.

Maximum length of document: 5 pages. {Assignment 16 – 25 points}

Backhouse, Roland, Syntax of Programming Languages: Theory and Practice, Englewood Cliffs, NJ: Prentice-Hall, 1979
deep analysis of syntactical issues

Bergin, T. J. and R. G. Gibson, History of Programming Languages, New York, NY: ACM Press, 1996
definitive historical survey of programming languages

Glass, Robert, Software Folklore, State College, PA: Computing Trends, 1991
recent historical anecdotes

Harel, David, Algorithmics: The Spirit of Computing, Reading, MA: Addison-Wesley, 1992
survey of algorithmic concepts

Lammers, Susan, Programmers at Work, Redmond, WA: Microsoft Press, 1986
interviews and insights into the world of programmers

LaPlante, Phillip, Great Papers in Computer Science, St. Paul, MN: West, 1996
section 2 contains 6 classic articles

Your Instructor

Gary Locklair is Assistant Professor of Computer Science and Chair of Graduate Computer Science at Concordia University Wisconsin where he has taught since 1986. Prior to coming to Concordia, he worked in the computer industry for 10 years. Three years were spent as a programming/analyst with the California Department of Transportation performing numerical analysis and scientific visualization. Seven years were spent working for 5 different divisions of the Hewlett-Packard company (in three states) performing duties ranging from creating systems software to software quality assurance to program management. His most memorable job was being custom font program manager for the very successful LaserJet line of printers.

Gary holds degrees from California State University, Sacramento (2) and from the University of Idaho. He has done additional graduate work at Oregon State University, the University of Wisconsin, Milwaukee, and is currently a student at Nova Southeastern University. He is a member of Upsilon Pi Epsilon (computer science honor society) and the IEEE and ACM.

Gary, his wife Karen, and their five children reside in Milwaukee, Wisconsin. Being a full-time graduate student while holding a full-time job leaves him no time for hobbies; however, if he had time, he would list photography and automobiles among his interests. He is actively involved in the field of Cosmogony (science of origins) as a researcher and teacher.

"My goal is to help ensure your success in this program. I know what it's like being a graduate student in a distance-learning program, so hopefully I have developed some empathy for your situation!"

Professional writers follow style manuals or guides to aid them in producing clear and effective materials. Sometimes programmers mistakenly assume that their source code does not need to conform to any particular style since it is intended for use by a dumb CPU. This is incorrect! CPUs don't understand source code such as C or Pascal; they can only execute ("understand") object code. Object code is the binary form machine language of the CPU. High level languages such as C or Pascal were created for ... people! Since source code is designed to be understood by people, it makes sense to apply some professional style guidelines to any source code that is created.

To be useful, source code must be read and understood by other people. Production programs are never static; they are changing all the time. A programmer may need to modify, enhance or debug a program. Following guidelines when writing the source code will make someone else's life easier when they have to read the code later. (Note: you may be the person who has to read it later too!)

This comment is stupid - remember another programmer will be reading your code and s/he can tell what a WRITELN is doing! Every procedure, including the main, should have a block of comments describing its purpose, I/O mechanism, and assumptions. Every major data structure should be commented. Every control structure (loops, decisions) should be commented. Any "tricks" or non-obvious code should be commented.

Illuminate the Structure The control structures used should be highlighted by proper indentation and the use of blank lines. Blocks of code (eg, compound statements in Pascal) should be indented evenly underneath repetition, selection, or procedure control structures. Use blank lines to separate logical groupings of code.