1 / 16

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

Herbert G. Mayer, PSU CS status 6/27/2011. CS 410 Mastery in Programming Chapter 1 “Good Programming Practice”. Syllabus. Programming Practice Measuring Master Programmers Are You a Master Programmer? Software Development Practices Software Complexity Interesting Experiences

gunnar
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related