SCOUG-Programming Mailing List Archives
Return to [ 07 |
February |
2008 ]
Content Type: text/plain
As per usual in as many months another higher priority
meeting has preempted my attending the SCOUG meeting this
month. I have made the request that in the future to please
select the first or second Saturday of the month, my open
Saturdays, for such meetings. I enjoy the SCOUG meeting, but
I do have other obligations which dominate my principal
avocation as an urban farmer.
As something of an compensatory offering I submit to you a
URL which my friend, John Stager, as recent addition to this
mailing list sent me:
http://www.eweek.com/c/a/Application-Development/Microsof
t-Preps-New-Modeling-Language/. It would appear that
Microsoft will introduce a new "modelling" language
designated as "D". In this instance a successor to "C" as it
was to Ritchie's original "B" (Basic Compiler Language) or a
bow to declarative languages or both.
You can read the article to see many of the same points I
have repeatedly expressed with respect to the Developer's
Assistant and SL/I. When actually introduced you should first
check to see if it retains "int" or not. If it retains the
"crippler" int in its different forms, it means that in the now
nearly forty years after the introduction of C and its
successors, e.g. C++ and JAVA, they have not offered the
functionality of PL/I and apparently will not for another forty
years. You can rest assured that SL/I as a "universal"
programming/specification/modelling language remains head
and shoulders above its competition.
With this confirmation by Microsoft and the chance that it
might take the "low" int road it nevertheless lends some
credence, some further credence beyond that of SQL, of the
advantage of fourth generation languages over third. That
despite any protestations by Steven Levine about the lack of
"proof" of my assertions to date should lay that part of the
argument to rest. I don't like Microsoft any more than he
does, but this announcement does amount to a form of
capitulation.
That leaves me with only one unproven concept, the data
directory/repository (DDR), which I hope to rectify in my
lifetime, which I expect will end long before yours. At issue
here lies the extension of reusability from statement groups to
individual statements. It rests on the fact that you cannot
change a statement group without changing its statement
content.
Moreover if a statement instance appears in more than one
group, the need exists to possible effect a change in all
affected groups. Thus the need to extend reuse to the
statement level and to have a more automated, controlled
and complete means of applying changes. That means
extending "versioning" to the statement level as well as
sometimes a statement change in one group need not occur in
another.
Now the key to the DDR lies in storing only statement and
element data content and treating all groups however
hierarchically they appear as bills of material (BOM) lists. As
in manufacturing such BOMs (assemblies) at any level my
contain other BOMs (assemblies) and elements. Eventually,
however, they decompose into raw materials (element
statements and data). Thus the DDR proposes no more in the
programming arena than what manufacturing has done since
the institution of the industrial revolution. Thus again despite
Steven Levine's protestations about "proof of concept" to the
contrary it has existed for hundreds of years.
What does not exist, at least in the form and function I have
proposed, is an actual implementation. I have provided a data
design based on relational database, e.g. SQL, which should
work. Unfortunately I remain wedded to the better
performing hierarchical database model like DL/I, whose HIDAM
architecture has no implementation in Intel-based operating
systems. Basically as a "purest" I would rather pursue
providing a HIDAM equivalent at the operational level
supporting an application (interface) level which would work
unmodified in support of a relational equivalent.
As we have proposed an single interpreter/compiler with
underlying "smart" editor which makes up the body of the
Developer's Assistant (DA), we probably have another leg up
on Microsoft whose IDE will involve "compile only" as far as
we know. That implies the continued presence of "copy" and
"include" statements instead of their content in the editing
stage. Remember the interpretive mode automatically makes
the substitution of the content for the name associated with
the "copy" or "include". I won't bother you with the
productivity gains from the ability to exhaustively test
sections of source code of an as yet incomplete program.
Take that Microsoft.
Now for something of the "glee" part. If Microsoft succeeds in
this announced effort and other climb on the bandwagon to
produce their alternative declarative form, the open source
community, given it follows the same path, will with the
concepts and means we have pursued here have the means to
do away with Microsoft entirely. In short Microsoft's success
here will lead to its demise if more intelligently applied by the
open source community. Of course, we still have to get it by
Steven.:-)
=====================================================
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 [ 07 |
February |
2008 ]
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.
| 
