SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Sun, 22 Oct 2006 20:37:44 -0700
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: The language end goal

Content Type: text/plain

Greg,

"And this relates to OS/2 in what way?? How many machines
with different RISC instruction sets are we using to run our
OS/2 Developers' Assistant?"

Thank you for the question. I call the tool "The Developer's
Assistant". I could have called it "The Developer's
Productivity Aid". Or even "The Developer's "True" IDE"". I
sought (and seek) to provide an environment in which the
developer does what the software cannot and the software
what the developer need not. In short it relieves the
developer of a significant amount of clerical effort which we
can automate in software.

As such it is platform-independent in terms of operating
system or machine architecture. Thus it is not OS/2-specific,
but -inclusive. It is RISC inclusive, CISC inclusive, Windows
inclusive, Linux inclusive, UNIX inclusive, in fact inclusive of all
software, operating systems, and computing systems.

That's really not all that difficult in a specification language
which incorporates all of formal logic. That's because all
software, all operating systems, and all computing systems
have a 100% basis in formal logic regardless of physical or
linguistic implementation.

By having a logical equivalency among the three levels of
RISC, CISC, and logical and with the lowest logical level
capable of expressing that equivalency could mean, for
example, that we could compile the source for a single
application or application system or multiples thereof for any
number of target platforms (operating or computing systems)
as part of a single unit of work: one compile producing
multiple (essentially unlimited) concurrent executables.

Instead of one external procedure, one compile we have one
compile with unlimited external procedures on input and
executables on output. That also means global
synchronization of "change" within a single unit of work.

Note that two pre-conditions exist. One, only a single,
all-inclusive source library. Two, only the processing of
source. In a practical sense that means the external divisions
of executables, the .sys, .dll, .exe, etc. do not exist within the
source input, only as a component of the output(s). In short
the same specification ability within the language exists for
them as it does for all other logical and functional aspects of
the source.

If you regard an operating system such as OS/2, specifically
including its component packaging, it means producing an
"updated" executable version of all source of all components
for all target systems as a single unit of work. It's something
which one person, i.e. one developer, on one machine with
one tool and one set of source can do as one unit of work.

I think you can see here an emphasis on developer
productivity. As part of that the tool defaults to interpreter
mode with compile as an option. The interpreter aids in the
developer's productivity while the compile does the same for
an executable in a production environment. Thus again one
tool supporting productivity of development and production.

" OK OK OK... I'm sold. Now please tell me what I need to
know so I can get started with Bob's sample code. I just need
to know WHICH SL/I compiler for OS/2 I will need, where to
get it, and how to set up my build environment."

To get started with Bob's sample code you need a PL/I, not
SL/I, compiler. We will use PL/I to get to SL/I. Get there we
will.

" And then, maybe..... Just maybe... Some kind of discussion
about what the Developers' Assistant should look like to the
programmer. ..."

Yes. Yes. Yes. We shall certainly discuss the design of the
tool with all of the windowing options available to us. We will
start with an editor. Enhance it with syntax checking. Add
semantic checking. Thoroughly discuss the operation and
design of the two-stage proof engine along with its
implementation. We will implement the use of predicate logic
to automate the generation of test data, if for no other
reason that to illustrate that such a language with such a tool
using a specific logical form eliminates the need for external
testing such as alpha and beta testing.

Again you should see the emphasis on developer productivity.

On the other hand as this comes as an open source project
with the entire source for the language (to support its
self-defining and -extensible nature) and the tool you will
have the ability to customize it to suit your needs and
preferences. Thus it really makes no difference what
decisions we make initially with respect to the features you
mention, because if you don't like them you can use something
else. With the productivity and testing features you will find
that the huge numbers you have quoted for source code in
previous messsages will appear less daunting.

And again you will note the emphasis on developer
productivity.

And again thank you for your comments and questions.

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

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
"postmaster@scoug.com".

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

Return to [ 22 | October | 2006 ]

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.