During my career, I’ve seen the PC’s star rise while the mainframe’s star dipped toward
the horizon. I’ve seen GUI programs replace character-based programs. And I’ve seen
the Web ascend while Windows declines. I can only assume that by the time you read this some new technology will be in ascendance, and Web programming as I know it
today (2004) will be on its way out. These technology cycles, or waves, imply different
programming practices depending on where you find yourself on the wave.
In mature technology environments—the end of the wave, such as Web programming
in the mid-2000s—we benefit from a rich software development infrastructure. Late-wave
environments provide numerous programming language choices, comprehensive
error checking for code written in those languages, powerful debugging tools,
and automatic, reliable performance optimization. The compilers are nearly bug-free.
The tools are well documented in vendor literature, in third-party books and articles,
and an extensive Web resources. Tools are integrated so you can do UI, database,
reports, and business logic from within a single environment. If you do run into problems,
you can readily find quirks of the tools described in FAQs. Many consultants
and training classes are also available.
In early-wave environments—Web programming in the mid-1990s, for example—the
situation is the opposite. Few programming language choices are available, and those
languages tend to be buggy and poorly documented. Programmers spend significant
amounts of time simply trying to figure out how the language works instead of writing
new code. Programmers also spend countless hours working around bugs in the language
products, underlying operating system, and other tools. Programming tools in
early-wave environments tend to be primitive. Debuggers might not exist at all, and
compiler optimizers are still only a gleam in some programmer’s eye. Vendors revise
their compiler version often, and it seems that each new version breaks significant
parts of your code. Tools aren’t integrated, and so you tend to work with different
tools for UI, database, reports, and business logic. The tools tend not to be very compatible,
and you can expend a significant amount of effort just to keep existing functionality
working against the onslaught of compiler and library releases. If you run
into trouble, reference literature exists on the Web in some form, but it isn’t always
reliable and, if the available literature is any guide, every time you encounter a problem
it seems as though you’re the first one to do so.
These comments might seem like a recommendation to avoid early-wave programming,
but that isn’t their intent. Some of the most innovative applications arise from
early-wave programs, like Turbo Pascal, Lotus 123, Microsoft Word, and the Mosaic
browser. The point is that how you spend your programming days will depend on
where you are in the technology wave. If you’re in the late part of the wave, you can
plan to spend most of your day steadily writing new functionality. If you’re in the early
part of the wave, you can assume that you’ll spend a sizeable portion of your time trying
to figure out your programming language’s undocumented features, debugging
errors that turn out to be defects in the library code, revising code so that it will work
with a new release of some vendor’s library, and so on.
When you find yourself working in a primitive environment, realize that the programming
practices described in this book can help you even more than they can in mature environments. As David Gries pointed out, your programming tools don’t have to
determine how you think about programming (1981). Gries makes a distinction
between programming in a language vs. programming into a language. Programmers
who program “in” a language limit their thoughts to constructs that the language
directly supports. If the language tools are primitive, the programmer’s thoughts will
also be primitive.
Programmers who program “into” a language first decide what thoughts they want to
express, and then they determine how to express those thoughts using the tools provided
by their specific language.
No comments:
Post a Comment