8612700302

Logika: Programming Logics

i. Introduction: Why bother?

That’s a good ąuestion! After all, you can hack a spreadsheet program or build an interactive gamę by writing a lot of codę, experimenting with it, and patching it. After awhile, the program you wrote does morę or less what you wanted.

But imagine if the rest of the world worked that same way - would you want to drive a car or fly an airplane that was “hacked together”? How about travelling in a bus across a bridge that fell down a few times already and was repeatedly patched till it (seemed) to hołd?

Perhaps these analogies are a bit extreme, but professional scientists and engineers rely on planning, design, and calculation so that they are certain the products they want to build will work before anyone starts building them. Professionals rely on an intellectual foundation to plan, design, and calculate. For example:

•    physicists use mathematics as the intellectual foundation of their products

•    Chemical engineers use chemistry

•    mechanical engineers use physics

•    Computer engineers and Computer (software) scientists use algebra and symbolic logie

If you develop significant expertise in software engineering, perhaps you will work at a firm or lab that develops safety-cńtical software, that is, software upon which people’s money or safety or lives depend. (An example is the flight-control software that lives in the nose of a jet and flies it. Another example is the navigation software in a satellite that talks to the GPS device in someone’s car.) Software of this naturę has to be working correctly from the beginning - therc is no freedom to hack-and-patch the codę once it is in use. Software engineers must use algebra and logie to plan and calculate how the software will bchave before the software is built and installed.

This story is not an idle one: As you probably know, Computer proccssor chips are planned out in a programming language that looks a lot like C. When Intel designed its first Pentium chip, there was a programming error in one of the chip s coded hash tables. The coding was burned into hardware, and millions of chips were manufactured. The error was ąuickly dctectcd - the chip did not always perform multiplication correctly. As a rcsult, Intel lost a lot of money rccalling the faulty chips and manufacturing a patched replaccment. These days, Intel uses techniąues for validating chip designs much like the one you will leam in this course.

If you have taken a software architecturc course (e.g., CIS 501: Software Architccture and Design), you know that large systems can be drawn out, or “blueprinted," with diagrams that show the components and how they connect together by means of method calls, evcnt broadcast, and message passing. What we will learn in this course is lower level and morę basie -we will leam how to calculate how the lines of coding in each component compute internal knowiedge as they convert inputs into outputs.