A computer science course is not just about learning how to program. The catalog description emphasizes the technical aspects of writing programs but doesn't mention general principles. Although much of the course will be devoted to programming, I will address those CS principles that you should be able to comprehend. Programming and CS principles are not mutually exclusive. You must have some understanding of basic computing principles in order to program. Similarly,through the continued practice of programming, the basic principles of computing become clearer.
For those of you who will be programming in additional courses and in life, understanding the principles of CS will help you to be a better programmer. For you, Java will definitely not be the only computer language you will use. If you've paid attention to the deeper issues, learning other programming languages will be a relative cake-walk.
If this course will be your only computing course, it will probably be more important to understand the principles of CS rather than remembering how to write a program. Nowadays, nearly every profession will require you to interact with programmers & information/computer scientists. If you have a basic understanding of the principles, you'll be better able to communicate with CS/IS professionals. For example, although remembering how to write a loop may initially help to communicate, you'll find that CS professionals consider this skill to be second nature. There is no continued depth of complexity in writing loops. However, if you remember (say) the process of the software development cycle, you'll be able to better interact with (and understand) CS professionals.
The following sections of this web page will introduce you to some of the CS principles that I will address during the semester:
Understanding how programming languages workCommunications ("style")
Design
Miscellaneous Principles
Understanding how a Programming Language Works
In class, and on my web pages, I will discuss programming in both a conceptual and practical manner. My goal is for you to learn the general principles of programming while learning to program in Java. Some instructors focus on Java "syntax". Of course, syntax is needed to make a programming language work but almost all programming languages have the same syntactic topics.
This is my list of basic syntactic categories for an introductory programming course (in any language). The terminology is not necessarily that of Java. In fact, I've made an effort to disassociate the underlying syntactic topics from Java syntax. Every programming language will have its syntax for addressing every one of these issues.
However, there are other categories of programming languages; Java is an example of an imperative programming language and most of the "popular" languages are also imperative. The primary alternative form of a programming language is a functional programming language (Lisp and Scheme are the best known examples).
About computer science principles
Most principles associated with computer science come from either a theoretical (i.e., academic) base or as a reaction to practical concerns that programming professionals face on a regular basis. Most of the theoretical ideas of computing will be addressed in future CS courses. Students with a higher scientific or engineering interest will probably end up enjoying later CS courses more. The science of computing is minimally associated with programming (which is only a skill).
In 15-100, however, I will focus on principles that derive from practical considerations that have some demonstrable relevence in programming.
The usefulness of many of these practical principles may only be fully evident if you imagine yourself as a professional programmer. A professional programmer will likely spend weeks (or years) solving large-scale problems as part of a group of many individuals. The big problem facing programming professionals is in how to deal with problems/programs that are larger than anything a single individual can fathom or understand in detail. The purpose of software engineering is to address this issue. However, in a college course, you're only asked to solve problems that instructors think you'll be capable of completing; consequently, it is difficult to appreciate how the size of real problems affect the process for designing solutions. Further, you'll likely spend only a few days in solving a particular problem and then never return to it again. All of these things run counter to how programming works in the real world.
Although you may not appreciate this immediately, I will be imposing penalties on your programs when they don't address the practical concerns listed below. Early on, penalties won't be severe. As the semester progresses, I will expect stronger adherence to programming practices. Forgetting the most basic practices will incur the harshest penalties; penalties for newly discussed practices won't be as severe.
The root problem with many existing programs is a lack of communication about the purpose or workings of the program. In the real world, you'll most often be writing programs that
a) will be used repeatedly by others; andIf you do not communicate how your program should be used, it will be difficult for others to use your program. If you cannot communicate the methodology behind your program, it will be difficult for others to change your program. In a large-scale setting, failing in either form of communication could be disastrous. To put this closer to home, suppose that you are a person that has to use someone else's program or that you have to update some other person's code. Alternatively, try to think about trying to update a program that you wrote six months (or six years) ago.
b) will be later be changed by others
The keys to better communication in programming are often described as a programming "style". If you utilize "good" style guidelines when writing programs, you can better communicate how the program is intended to be used. Adhering to good style guidelines makes it easier for others to understand your program and, therefore, modify your program if need be.
In the past, there was no single agreed-upon style to which everyone must conform. The Java language has proposed style guidelines. In the real world, many organizations have their own "programming style guides"; for example, the programming style guide for the Air Force is over 50 pages long.
Initially, these are the only communications/style issues to which I want you to adhere:
As the semester progresses, there will be other style issues to which you will need to conform.include useful comments that explain what your program does give descriptive names to constants, objects, methods, and variables keep the indentation format clear and consistent
Consider a contruction company. The hourly employees don't just slap together a building. They utilize an architect's design to tell them what has to be done. The architectural design defines a methodology for the worker's actions.
Designing a solution to a programming problem is the problem-solving process of computer science. In this regard, it is similar to mathematics -- it is harder to solve a word problem in a math class than to solve an abstract equation. However, creating a good design means you'll spend less time writing (and modifying) code since the major issues in solving the problem have been well thought-out and addressed before any coding begins. In large-scale software engineering projects, nearly half of the project time-line is devoted to issues of design. The basic idea behind programming design is to abstractly break down a complex problem into a larger group of smaller problems that are, individually, relatively easy to solve.
Still, design is somewhat of an art -- I'm constantly learning better ways to put together programs. If I've worked out the design for a project ahead of time, then writing the actual code is much simpler. Using Art as an analogy, coding is like applying brush strokes to a painting (a technique); while design involves the higher purpose of the painting. As such, it is also more difficult to assess the quality of design ("I know art (a good design) when I see it").
There are a few "truisms" regarding the relationship between design and code. Although these statements don't explain how to do design, they should indicate whether your design is reasonable. Not all of these items may make complete sense to you at this early point in the course:
In larger projects, the design is part of the documentation. Design documentation minimally includes diagrams and text explanations but it may even extend futher. Design documentation is important for a variety of reasons but it is easiest to understand when considering program maintainers (see below). In my experience on large projects, I have actually spent more time on design documents than on documenting code.
For 15-100 students, I don't expect detailed documentation of your design. However, writing a design for solving a project is similar to writing an outline for a paper. This analogy extends to what might happen when you ask for assistance on a project. Without a design, I (or a CS tutor) will not help you with details; instead, just like a literature professor (or tutor), I'll try to make you focus on the basic design issues that are important. With a reasonable design, I (or a CS tutor) will help you with more specific details.
I don't expect you to have strong design skills
and I've attempted to design projects which will gradually step up in design
complexity. For the initial projects, writing a design will be close to
writing an outline (a skill with which I assume, as do lit profs, you are
relatively familiar).
Other CS Programming Principles
There are other concepts important to computer science that I will also introduce in this course. Since these topics are not things that you need to think about at the beginning of the course, I'll just provide an outline.
In 15-100, we'll see some simple examples
of how to make certain parts of our programs more robust. Although addressing
robustness is generally straightforward, making any program robust requires
a lot of code (which isn't that different from one program to the next).
I will ask you to make at least one of your projects robust.
After mid-semester, we'll look at a few problems
(e.g., searching and sorting) that have both efficient and slower algorithms.
In 15-100, we'll look at the following debugging
issues
I no longer try to require you to understand
the simpler validation techniques; however, I will address invariants
(the simplest validity concept) to help you better to understand how to
write a correct loop.