Programming power necessarily introduces complexity into the experience of
the developer, just as aircraft power introduces complexity into the
operation of an aircraft.
A paper airplane is easy to fly. Just throw it. But how high can it fly, and
how many people can fly in it?
A single-engine small aircraft is considerably more difficult to fly. It
propels itself, and must contain at least one human being. So, it must be
able to take off and land without injuring the human beings inside it. It
must have fuel inside it. It must have enough power to lift the plane the
engine, the fuel, and the human beings inside it. It must have controls for
navigation, a control interface to enable the pilot to control it, and an
instrument interface to enable the pilot to receive information from it. But
how high can it fly, how fast can it fly, and how many people can fly in it?
A Boeing 747 is considerably more complex that that. It can fly at high
altitudes, over very large distances, carry hundreds of people as well as
their baggage, fly at considerably higher speed than a single-engine small
aircraft, and even fly itself. But what sort of complexity does this add to
the design of the aircraft? At high altitudes, air pressure is much lower,
and air is much thinner. It must have enough power to fly in thin air, and a
system of cabin pressurization to provide enough air to the passengers, as
well as a system to protect passengers when the cabin loses pressure. It is
very large, so it must have enough power to lift an incredibly heavy
aircraft to high altitudes in thin air. It must have several jet engines,
rather than a single propeller engine. These engines must be coordinated to
make the plane fly correctly. In order to fly itself, it needs a computer
that can gather data about the state and location of the aircraft, and
calculus algorithms to calculate the trajectory and the amount of power, as
well as the state of the navigational devices on the aircraft, such as
flaps, rudder, ailerons, etc. It must have backup systems. that can take
over in the event of any system failure. It must have a bathroom for the
human beings inside it, as well as other human necessities that must be met,
such as thirst, hunger, etc. It needs a crew of human beings to fly it. And
each member of the crew must be fully trained to do their job and interact
successfully with the rest of the crew and passengers. And so on.
Back in the day, a computer could perform exactly one instruction at a time.
In fact, a computer can STILL only perform only one instruction at a time.
Back in the day, there were no networks, and no Internet. Computers were
safely contained within their own confines, and had very little memory and
procesing power. Computers are calculators that have electronic switches and
toggles in them. Back in the day, computers were programmed using binary
machine code. Punch cards were used to feed instructions to them. A hole was
a 0. No hole was a 1 (or was it the other way around?).
As computers became more powerful, the number of punch cards and binary
instructions became too large for humans to keep up with. Assembler language
was developed. It provided a human-readable language that was translated by
a computer into machine code, combining whole blocks of machine code into
single assembler language commands. Now people could type instuctions into a
file, and compile that file into machine language that the computer could
execute. At this point, a program interface was still lines of command-line
text.
As computers became even more powerful, programs became larger, and did much
more. Higher level languages such as COBOL, Fortran, Pascal, and C were
developed for the purpose of making programmers more productive. They
combined blocks of assembler code into functions that contained
commonly-used operations, and data types that contained larger blocks of
data in a single container. These functions and data types could then be
combined to create a large variety of applications, applications that had
graphical interfaces, could interact with a variety of peripheral devices,
and make life much easier for users, who could perform tasks in much less
time than before. These high-level languages were first compiled into
Assembler, and then compiled to machine code that the computer understands.
To write such an applicaton using assembler only, or worse yet, machine
language only, would take entirely too much time. Of course, with the advent
of new higher-level languages, developers had to learn them and adapt with
the changes.
Networks were introduced, and with them, the Internet, the largest computer
network in human history, a network of millions of computers across the
globe. And computer power continued to increase, doubling every 2 years
(more or less), according to Moore's law. With the increase of programming
power, programs became much more complex. Multi-tasking operating systems
were developed, which could seem to run more than one program at a time via
time-sharing, and Network protocols were developed to allow computers to
talk with one another and exchange data. The complexity of such programming
made procedural programming so complex that it was extremely difficult to
write, debug, and maintain. Security issues demanded that software have
accessible and inaccessible areas, and that these levels of accessibility be
configurable to an increasingly higher degree of precision.
Object-oriented programming was introduced some time around 15 years ago or
so, which included principles such as Inheritance (which cuts down on
redundant code, making program code leaner and simpler to debug, maintain,
and extend), Encapsulation (which provides the ability to hide or expose
data and functionality on a highly-configurable basis), Polymorphism (which
enables classes to be used for a variety of similar purposes), and
Abstraction (which enables developers to treat aggregates of data and
process as real-world "things" or objects). Rather than thinking of data and
process (the essential components of any program) as what they really are,
programmers could think of them as objects, engines, tools, etc. In essence,
this was a continuation of the process of combination that started with
Aseembler language. Functions and data were combined into classes, which
provided larger "blocks" of functionality to the developer. This made
developers able to write even larger and more powerful applications, the
"Boeing 747" of programming technology.
ASP is procedural in nature, and relatively simple to use. It is also simply
not capable of doing a whole lot. It is the "single-engine small aircraft"
of web developers. Note that single-engine small aircraft are still in use,
and useful today, for very limited purposes, just as ASP is still in use,
and useful today, for very limited purposes. ASP.Net is more powerful by an
exponential factor, faster, and has the ability to do anything that any
compiled programming technology can do. This makes it more complex, and
harder to learn. That is simply the way things are.
If you don't have "the right stuff" to learn it and deal with it, stick to
ASP. It will be around for a long, long time, just like small aircraft. But
realize this: ASP.Net is not designed to be used like ASP, any more than a
Boeing 747 is designed to be used like a single-engine small aircraft. It
doesn't need to be "dumbed down" to a procedural level. It is designed
extremely well for what it is. It doesn't need "fixing." If you don't like
to "hang ten" on the big waves, the swimming pool is still there. But if you
want to ride the curl, don't argue. Listen and learn.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
When you can snatch this pebble from my hand, you will have learned.
