SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Wed, 5 Mar 2003 12:22:42 PST8
From:	Peter Skye <pskye@peterskye.com >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: Lynn's project

Content Type: text/plain

There might be a worthwhile idea or two in Aspect programming:

http://books.slashdot.org/books/03/03/02/2253212.shtml
_____

Lynn H. Maxson wrote:
>
> . . . synchronization of change management
> [between specification and programming]
> has always challenged any development.

Agreed. I tend to be *very* verbose with my inline comments; what I've
learned is that two years after I write something I often don't remember
what I was thinking. The English is necessary so I don't have to
reverse-engineer my own coding.

> 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

I've read some of his literate programming, though I don't remember too
much.

The examples he gave, I noticed, matched somewhat with how I code.
Probably because of my life-long love of flowcharts, I tend to write
*only* commented documentation first, such as

/* Next get the entire command line string so
/ it can be parsed character by character. You
/ can't use the builtin functions for parsing
/ because the parameters contain non-standard
/ and dynamically-changing delimiters. */

/* Step through the command line string and
/ create pointers to all delimiters. Use the
/ ParamDelim table to determine what the
/ current delimiters are. */

etc.

After I write just the comments, I go back and write the code. I guess
I'm not a "code jockey", more of an algorithmnist ("systems analyst" -
go ahead, make wisecracks).

You may argue if you wish that my comments aren't true documentation
because they pertain to the logic flow rather than the "job at hand".
Not so. I have a number of programs who begin with hundreds of lines of
commented documentation -- tables, warnings, notes, exceptions, test
data to be used to verify that the program works under certain
conditions -- before you see any code.

> Thus you have the need to mix and merge in numerous
> forms both [documentation and logic] sources.
> The question comes down to how to do this.

Yes.

> I have no objections to XML per se, but . . .
> 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.

Lynn, I agree with this point of view totally.

> >I don't recall you ever mentioning how you believe
> >[hardware-specific code] should be addressed. ..."
>
> 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.

I may be way way behind here. Are you discussing SL/I or something
newer?

I've used the Intel books (free, very nice of them) quite a bit over the
years. And I've used them to help me embed inline machine code (not
assembly; hex stuff) in some of my programs. But, honestly, this is a
bit cumbersome. (Very early in the PC's reign we did this by using POKE
in Basic to create machine language commands, then executing them. That
was cumbersome too.)

I like what the Embellish (a graphics program) developer did -- he wrote
one program for multiple platforms and used a platform-specific DLL
which contained all platform-specific code.

> 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.

The assembly language front end is very tiny. It's basically a
boiler-plate table of options.

> Unfortunately it doesn't work for [a driver in] PL/I.

Wow, we could discuss this a lot. I've never tried writing a PL/I
driver. First, I think it would have to be assembly frontend to C which
calls PL/I. Second, I'm not sure I can get the necessary type of
compiled object out of the PL/I compiler. Third, there's the little
matter of PL/I dependencies on libraries.

I *think* you can compile PL/I functions/procedures and link to them
from C but it's been several years since I studied up on this and I
might even have my platforms (mainframe vs. OS/2) scrambled.

> 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.

The filters (I've written hundreds) are debugged and reliable, thus I
know what's going to happen. If I start writing new specs & code I
might introduce a bug. Why call a bunch of new ladies and risk numerous
failures when I know I'll get a "yes" from Viola?

Give me a better tool and I'll throw away my filters.

> 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?

As for different source languages, for my entire life I have had only
two in my cranium when I'm developing. One is English with which I
write my documentation -- the analysis, the rationale for choosing a
particular method of implementation, the notes concerning that chosen
implementation. The other is machine code -- "what will the binary
_really_ be doing when it's executing"? And yes, I consider binary a
source language; it's the hardware that does the work, not the binary.
So I don't think at the extreme low level of hardware; I'm not thinking
in terms of what is going on in the adder or how many cycles a far jump
will take.

The stuff in between the English and the binary -- PL/I or Pascal or
Rexx or whatever -- is what you want to get rid of, yes?

- Peter

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

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 [ 05 | 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.