Transcript LN 5: programming_skill

CS 201
Computer Systems Programming
Chapter 5
“System Programmer Skills”
Herbert G. Mayer, PSU CS
Status 10/8/2012
1
Syllabus










Programming Practice
System Programmer
Software Development Practices
Software Complexity
Interesting Experiences
What Can Be Programmed?
What Cannot Be Programmed?
Algorithm
Defensive Programming
References
2
Programming Practice
General programmer attributes:

Critical thinker, uses good judgment; what’s new? 

Creative ideas, about algorithms, computing

Open to others’ ideas; i.e. great mind

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 
3
System Programmer
An effective system programmer is an experienced
SW engineer, who masters a suitable programming
language L very well: necessary condition
Such a language L allows visibility of, access to, lowlevel 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
4
Good Judgment comes from Experience,
and
Experience 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, instead repeats errors
5
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 
6
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
7
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 Ada Case Statement in Ada compiler; worked!
Until years later I observed an error on Case Statement
implementation!
•
SDSU colleague left 1 page of pseudo-code for Symbolic
Differentiation on a department copy machine intuitively
great, comprehensible, beautiful; stolen with pride
•
Positive feedback about almost religious credo to: not trust
your own SW; but to check instead! (Catch your
assumptions! Best to make few assumptions)
8
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
9
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!
10
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
11
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!
12
Defensive Programming
Don’t trust your interface; verify even if checks seem unnecessary!

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
13
References
1.
The Humble Programmer:
http://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.ht
ml
2.
Algorithm Definitions:
http://en.wikipedia.org/wiki/Algorithm_characterizations
3.
Solvability:
http://www.cs.nott.ac.uk/~nxk/TEACHING/G53COM/G53COMLecture8.
pdf
4.
C. A. R. Hoare’s comment on readability:
http://www.eecs.berkeley.edu/~necula/cs263/handouts/hoarehints.pdf
5.
Dr Richard Sites’ phrase even on sweatshirt:
http://www.cafepress.com/+id_rather_write_programs_hooded_sweat
shirt,63975143
6.
Church-Turing Thesis: http://plato.stanford.edu/entries/church-turing/
7.
Linux design: http://www.livinginternet.com/i/iw_unix_gnulinux.htm
8.
Words of wisdom: http://www.cs.yale.edu/quotes.html
14