Troubleshooting Professional Magazine
|
A Tribute to Programmers |
My other writing deadlines are so tight I have only 3 hours to write this Troubleshooting Professional Magazine. Thats why this issue wasn't published until the eighth of the month. I've always found the fastest thing to write are editorials on a subject you feel strongly about. So how bout this:
Programmers Rock!
We built this world. Every bank transaction, every robotically created car, every special effect in every movie -- we programmers created it. We pound out code all day and all night. If we finish our work we do it for fun. When we've run out of fun ideas we code Open Source projects. We're unstoppable.
This issue of Troubleshooting Professional Magazine is a tribute. So kick back and relax as you read this issue. And remember, if you're a Troubleshooter or programmer, this is your magazine. Enjoy!
Please vote for your favorite Troubleshooting Professional issue
(by year and month) and/or article (by year, month and title).
Submit your entry to Steve Litt's email address.
The results will be announced in our third anniversary issue, which comes
out in January.
Back in those days I used to laugh at the old guys whose every thought involved a goto. Today I'm amazed at the arrogance of my youth.
It didn't cross my mind those guys didn't grow up with the luxury of 64K of memory to save subroutine states and return addresses. They had to make do with 1K or less, and they did it admirably. Older and wiser, today I know I don't have the intelligence to write such code. My generation was the first who could afford to substitute RAM for intelligence. The guys who came before us established programming as an activity and a profession. They did their job superbly.
The structured guys took programming from the research facility to the business, then to the home, and finally to what would someday be called "the enterprise". With their truly prolific functional decomposition design paradigm and their cowboy mentality, they could write programs with double the functionality in half the time. Their language of choice? C! By the time their era ended, their code was everywhere, including the architecture of the Internet.
Somewhere in the early or mid 1990's the structured crew handed the baton to the OOP guys. These guys could assemble a serious app out of a bunch of prefabricated object before functional decomposition got down to the fourth level. When they couldn't find an object, they built their own. They built objects independent of any language, that could be linked in at run time. They were called "developers", "application developers", and "software engineers", but they continued the proud tradition of "programmers". They run the world, and run it well. On the way, the OOP era took a detour. Many OOP development environments were created to fill marketing needs, not to produce robust code. Serious bugs cropped up.
Open Source to the rescue. Using the ancient C language combined with their knowledge of modern OOP concepts, they created small, fast, modular and robust software. Others used new Open Source programming languages such as Python and Perl to achieve remarkable productivity. Programmers have always loved to make money in the day and program at night (some vice versa). They were quick to join Open Source projects. Armed with the surprisingly versatile and long lived C language, and the best of modern OOP concepts (devoid of the cow pies that often accompanied popular OOP), they produced spectacularly clean code.
We rocked in the 50's, when you could list the worlds programmers in an address book. We rocked in the 60's, when geniuses plied their gotos in assembler, Cobol and Fortran. We rocked in the 70's, when we codified design concepts in preparation for large projects yet to come. We rocked in the structured 80's with our conquest of every business with more than 10 employees. And we rock in the 90's with our OOP, web, and Open Source programming. We eat too much pizza and drink too much coffee. We fly airplanes and ride skateboards. We have long gray beards and faces devoid of peach fuzz. We live in every nation on this earth, and we work together on a daily basis. And most of all, we pound out great code. From the first guy to boot a computer with patch cords, to the guy starting a Free Software project in his basement, we take pride in this world we've built.
The Samba code base is truly beautiful. It's unbelievable what great programmers can do with non-oop C. Encapsulation? Yes, plenty. Reusability? Absolutely. Readability? You better believe it -- everything I described in the August 1999 issue of Troubleshooting Professional Magazine and more.
I was a professional C programmer from 1984 thru 1995. I thought I was pretty slick. I now know I just scratched the surface. The Samba source showed me numerous techniques I could have used -- should have used. Encapsulation via static vars. OOP like separation of program functionalities, modeling the problem domain.
Open Source projects like the Samba project give programmers the unique ability to learn from the masters. To learn the right techniques. To learn from a code base that's proved its success in maintainablity by an Open Source team, and proved its success in day to day performance. No longer are we at the mercy of the quirks of the lead programmers who mentored us, or the idealism of our school teachers, or the academicism of books and website authors. Now we can take a known good codebase and disect it. Now we truly can stand on the shoulders of those who came before us.
All submissions become the property of the publisher (Steve Litt), unless other arrangements are previously made in writing. We do not currently pay for articles. Troubleshooters.Com reserves the right to edit any submission for clarity or brevity. Any published article will include a two sentence description of the author, a hypertext link to his or her email, and a phone number if desired. Upon request, we will include a hypertext link, at the end of the magazine issue, to the author's website, providing that website meets the Troubleshooters.Com criteria for links and that the author's website first links to Troubleshooters.Com.
Submissions should be emailed to Steve Litt's email address, with subject line Article Submission. The first paragraph of your message should read as follows (unless other arrangements are previously made in writing):