Much of the history of modern technology has been a process of
increasing complexity until complexity becomes an obstacle to
further progress. The quantum advances in technology have
largely occurred when ways have been found to internalize
complexity behind a higher level of apparent simplicity.
Consider the evolution of programming languages. Ultimately,
computers can only deal with machine language, and every program
must deal with the hardware at that level. But early on the
difficulties of expressing abstract concepts in raw ones and
zeros exceeded the ability of human programmers to deal with the
mind-boggling complexity of that approach. The solution was
assembly language - the first generation. As programmers tried
to express ever more complex abstract concepts in software, the
limitations of the available tools again became a serious
distraction, setting the stage for the next generation of tools.
It's said that one line of code in a higher level language can do
what takes 10 lines of code in the previous generation language.
It's true that some languages have attempted to deal with
complexity by limiting the functions available to the
programmer. Today C++ is being promoted as a "solution" to the
"programmer problem" by turning application development into a
simple process of assembling pre-written objects. This sounds
like a good idea to management types who see programmers as an
expensive and troublesome complication in "their" business. But
C++ is built on such faulty perceptions and motivations that its
failure to deliver on its promises of making software development
quicker, cheaper, and easier, has been inevitable.
The component reuse concept of C++ may be useful in some very
limited applications, but the programs I build do tasks that have
little in common with the typical components used in "standard"
applications like spreadsheets and word processors. As such, I
find the imposed authoritarianism of C++ far more of an obstacle
than an asset - I end up spending far more effort working around
the limitations of the C++ concept than it saves me with the few
"standard" components I am able to reuse.
My long term language of choice is PDC Prolog since it seems to
provide the best fit with the way my mind works (your mileage may
vary). Prolog was largely written in C, but I find I can do
things in Prolog that would be very difficult if not impossible
to do in C. Rather than "solving" the problem of complexity by
imposing restrictions and limitation like C++, Prolog simplifies
the underlying complexity in a way that empowers me to do more
than I could do otherwise.
There is a quantum difference between "enabling" and
"empowering". An enabling tool makes a task easier and/or more
efficient, but doesn't do much to expand the capabilities of the
user beyond what he could in theory accomplish without the tool,
assuming time and effort were not a factor. An empowering tool
makes it possible for the user to accomplish tasks that are
beyond the his capabilities without the tool.
The windoze approach is focused on enabling - they started with a
pretty UI with menus and icons that made it (appear) easier for
some users to accomplish the same tasks they could in theory do
without windoze, if they knew all the necessary command line
arguments. As such windoze has always been a UI with a kludged
operating system hung on the back to support the UI.
While the windoze approach does offer some value in narrow
graphics oriented applications such as desktop publishing, in
reality most of its reputation of being "user friendly" is the
result of very aggressive marketing efforts and illegal coercion
of the computer industry. Perhaps the most effective strategy in
concealing the complexity of windoze has been manipulating the
market so that the vast majority of windoze users got it
pre-loaded on their computers. As long as they're willing to use
it as it came in the box, and put up with the instability of its
fundamentally flawed internal architecture, most users remain
blissfully unaware of the tangled mess behind the pretty
screens.
The reason OS/2 was so superior to windoze was because it was a
core operating system first, with a UI added on top in order to
provide a more convenient way for the users to deal with the core
operating system. From what I understand, Win2000 is built on a
BSD core in an attempt to move toward this model. However, I
believe that microsoft's corporate culture of exploitive
authoritarianism will make it very unlikely that windoze will
ever make the quantum level transformation from trying to be
simply enabling to becoming empowering.
As a true believer in intelligent machines, I've come to see
microsoft as the primary obstacle to developing machines that
actually understand their users. Every time more powerful
hardware becomes available, microsoft bloats up its brain dead
operating system to consume all of the available horsepower.
Even with hardware that is several orders of magnitude more
powerful, computers today are still largely limited to the same
basic set of tasks they were doing a decade ago - just doing them
on prettier screens. Artificial intelligence will only be able
to advance when the massive resource consumption and restrictive
limitations of windoze are eliminated.
One of the reasons I'm attracted to Linux is that it is a very
powerful, efficient, and robust operating system. If the problem
of dealing with the current level of complexity is addressed by a
quantum level evolution in the user interface - one that provides
a higher level of simplicity that empowers the user - Linux could
well become the foundation for building intelligent machines.
The last thing I would want to advocate is to "windowize" Linux.
Trying to deal with the complexity of Linux by imposing arbitrary
restrictions and limitations would likely destroy the fundamental
value of the OS. Rather I advocate solving the problem by moving
beyond the current complexity onto the next level of simplicity.
--
Kort E Patterson
http://www.overalltech.net/
http://www.hevanet.com/kort/
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
