CS 201 Computer Systems Programming Chapter 5 “ System Programmer Skills ”

1. Herbert G. Mayer, PSU CS Status 10/8/2012 CS 201Computer Systems ProgrammingChapter 5“System Programmer Skills”

2. Syllabus • Programming Practice • System Programmer • Software Development Practices • Software Complexity • Interesting Experiences • What Can Be Programmed? • What Cannot Be Programmed? • Algorithm • Defensive Programming • References

3. Programming Practice • General programmer attributes: • Critical thinker, uses good judgment; what’s new?  • Creative ideas, about computing • Open to others’ ideas • Humble , according to E. Dijkstra [1] • Practicing and mastering a craft: • Programmer reads, analyzes, improves programs • Designs programs, i.e. SW solutions to computable problems • Practices, reviews, corrects, refines programming process • Experience and high skill: • Knows how to design, implement, document, test, validate, improve, maintain, judge complex software • Mastery: • Advances state of the art of SW development to higher level • Designs, implements cooperatively –real jobs are not solvable by 1 engineer, except if you are Linus Torvalds designing Linux 

4. System Programmer • An effective system programmer is an experienced SW engineer, who masters a suitable programming language L very well • Such a language L allows visibility of, access to, low-level target machine and to OS resources • Possible languages L are C, C++, assembler • Knows target machine thoroughly • Understands which operating system calls can be expressed in L to manage system resources • Can combine system calls to low-level machine from L, with overall goal of effective machine use

5. Good Judgment comes from Experience,andExperience comes from Bad Judgment provided that you are smart, since: only a CS genius learns from the mistakes from others; the smart CS student learns from her own mistakes; a dumb person –not studying CS  -- never learns and repeats errors;

6. Software Development Practices • Software of real value should be: • Functional • Correct • Reliable • Efficient • Easily readable, see C. A. R. Hoare [4] • Re-Usable • Extendible, AKA open-ended • Maintainable • Complete; exceptions are documented clearly! • Does such SW exist? Then why don’t we see & touch it all the time? Ever touch an OS that locks up, freezes, slows down excessively? It is called Windows 

7. Software Complexity • Common complexity measures: Chomsky language classifications, after Noam Chomsky: • FSA, deterministic, nondeterministic • Context-free • Push-down automaton • Recursive (Not the prog language feature!) • Recursively enumerable • Listed from easy to complex • See later lecture on language complexity, program complexity

8. Interesting Experiences - Herb • I literally re-typed one page (~50 lines) of Pascal-like code to finally render SW functional; mystery never solved why the re-typed, identical program worked • Designed and coded some days and nights w. almost no sleep and food, and crafted ~2,000 lines of highly functional C++ code for Case Statement and other structured statements for Ada compiler; worked! • SDSU colleague left 1 page of pseudo-code for Symbolic Differentiation on a department copy machine intuitively great, comprehensible, beautiful; stolen with pride; you will see it! • Positive feedback about almost religious credo to: not trust your own SW; but to check instead! (Catch your assumptions! Best to make few assumptions)

9. What Can Be Programmed? • Algorithms; see [2] • Guideline for what can be programmed: Church Thesis [6]: “any algorithmically computable function can be programmed and executed on a regular computer.” I.e. you can express it as a C++ program  • What is “Computable? • see Alonzo Church’s Lambda Calculus • or Alan Turing’s hypothetical “Turing Machine” • Yet some problems remain very hard to solve programmatically, even though they are computable

10. What Cannot be Programmed? • Code to become a a perfect System Programmer? • There is no methodical, algorithmic way • But there are ways  Don’t give up! It includes learning, practicing, thinking • Design SW to win lottery? • Unless unbounded time and all permutations allowed! Then you lose money • Natural language translator? • Yes, very aware of automated translation tools! And I use them! Like Babel Fish, Google translators, etc. • If it were possible, how then could the typical human ambiguities be avoided? • Decryption of any encrypted code? • May require too much time to render result interesting • Hence some states impose limitations on encryption complexity (128 bits) • Medical diagnosis • Yet great steps achieved to automate some diagnostic steps • Mainly to save time; final diagnosis generally left to MD • Judicial judgment • Oregon DMV services!

11. Algorithm, see [2] • Markov (1954) • Algorithm is … an exact prescription, defining a computational process, leading from various initial data to the desired result • Minsky (1967) • Algorithm is a synonym for “effective procedure” • Donald Knuth (1968) • A precisely defined sequence of finite steps to compute a result from given inputs and initial values –paraphrased by HGM  • Stone (1972) • Algorithm is a set of rules that precisely defines a sequence of operations such that each rule is effective and definite and that the sequence terminates in (very) finite time • Berlinsky (2000) • Algorithm is a finite procedure, written in a fixed symbolic vocabulary, governed by precise instructions, moving in discrete steps, 1, 2, 3, . . ., whose execution requires no insight, cleverness, intuition, intelligence, or perspicuity, and that sooner or later comes to an end

12. Defensive Programming • Automation • Some aspects of programming can be automated • Many web interfaces to users/customers are automated, some are mainly clerical • How many times did you have to retype correct web-page information because 1 item further down was misspelled? • Learning: simple things can be automated, but even for those: Use good programming principles, consistency, documentation, common sense • Focus • Programming the remaining portion, the hard problems, is a challenge • So automate what can and should be, and “manually” program the rest • See Richard Sites, main designer of Alpha processor [5]: “I rather write programs that write programs than write programs!” • Future • Programmers will have great job security for some time to come • But like in all professions: The good ones will be in demand to craft new works; others write web interfaces that clear out  after 1 typo!

13. Defensive Programming • Don’t trust your interface; verify even if it seems redundant • The defined interface dictates your SW inputs, and specifies the output your SW is to generate • Verify the accuracy of input, even your own • Generate messages where applicable and beneficial • May not work for embedded SW, space mission 200 Mio miles from home; but appropriate default action may be meaningful • Don’t trust yourself; check instead • Your “other” SW may generate your other inputs • And even you may make errors: check, verify, report, mistrust • Make “reports” of suspicious logic conditional, via #ifdef or similar mechanism • Don’t be complacent; consider future enhancements • Today your SW works perfectly for the given specification • Tomorrow the specification will change, and you need to adapt your SW to modified requirements: Write maintainable SW

14. References • The Humble Programmer: http://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html • Algorithm Definitions: http://en.wikipedia.org/wiki/Algorithm_characterizations • Solvability: http://www.cs.nott.ac.uk/~nxk/TEACHING/G53COM/G53COMLecture8.pdf • C. A. R. Hoare’s comment on readability: http://www.eecs.berkeley.edu/~necula/cs263/handouts/hoarehints.pdf • Dr Richard Sites’ phrase even on sweatshirt: http://www.cafepress.com/+id_rather_write_programs_hooded_sweatshirt,63975143 • Church-Turing Thesis: http://plato.stanford.edu/entries/church-turing/ • Linux design: http://www.livinginternet.com/i/iw_unix_gnulinux.htm • Words of wisdom: http://www.cs.yale.edu/quotes.html