CS 410 Mastery in Programming Chapter 1 “Good Programming Practice”

1. Herbert G. Mayer, PSU CS status 6/27/2011 CS 410Mastery in ProgrammingChapter 1“Good Programming Practice”

2. Syllabus • Programming Practice • Measuring Master Programmers • Are You a Master 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 • Creative ideas • Open to others’ ideas • Humble , according to Dijkstra [1] • Practices and masters 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, new level • Designs, implements cooperatively –real jobs not solvable by 1 engineer, except Linus Torvalds

4. Good Judgment comes from Experience,andExperience comes from Bad Judgment

5. Measuring Master Programmers • Certain professions have: • Learning programs, specific training courses • Studies to master skills, techniques, e.g. architect, MD • Proficiency tests; e.g. bar exams • Documented practices • Medical Science, for example: • Educates specialists in narrow fields, that others do not practice as well as the specialist • Includes certification processes; plaques prominently posted at wall  • Some fields offer formal accreditation; e.g. educational institutions like PSU • Situation for programmers or Software Engineers? • Not much formal certification, except BS and MS degrees

6. Are You a Master Programmer? • Like the others? • Typically young programmers view themselves to be super-programmers • I speak from past experience  • Some very experienced programmers think “they are exceptional” • Are they, are you, Master Programmer[s]? • Prove it! That you are a master! • First prove it to yourself! Not like “talking oneself into lots of self esteem”  as practiced in some High-Schools! • Prove mastery by analyzing your own programs; compare with serious SW designed by others • Are your works complex, simple, long, short, readable, obfuscated, maintainable ..? Other metrics? • What is program complexity? Language complexity? • What is, and how can one prove, software correctness?

7. 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? Why don’t we see & touch it?

8. Software Complexity • Other complexity measures we know: Chomsky language classifications: • FSA, deterministic, nondeterministic • Context-free • Push-down automaton • Recursive (complexity! Not programming language feature!) • Recursively enumerable • I.e. from easy to complex • See later lecture on language complexity, program complexity

9. Interesting Experiences • Literally re-typed 1 page (~50 line) of SWL (Pascal-like) code to render SW functional; mystery never solved • 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 of Ada compiler • 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 one’s own SW; but to check instead! (Catch your assumptions! Best to make none/few)

10. Interesting Experiences • Student Discussions: • Have you had strange, unusual programming experiences?

11. What Can Be Programmed? • Algorithms; see [2] • Church Thesis [6] • Yet some problems remain very hard to solve programmatically

12. What Cannot be Programmed? • Code to become a better person? • There is no methodical (i.e. algorithmic) way • Yet there may be ways  • Design SW to win lottery? • Only if unbounded time and all permutations allowed! • 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 could 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 • Optimal Software

13. 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” • 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

14. 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 any one typo!

15. Defensive Programming • Don’t trust your interface • 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 • 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 • Today your SW works perfectly for the given specification • Tomorrow it shall change, and you need to adopt your SW to modified requirements: Write maintainable SW

16. 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