SCOUG-Programming Mailing List Archives

<< Previous Message <<

Date:	Mon, 17 Feb 2003 09:57:51 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: In retrospect

Content Type: text/plain

Ben,

"Much of this interesting exchange is beyond what I know but
I can relate to this point. One role I've been in is algorithm
development which I regard as mostly distinct from
programming. ..."

You know what's absolutely odd about the distinction is that
both are based 100% in formal logic. Different languages,
same formal logic. Different symbol sets, same formal logic.
That you can "literally translate" the Matlab expression into
C++ bespeaks that two different means of expression, i.e.
different languages, based on the same formal logic
nevertheless have "logical equivalent" forms.

You have an interpreter, Matlab, that cannot produce
compiled output. Therefore you must spend people time
writing in two languages, when the only requirement lies in
the choice of executable forms, which is language
independent. If it weren't for the fact that C++ depends upon
choosing among incompatible class libraries, Matlab could save
you one hell of a lot of money and time by offering compiled
code as an option.

I appreciate your input. You don't see writing expressions for
Matlab as programming or Matlab as a programming language.
We differ on this as the only difference between a
specification language and a programming language lies in
whether or not a tool for translating it into executable code
exists. For that reason every programming language is a
specification language, but not every specification language is
a programming language.

But you see Mathlab depends upon logical equivalency to
translate the input language into the output language of the
underlying machine. That says it doesn't use the language it
supports.

Now you know I've proposed a specification/programming
language, SL/I, based on using PL/I syntax, the APL symbol
set of primitive operators, PL/I data types, PL/I and APL use
of aggregate operands, the addition of the assertion
statement to that of the assignment statement, and use of the
two-stage proof engine of logic programming. Steven may
have difficulty accepting that prototypes of all these exist,
but I'm hoping that others are more open minded.

The end result is a language that not only is capable of
specifying itself but any other language based on formal logic.
Self-defining. Self-extensible.

"The general problem is reducing a long time series of n-point
fluorescence spectra to a DNA sequence or
genotype--another chemical data problem. The possible
variations in the raw output are so great that a regression set
comprising several hundred cases isn't complete--new types
of failures keep showing up."

You hit upon a key point here of current methods of
generating test data, your regression set, versus the dynamic
generation I propose through software, that represented by
the predicate logic used in Trilogy.

When Steven talks about unit testing his unit is an entire
program. Yet the smallest unit is a single statement. These
get aggregated into control structures. These into
procedures. And then these into programs. So it is reasonable
to ask when is a unit not a unit of unit test?

Nothing really prevents creation of "artificial" programs of
these smaller aggregates for "unit" testing except for the
excessive amount of extra writing and rewriting necessary.
You also have the problem of deciding on the design of test
data, specifically for the "unit" under test or a more general
form to support multiple units. In either case these represent
yet another source to be created and maintained.

Wouldn't it be a lot simpler to dynamically define (mark) the
unit of test to dynamically determine the variables to within
that unit to dynamically specify their range of data values to
dynamically enumerate all possible sets of values? Moreover
something for whom the dynamics of change requires only
modification of the source language and not source test data?

If Matlab were open source, the first thing I would introduce is
the option of compiled output...in the language of the machine
based upon the intermediary language used internally. In that
manner the only changes for defect correction would occur in
the Matlab language. In that manner you would only need
algorithm writers engaged in the self-deception that they are
not programming, saving the cost associated with "skilled"
programmers.

What you describe is the process you must endure due to the
inadequacies of the tool set. You endure it because you feel
you have no other option. I on the other hand say with open
source you have those options if you are willing to meld them
into an integrated process instead of a hodgepodge of
separate processes which you must externally integrate.

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

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 [ 17 | February | 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.