SCOUG-Programming Mailing List Archives
Return to [ 21 |
January |
2003 ]
>> Next Message >>
Content Type: text/plain
Sheridan,
The HPCalc program itself suffices as a tutorial on C. There is
little in C not touched upon in the program. If we take a
literate programming approach, combining informal
descriptions with formal code, we should create a document
that functions as a tutorial on both C and HPCalc. I would
probably suggest that we encapsulate text and code using
html. This would allow us to integrate all the source files
with links attached to the internal references, effectively
creating a hypertext document.
This is something you can only do with an electronic book and
not with a "real" one. In this manner we can then offer a
tutorial which any reader need only seek out that which he
doesn't know and not be bothered having to scan through
what he already does.
We could, for example, incorporate within the same hypertext
document a tutorial replete with examples of PM programming
and graphical user interface design. Then as we proceed from
program to program, say from HPCalc to a PM Editor to a
compiler and to eventually something like Mozilla or
StarOffice, the tutorial material will suffice for self- or
independent-study.
This allows us a more general, a more philosophical approach
to open source and what in general needs to occur to insure
its success...at least for the OS/2 community. As part of this
entire process, based on our experiences, we can decide that
which we will retain, that which we will change, and that
which we can do without.
We have to get beyond the surface implications of open
source. We have an IT industry which regardless of available
funds and fulltime people resources still cannot maintain pace
with change requests. If you have everything going for
you--the choice of best people, tools, and methods--in closed
source and you can't do it, then it's obvious that open source
as it stands will achieve even less.
To me the issue is productivity. As our primary activity is
writing, a physical activity with finite human limits, we need
to find ways to write less and output more. Those ways lie in
improving our tool set. We need eventually to move from
imperative, third-generation languages like C, C++, JAVA, and
PL/I to some declarative, fourth generation language,
preferably based on predicate logic. We need to switch from
editors and compilers to interpreters, in which we integrate
editing and compiling naturally and not artificially in so-called
IDEs.
Once we have command over our existing tool set we will
have the experience and knowledge needed to shift them
toward what we want. Then we don't have to take anyone's
word or opinion for it as we will have the facts in hand.
=====================================================
To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".
For problems, contact the list owner at
"rollin@scoug.com".
=====================================================
>> Next Message >>
Return to [ 21 |
January |
2003 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
| 
