Speaking of talking to myself I have to admit that I have
devoted my discretionary time lately to my role as urban
farmer rather than urbane...and witty(?)...programmer. I still
have a few other odds and ends to clear away first, but am
still planning to present at this year's WarpStock in San
Francisco. That gives me only three months, which is a bit
scary.
I hope that our APL members will be ready to present at the
next meeting (July) their solution to either the peg solitaire or
permutation examples. I've not successfully executed the APL
workspace submitted by Ben Archer on the peg solitaire. I
probably need some assistance on just what it is that I am not
executing correctly.
Besides they, Ben Archer and Zdenek Jisba, can update us on
the latest from the world of APL presented at the recent
conference in San Diego which conflicted with our last
meeting. It would be nice to know if they have some
examples of list processing a la LISP implemented in APL.
The latest issue (July 2003) of the C/C++ Users Journal
contains an article on "Building Hybrid Systems with
Boost.Python", subtitled "Getting our two favorite languages
to work together is so much easier now." They do offer a
reference to a website (www.boost.org) as well as the
following introductory paragraph in the arcticle:
"Python and C++ are in many ways as different as two
languages could be: while C++ is compiled to machine-code,
Python is interpreted. Python's dynamic type system is cited
as the foundation of its flexibility, while in C++ static typing is
the cornerstone of its efficiency. C++ has an intricate
compile-time meta-language, while in Python practically
everything happens at runtime. ..."
That's Python and C++. At their core lies C. That ties in with
the lead article in this issue of "Simplifying Lint", subtitled "An
easy and effective means for integrating Lint into your build.":
"Lint Early, Lint Often
"Lint is your software conscience. It tells you when you are
doing bad things. Always use Lint. Listen to your
conscience"[1]
Lint is a tool for finding problems in your source code that the
compiler may have missed before run time. Linting saves
development time by squashing bugs before the
effort-intensive unit and integration testing cycles. This
article describes a set of shell scripts for UNIX systems that
makes running Lint against applications and libraries as simple
as running Make. ..."
I've subscribed to the C/C++ Users Journal for a number of
years now principally using the articles as to why I have
chosen to program in neither. Oddly enough a "wrapper" is
yet another form of "filter", the universal UNIX glue. The UNIX
community had no choice or at least didn't exercise it at the
onset, a practice they have continued until this day.
These articles act as a constant reminder of a community
wedded to an edifice of pasting, patching, and putzing to use
complicated means in tools to achieve simple results. That's
why you end up with an emx package that not only includes
the C/C++ gcc compiler along with a set of 50+ (or is that
50++) utilities. Each utility comes complete with its own
source language.
Now Peter Skye may love the "flexibility" of this approach:
you can do so many "wonderful" things. True, but in software
development you have a number of possible activities at
whose core lies "editing", the maintenance (creating, deleting,
and modifying) of source. All activities follow from this as do
specific combinations (sequences) of them. These form a
rather "finite" group, a mere drop in the bucket of 50+ utility
combinations taken one at a time, two at a time, three at a
time, etc.. I think even in the UNIX (and now Linux)
community once you get above three, you invent a "wrapper".
Of course I propose making changes to language
implementations, primarily compilers, that eliminates the
separate process of build which eliminates the need for Make
which in turn eliminates the separate need for linking. It
seems reasonable to ask why a separate need for Lint exists.
Why do you have all these separate things you have to glue
together to make a needed (if not necessary) whole? Why
not offer the whole to begin with?
Actually it stems from not starting off whole. For example,
take (please) the five stages of the software development
cycle: specification, analysis, design, construction, and testing.
Now in theory these should form a seamless whole with the
others permeated throughout with testing or at least the
ability to do so. I say "in theory" because never "in practice"
has this ever occurred: no one has ever proposed a set of
seamless activities necessary to support a seamless process
(with or without people) asserted for the five stages. Never.
In fact the last major attempt to do so, IBM's infamous
AD/Cycle, ended in colossal failure. Here the attempt was to
standardize the seams, i.e. interfaces, between the different
vendor pieces, the major contribution of the data repository.
The vendors were to provide the seams;IBM, the data
repository. The vendors didn't. Therefore IBM, couldn't. The
difference between didn't and couldn't was couldn't took the
blame.
Now you have to ask yourself why so much effort continues in
seam writing of pieces and none into the same effort for the
whole? You can make the case for not doing so in closed
source: the didn'ts had their reasons, all of them based on
competitive risks with its potential loss of market share and
thus profit. You can't make the case for the same reasons in
open source...unless, of course, the open source contributors
can afford to do so subsidized by their closed source
income.
When I proposed Warpicity almost five years ago to address
what the OS/2 community could do with open source to
achieve independence from the rapidly declining availability of
closed source, I offered a single tool with the activities
seamlessly integrated under the hood. That single tool came
with a data repository/directory as I had no concerns for
preservation of "didn'ts" and thus like the little train "I could".
Now over the next months, few and beyond, we will continue
to grow our knowledge base. As I said next month I hope the
APL folks will step up to the plate. In the following month I
expect we will return to HPCalc, doing a more detailed
introduction to PM programming and the user interface. In all
this I expect we will increase the algorithms commonly
implemented in our different languages of choice.
At some point I expect we will cross a threshold where a
pattern will more clearly present itself to allow us to better
organize and direct our efforts. I don't presume to know it.
=====================================================
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".
=====================================================
Return to [ 26 |
June |
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.
