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

1. Herbert G. Mayer, PSU CS Status 6/25/2013 CS 410 / 510Mastery in ProgrammingChapter 1“Good Programming Practice”

2. Syllabus • Programming Practice • Measuring Master Programmers • Are You a Master Programmer? • Software Development Practices • Software Complexity • Interesting Personal 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 • 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’ Linux design 

4. Good Judgment comes from Experience,andExperience comes from Bad Judgment(provided one is smart)

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 MS, PhD 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 indeed a master! • First prove it to yourself! No “talking oneself into lots of self esteem” as practiced in some High-Schools! • Prove mastery by analysing 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 or demonstrate software correctness?

7. Software Development Practices • Software with true value should be: • Functional • Correct • Reliable • Efficient • Easily readable, see C. A. R. Hoare [4] • Re-Usable • Extensible, 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?

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

9. Interesting Personal Experiences • I literally re-typed one page (~50 lines) of Pascal-like code to finally render SW functional; mystery never solved why the re-typed 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 one’s own SW; but to check instead! (Catch your assumptions! Best to make few assumptions)

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

11. What Can Be Programmed? • Algorithms; see [2] • Guideline for what can be programmed is the 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

12. What Cannot be Programmed? • Code to become a better person? • There is no methodical (i.e. algorithmic) way • Yet there may be ways  Don’t give up! • Design SW to win lottery? • Unless 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 then could human ambiguities be avoided? • Decryption of any and all encrypted code? • Without seed, may require too much time to render result interesting • Hence some states impose limitations on encryption complexity (128 bits) • Complete 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!

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) • An 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 1 typo!

15. Defensive Programming • Don’t trust your interface; verify even if 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 make errors: check, verify, report, mistrust • Make programmatic “reports” of suspicious values and conditions, e.g. via #ifdef or similar mechanism • Don’t be complacent; consider future enhancements • Today your SW works perfectly for the given requirements • Tomorrow the requirements change, and you need to adopt your SW: 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 • Words of wisdom: http://www.cs.yale.edu/quotes.html