SCOUG-Programming Mailing List Archives

<< Previous Message <<

Date:	Tue, 4 Mar 2003 11:51:21 PST8
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	< "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Lynn's project

Content Type: text/plain

Peter Skye writes:
"... If I understand one of your arguments correctly, the
specifications become the executable and thus the
documentation is not "in the mind of the developer" but rather
an inherent part of the written program. ..."

All software developers, whether or not they care to admit it,
follow the same stages of software development:
specification, analysis, design, construction, and testing with
testing occurring throughout construction. If you have a
specification language which is also a programming language
and you write the specifications in the specification stage,
then the software as it does in logic programming provides the
necessary analysis, design, and construction, this latter which
produces the executable.

This is a specification/programming language using a formal,
i.e. restricted, syntax and logic. It differs from that which
occurs within documentation. However, a connection, an
association exists between the two. Their synchronization of
change management has always challenged any development.

Knuth sought to address one part of this with his proposal for
"literate programming". This involved a two-language
approach within a single document, one formal, one informal,
using juxtaposition overall. The truth is that you have to add
code to a compiler to cause it to skip over the documentation,
in non-literate programming the current comments embedded
within source code. The compiler wants the source code
alone in whatever order dictated by the formal language.
Most user documentation has no use for the source code, only
different forms (organizations) of the same informal language.

Thus you have the need to mix and merge in numerous forms
both sources. The question comes down to how to do this.
Some work underway suggests the use of XML, which for my
money is stupid. I have no objections to XML per se, but
do object to the maintenance problems it engenders as "the"
source. That's why I have supported a lower level source
which can be automatically supported by the software tool to
construct XML documentation for viewing, meaning its actual
source is elsewhere.

"...At least two of the shorter threads pertain to
hardware-specific code; the two I read apparently were
commands that communicated directly with drivers, such as
resetting the SCSI bus. I also noticed a thread about
splitting multi-processor machines into multiple virtual
machines (I think) but I didn't read that thread; apparently
this is done under program control. I don't recall you ever
mentioning how you believe these technical aspects should be
addressed. ..."

Not true. Unfortunately I started out in this business having to
know the logic of the hardware physically and electronically,
because whenever it broke I had to fix it. That experience
formed the basis for my statement that both hardware and
software have a 100% basis in logic.

I thought I had provided enough examples, the most recent
Volume 2, the Instruction Set Reference manual, for the
Pentium from Intel to show that an equivalent HLL set of
expressions existed for every machine instruction. That
allows us to have machine-dependent as well as
machine-independent specifications. This includes the ability
to specify as data the command string necessary as input to
an instruction to reset a SCSI controller.

The problem you have with a .exe, .dll, .sys, etc. lies in
different forms used for that function. I know that you can
write device drivers for OS/2 in C, but not without an
assembly language front-end. Unfortunately it doesn't work
for PL/I. In either case that doesn't reflect badly on C or PL/I,
but on their implementations. In short it is not a language
restrictions. Nothing dictates that you cannot indicate in the
source as a declarative option the ultimate form you desire.
Frankly that's no more than a different set of specifications in
the same language as well.

At some point you will realise that every vendor effectively
screws you with every tool, that his focus on a piece, a
segment, of the overall process keeps him from having to fit
within a much larger system of such pieces. We know from
our experience with AD/Cycle that vendors have no desire to
commit financial suicide by their cooperation consisting of
"you first, no, you first" discussion.

emx-gcc is simply a continuation of the piecemeal approach of
closed source. I don't want to blame the UNIX and now Linux
mentality for this oversight. You seem to enjoy writing
"filters" piecing together utilities into a working prototype.
You as well as many other techies abound in the joy of having
and learning 50 different utilities and mastering combining
them in different modes. I don't find it beyond my abilities,
but I do find it absolutely unattractive hordes of open source
users uncomfortable with what it takes to become
contributors.

It's not an argument that you can't do something, but one of
why do it that way. Why have an unnecessary "make"
activity due to a compiler, not language, restriction? I'm sure
if we looked not all that hard we could come up with the
same conclusion with respect to the "resource" file. So why
have all this multitude of different ways and different source
languages if clearly through using a set of different options
you render this unnecessary?

Fourth generation languages, those involved with logic
programming, do not use internal procedures. No language
requirement exclusive of a compiler restriction exists for their
use in third generation languages like C or PL/I. In fact, PL/I
offers a "package" option which allows the use of external
procedures only. So I don't make this up.

So there are things that we can do to make life easier for
those who might also want to join in. I'm not a Niklaus Wirth.
I don't want to manage or punish you with software. I want it
to make it easier for you to write and maintain it. That means
synthesizing a better system from the systems we now have.

=====================================================

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 [ 04 | March | 2003 ]

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.