| Introduction |
This lecture will overview four topics related to this course:
|
| Computer Labs and Software |
I expect that most students will use their own computers for programming
assignments.
You are encouraged to use your own computer for all aspects of the course that
it is capable of supporting.
You can download all the required course software to your personal computer for
free.
In addition to using their own machines, students can do their coursework on the machines in the ICS Labs. The main upside of using the ICS labs is that it will be easy to get ICS-33 staff to help you there. All labs are located in in the ICS building, in rooms 180, 189, 192, and 364. ICS courses often schedule lab hours (to complement lecture hours), during which students can learn how to use software tools and work on their programming assignments, all under the supervision of ICS staff members. We will have 4 hours of lab scheduled each week in ICS-33. All the machines in the ICS Labs run Windows 7 and are loaded with all the necessary course software: browsers, the Eclipse Integrated Development Environment (IDE), Python, and all the other course-related software. These labs provide a convenient space for students to work on their assignments where the course staff is available to answer questions immediately. |
| Human Resources |
Students start ICS-33 with a wide variety of aptitudes and skills.
At times, even the best students run into problems, misconceptions, mental
roadblocks, etc.
It is imperative that you quickly determine that you have a problem, and then
get it diagnosed and corrected as soon as possible.
There are many different resources that you can elect to use:
I will broadcast information to all the students (and staff) in ICS-33 using the ICS-33 Email List (ics33-S22@classes.uci.edu). All students and staff in the course will automatically receive emails sent to this address and all messages sent via this discussion list will be archived. Click Lecture A or Lecture B (depending on in which lecture you are enrolled) This information is easily reachable from the course web's index too. Most student-initiated questions/discussions should use the Ed Discussion threads mentioned above, but sometimes students can use this email list to inform the instructor, staff, and other students about some timely issue: e.g., Checkmate not responding to program submissions. Learning when and how to seek help from others is an important skill to acquire -one that you will use continually in your professional career. For example, if you encounter a programming problem that you cannot solve in 5 minutes (and see no further steps toward a solution), you should be able to explain the problem concisely (using all the programming terminology that you have learned) to someone else, and then understand and apply an informed answer, possibly collaborating to reach a solution. Instructors, TAs, and Lab Tutors all have experience handling such questions, and are trained to help students learn to become more self-sufficient -while still answering their questions: for example, we might tell you a general technique for solving a collection of similar problems instead of just telling you "the answer". Sometimes this process is a bit frustrating for students seeking help (especially if they started the assignment late and are caught in a time-bind), but ultimately this approach makes them better programmers. The appropriate homily is, "Give a person a fish and you feed them for a day; teach a person to fish and you feed them for life." Think seriously about using the human resources that UCI provides (which includes me, our TAs, and Lab Tutors, and your fellow students), just as you would think about using computational resources: the former resources are even more important than the latter. Knowing when (and how) to seek help is a strength, not a weakness. |
| Learning |
In this section I'd like to work from the general to the specific,
from education to programming, illustrated with various
Quotes
I have collected on my web page.
Let's start with three interesting quotes: the first from a graduate student
at the University of Washington, and the second from Jacob Bronowski, a
distinguished philosopher of science, the third from Edward Teller, a
physicist.
You have to decide why you are attending UCI. Your choice will have a lot to say about what you do in this class and others. Here is a simple question that makes it concrete: which of the following students would you rather be? Student 1 attends UCI, but on graduation day is informed that all records of the student's performance at UCI have been lost; in the future, UCI will acknowledge only that the student attended for four years and graduated with an ICS degree, but there are no more details to tell. Student 2 attends UCI, but on graduation day is hit on the head and develops amnesia; although UCI shows the student to have graduated with a 4.0 in CS, the student cannot remember any of the material learned through those four years. I enjoy teaching because I am constantly challenged by students to think more deeply about what I know and how I can teach it. Teaching as best as I can is my job; challenging what you hear -to better understand it and question my knowledge of the subject- is yours. Such challenges make me rethink and revise my opinions (more than you might imagine) and think about better ways of presenting and explaining complicated material. Everyone can excel in Computer Science at UCI: different students will gravitate torwards different parts of the field, but it is a big field -with many connections to applications in other disciplines- and there is room for everyone to be excellent at something. Many of you will be excellent at programming; some of you will be good at it, and that will be enough for you. But, everyone should acquire a basic understanding and basic skills in programming. Just as I question myself, a huge part of learning requires students to question themselves (and, as seen above, me as well). Learning is more about questions than answers, as the following quotes illustrate.
When the physics nobel-laureate I. Rabi was a child, his mother would always ask him at the dinner table not what he learned in his classes that day, but what interesting questions he asked. Neil Postman, a famous education, technology, and media critic tells the following story about the importance of asking the right question: Two priests were arguing about whether it was appropriate to pray and smoke at the same time. They each resolved to ask their bishop for guidance. When they met again, each claimed that the bishop supported his position! They went on to explore their interactions with the bishop in a bit more detail. The first said, "I asked the bishop whether it was appropriate to smoke while praying, and he said that praying is a transcendant activity that should not be debased by smoking." The second said, "I asked the bishop whether it was appropriate to pray while smoking, and he said that praying was appropriate any time."I know that students enrolled in this course have all already learned Python programming, but different students will have learned/retained different amounts. I urge everyone to use this quarter to attain a deeper, more integrated understanding of what they already know, as the following quote illustrates.
Of course, everyone will build on this material to learn more. Remember too, that teaching and learning are two different, but cooperative activities. I'll do my best to teach, but you need to do your best to learn as well.
Here is an old joke that illustrates this idea: One day a mother comes home from work and asks her son, "What did you do today?" The son replied, "I taught our dog how to play the piano." The mother, incredulous, asked, "Our dog can play the piano?", to which the son laughed and replied, "Of course not mom. I said that I taught him; I didn't say that he learned how."Finally, don't be afraid to "struggle" and "fail"; if learning were simple and effortless, we'd all be a lot smarter.
Unfortunately, the K-12 educational world that we live in doesn't encourages students to try (at really hard things) and fail. Everyone wants to make sure they never fail. This attitude is bad in many dimensions. College is a safe place to try hard and fail (and succeed eventually too); mistakes are failures only if you don't learn from them. |
| Programming |
Finally, let's talk about programming and programming languages.
Most of the quotes below are lengthy, and come from emminent computer
scientists (or just fantastic programmers) who are trying to communicate
what programming is about and why it is so fascinating to them.
Now, I like to focus on aesthetics, because at some level, the root of learning in all disciplines is learning their aesthetics: learning to separate the beautiful from the ugly. Central to this discussion is the dichotomy between complexity and simplicity in programming. As is illustrated many times below, what makes programming hard is complexity in the tools used and complexity of the final product: it is too easy to create overly complicated designs and implementations (which inevitably are incorrect). We must strive to keep everything simple: this is where creativity in programming lies. Programming is one of many human activities in which simplicity and beauty are bound tightly.
I'd like to present the following quote last; it will provide an import perpective for many of our discussions about features in the Python language. It fully recognizes the psychological aspect of programming and is directly related to the complexity of the tools that we use when we build complex artifacts.
|
| System Costs |
In the early days, computers were built by hand, which made them expensive.
They were physcially large, consumed huge amount of power, were slow, and their
memories were small; so they could run only small programs.
As a result, the cost of developing a working computing system was mostly spent
on hardware.
At present, computers are cheaply mass produced: they are small, consume minimal power, are fast, and have large memories. Now, the cost of developing a working computing system is mostly spent on software. To deliver new systems cheaply and on time, we must focus on improving the production of software. When implementing a computer system, a 5% improvement in developing software is worth about as much as a 50% improvement in developing hardware (because these latter costs are so minimal to start with). |
|
In his Turing Award lecture, "The Humble Programmer", Edgser Dijkstra (a famous
Computer Scientist) put it as follows:
"As long as there were no machines, programming was no problem at all;
when we had a few weak computers, programming became a mild problem,
and now [1972] that we have gigantic computers, programming has become a
gigantic problem.
...As the power of available machines grew by a factor of more than a
thousand, society's ambition to apply these new machines grew in proportion,
and it was the poor programmer who found his job in this exploded field of
tension between the ends and the means.
The increased power of the hardware, together with the perhaps more dramatic
increase in its reliability, made solutions feasible that the programmer had
not dared to dream about a few years before.
And now, a few years later, he had to dream about them and even worse,
he had to transform such dreams into reality! It is no wonder that we found
ourselves in a software crisis."
In fact, Moore's "Law" (empirical) states that computer/communication hardware doubles in performance (speed, memory) and halves in resources (size, cost) about every 18 months. This exponential law has held for the past 30 years of computing, which has seen changes in computing technology by a factor of a million. PCs today perform a billion operations per second; if Moore's Law continues to hold for another 40 years, PCs will be performing a thousand trillion operations per second (about as many as the human brain performs; with many more logical elements, each operating at a much slower -than electronic- speed). |
| A Software Development Model | Over the last 30 years the following model, called the Iterated Waterfall model, has proven itself an important one, for developing large software systems (direclty applying it to smaller projects is a bit cumbersome, but it is often applied in a modified way). Each higher phase must finish before a lower phase begins (like water falling), but there are opportunities to return to earlier phases: a problem at a later phase may back up to an earlier one; and all phases can be reached again (iterated) during maintenance. A more recent software methodology (better adapted for smaller projects that require fewer programmers) is called Extreme Programming. It shares the idea of incremental development with the iterated waterfall model, but reaches these objectives a bit differently. |
In fact, maintenance is a curious term to appply to software, because
unlike cars, for example,
|
| Relative Costs to Fix Errors | Review the Iterated Waterfall model of software development. The following chart shows the cost to fix an error, depending on when the error was discoved during this process. Notice that the sooner an error is discovered, the less expensive it is to fix. |
| When we write Python programs, we will learn about language features that allow us to detect errors more quickly (and thus, fix them earlier and save our time, which is the biggest cost of taking this course) |
| Software Lifetime Costs | We have learned that reliably working software continues to be used a long time. Therefore, the following charts should come as no surprise (although it typically does). |
| The upshot of this chart is that software must be built initially in such a way that it is easy to maintain, because over the lifetime of a product, maintenance costs dominate. One easy way to remember this chart is that the maintenance cost looks like a Pac-Man icon, gobbling up the initial cost to build. |
| Software Project Sizes |
Although we will write only small software systems in this course, we should
still keep the construction of large software systems in mind.
As we have seen in industry, often small software systems grow into large ones.
Software project sizes are roughly categorized as follows (where K means 1,000
lines of code and M means 1 million lines of code)
Writing a very large software project is like building a skyscraper, in terms of workforce, cost, and timetable. But, it is notoriously difficult to predict software costs and schedules, compared to the building trades. While most construction jobs can be estimated within 10% of time and budget, software jobs are lucky to be estimated with 300%. Something like 60% of all software projects fail to be completed or deployed. -many $100 million projects are abandoned, with no usable product produced. This is known as the software crisis, which many attribute to the relative newness of programming as a discipline (<60 years; civil engineering is thousands of years old); others say that the difference between two large programs is much greater than the difference between two large buildings, which is why constructing programs is harder than constructing buildings; still others ponder the nature of digital systems and the ability for small mistakes to cause large problems. The area of Software Engineering is young, but quickly growing and maturing as software finds its way into everything that we produce. |
| Software Project Metrics |
Although software projects scale many magnitudes in sizes (the ones shown below
are medium to huge), worker productivit rates fall into a much smaller range.
The following data came from an article, "How to Break the Software Logjam"
from Fortune magazine, Sept. 25, 1989 (pages 100-112).
Note that Code Lines/Month is a bad metric to measure programmer productivity. This is because a poor programmer may quickly produce many lines to do a simple task; while a good programmer will carefully write fewer lines of code to accomplish the same task, often producing simpler and easier to modify code, reproducing the same functionality in fewer lines of code. Here are two relevant quotes from my homepage (there are lots of other interesting and relevant quotes there).
But Code Lines is a good metric to measure maintenance cost (which we have seen overshadows by a large fact the original cost to build software). So, the cost of maintaining a program is roughly proportional to its size. This leads to an interesting anomoly: A programmer may exhibit what appears to be negative productivity by working to shrink the size of a program; but, the result is reduced maintanence cost over the lifetime of the software. |
| Problem Set |
Mastering programming starts with mastering the syntax (form) and semantics
(meaning) of a programming language.
Before we begin our study of computer languages, we can investigate these
topics in a natural language.
Although these are not questions about programming, answering them requires
thinking like a programmer.
|