14 July 2009

IBM: Assembly Language Programming

WARNING: If you easily get distracted and go off on tangents then this blog post is not for you. Please browse to another place on the internet and be content.


While visiting my Mom this last week I found one of my Dad's IBM Assembly Language books upon the bookshelf and decided to bring it home for safe keeping and to explore it a bit.

Assembly Language Programming for the IBM Systems 360 and 370 for OS and DOS copyrighted circa 1980 by Michael Kudlick.



An example page of part of a binary search in assembly.











Though exposed to assembler in a C.S. class and in an electronic instrumentation class, I seldom think about it anymore. Seeing this book got me to wondering about GNU Assembler. A slightly different looking assembly than IBM's but still interesting. I wonder where this all will end up ...... hmmm. ;)

You were warned, remember?

02 July 2009

Where It All Began

My father was a computer programmer from the early 1960's until the early 1990's when he retired while in his early fifties. His journey began by learning to wire boards for an accountant after he got out of college in 1962. This skill landed him a job teaching high school data processing (or programming.) Then a year later he landed a job with General Telephone (GTE) as a beginning programmer and did that until retirement. His only programming classes were several weeks of training in the Dallas-Fort Worth area then the rest was on the job training.

Interestingly enough the replacement teacher, when Dad left the high school, ended up still being the programming teacher at the high school by the time that my sister and myself got there in the late 1970's and both of us took that class.

Other than what little (punch cards and COBOL) my Dad tried to show me about programming up until high school, this class was the first time I had a programming class. We learned BASIC on a Radio Shack TRS-80 (aka Trash-80), RPG, COBOL, and FORTRAN from a terminal connected to a state computer. I forget whether I was a sophomore or a junior when I started the class (either in 1979 or 1980.) We started off learning BASIC and then moved onto other languages of our choice from the list above. I only tried RPG and COBOL. Luckily I did not have to learn FORTRAN for a few more years and luckily stopped using it in around 1997. Interestingly, COBOL was a much more a Literate-like language which Knuth has promoted.

Our instructor made us use this form (on the left) to write out our algorithm. At the time on the TRS-80 you could type in your code and get it running. Then you either printed it out on a narrow ribbon paper or if you had a cassette tape you could save it to cassette. Then you had to type NEW to delete it from the TRS-80 and you were ready to type in another program. I would print the working code out on the ribbon paper and tape or glue it to the work sheet as seen to the left. This is the first BASIC code I wrote.



Here is a example of the ribbon print out. This was just about the longest program we wrote during the class. Most of the program exercises were simple and small. All very sequential in nature.









Looking through my notebook from this class I found an interesting exercise. It appears that the instructor wanted us to write a program to plot a sine curve and to calculate the area under the curve. What I find so interesting is the fact that at the time I had no idea what a sine function was or even the concept of the area under a curve. A few others in the class may have had a clue but not myself. Somehow I got through this class doing somethings I did not learn for another four or five years while I was in college trying to catch up to start taking some physics classes. I did not take trigonometry or calculus until several years (~1985) into college.


If you look closely enough you can see that I defined Pi as TT instead of PI. That was how naive I was in math....really.


Also note the TRS-80 is an interesting story in itself.

Now nearly thirty years later I am still at it but doing it for physics but this was where it all began.

01 July 2009

Buksas' Postulates On Testing

After careful thought (and experience born out of his projects) about software and unit testing, one of my coworkers (Mike Buksas) wrote some "disorganized thoughts" about unit testing. I thought they were worth sharing here:

Postulate One: Tests suffer from the same, or complimentary, defects as the code they test.

Postulate Two: Stubborn determination to do the right thing badly is not a virtue.

Postulate Three
: Bad code needs more tests, and needs tests more, to attain the same level of confidence.

Conclusion One
: Bad tests impede refactoring, making the code harder to improve.

Conclusion Two
: Testing makes bad code more correct, but less maintainable.

Postulate Four
: Code must change over time, and bad code is harder to change correctly.

Conclusion Three
: Determined testing can make bad code worse over time, or at least, less better than it could be.

from Local Extrema: Disorganized Thoughts On Unit Testing Software



I do not know about you but this sorta reflection causes me to think more about how we write unit tests and to strive to do a better job for other's sake.

Another Reason To Like Kent Beck

Kent, regarding your comment that "all methodologies are based on fear". Would I be way off if I were to guess your fear was the Change Cost Curve? -- Ben Aveling

No, my fears are more about not spending enough time with my kids, growing away from my wife, and dying young of heart trouble like my grandfather. The Change Cost Curve I know how to handle.

from c2/KentBeck

"I Can Sleep When The Wind Blows"

The following story, from a Kent Beck article, illustrates one reason we have enjoyed learning and doing XP.


Once, a farmer interviewed a young man for a job as a farm hand. One thing the young man said particularly puzzled the farmer,
“I can sleep when the wind blows.” The farmer didn’t know what this meant, but the young man seemed competent and knowledgeable and so he was hired.

A few months later the farmer was awakened in the middle of the night by a thunderous wind storm. Panicked, he raced to the cot where he found the farm hand fast asleep. Shaking him roughly awake, he demanded, “We have to bring in the animals!”

“They are already in.”

“We need to fasten the windows.”

“They are already fastened.”

“We need to tarp the hay.”

“It’s done.”

After going down his list of worries and being reassured that they were already taken care of, the farmer finally realized the meaning of the young man’s puzzling statement. By taking care to finish every job and leave the farm safe every night, the farm hand could sleep when the wind blew.

The farmer went back to bed and told his wife what he had just learned. She just smiled knowingly and the two of them went back to sleep, lulled by the music of the storm.




The rest of the article is here: Accountability In Software Development