osfree.org

#735 From: "Tom Lee Mullins" <tomleem@...>
Date: Tue Aug 19, 2003 5:50 pm
Subject: Re: An E-Mail to IBM? bigwarpguy
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


--- In osFree@yahoogroups.com, "Lynn H. Maxson" <lmaxson@p...> wrote:
> Tom Lee Mullins writes:
> "I am/was hoping that IBM would support this open source
> project like they do with Linux and other open source projects
> they say they said they did (with this open source project,
> little chance of a lawsuit from SCO )."
>
> I speak as a "retired" IBMer after 36 years as an employee.
> IBM is a business, not a charity. If it supports open source
> projects like Linux, it does so because an opportunity for
> profit exists. If it doesn't support a particular open source
> project like this one, it doesn't because an opportunity for
> profit doesn't exist. It certainly doesn't want to support a
> non-profitable project, open source or not, if it competes with
> one in which it does profit.
>
> IBM global services makes a profit on closed source (Windows)
> and open source (Linux). If either ceased to remain profitable
> it would cease offering support. That's what happened to
> OS/2. Except in that instance it absorbed a billion dollars a
> year in losses over several years. To the profitable
> businesses in IBM who had to cover those losses from their
> profits and thus reduce their investments in their own future it
> didn't make sense.
>
> IBM is not an enemy. There are probably things we could
> propose successfully. We would make a better case if we had
> a business case profitable to both parties than one in which
> we came begging for charity. For instance, the SmallTalk
> group at IBM offers OS/2 users the ability to download the
> latest enterprise level version of their product for free for
> non-commercial use for an unlimited trial period. If we could
> get them to retrofit other dropped OS/2 products like PL/I and
> APL in like manner, you would have a chance to experience
> the prevalent myths with respect to C and its derivatives.

The purpose of the e-mail to IBM was not to beg for charity
(or anything else). I apologzie if that is how you interpret
what I had posted (I am not the greatest of 'writers' and do
not always convey what I am trying to say). I was suggesting
to them a possible alternative to just dropping OS/2 but also
helping those who wish to continue to use 'Warp' yet satisfy
a certain company.

BigWarpGuy

#736 From: "Lynn H. Maxson" <lmaxson@...>
Date: Tue Aug 19, 2003 6:43 pm
Subject: Re: Re: An E-Mail to IBM? lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Tom Lee Mullins writes:
"The purpose of the e-mail to IBM was not to beg for charity
(or anything else). I apologzie if that is how you interpret
what I had posted (I am not the greatest of 'writers' and do
not always convey what I am trying to say). I was suggesting
to them a possible alternative to just dropping OS/2 but also
helping those who wish to continue to use 'Warp' yet satisfy
a certain company."

Well, that's two of us who sometimes fail to communicate
properly. Not seeing the message you sent to IBM and to
whom you sent it, I could not possibly do more than speculate
on its content. I made no judgements on it for lack of
evidence.

I did, however, want to emphasize that IBM is a business and
that currently open source with respect to Linux does off an
avenue of profit even if indirectly, lower software costs
associated with the operation of their hardware servers. I
don't know your experience with the IBM OS/2 lan server,
which remains a quality product but unprofitable.

Serenity Systems managed to strike a deal with IBM while
Stardock managed to strike out. As a result we now have
eCS a client version of the OS/2 e-business server. Serenity
Systems, which is also profit oriented, will continue with eCS
as long as it remains profitable. It will discontinue it when it
shifts below the line.

I've made the arguments before that even if IBM gave up its
wholely owned portions of OS/2 source code, we, one,
wouldn't want to use it, and, two, we couldn't use it. To do
so means having the same level of necessary resources to
maintain it as IBM had, whose cost forced them eventually to
cut their losses. We can't afford to use IBM code "as is" with
the available tool set, even if that tool set itself is open
source and thus free.

In short if you do it with basically the same tool set as IBM,
you will have to have the same level of people resources and
skills. Serenity Systems has taken years now in the effort just
to replace the IBM installation procedure. It has taken years
because they couldn't afford the people resources to do it in
less time and receive an accecptable ROI, i.e. profit.

No one knows how the IBM/SCO conflict will turn out. That
argument centers over source code. I would argue that the
last thing I would want to do is "physically" copy it. I would
want to know what it "logically" does, i.e. use it for
documentation purposes only.

As I am only interested in its logical aspect as a source for its
physical implementation, we have more than enough
information as "source" for writing an open source OS/2
replacement for the "kernel" and eventually the "package".
For the moment IBM offers much of that information for
"free", including the OS/2 Toolkit 4.5. That documents the
OS/2 APIs. Those in turn determine the underlying kernel
logic. What you need is a handful of skilled people capable of
determining an efficient and effective kernel logic.

The truth is that we have all that we need from IBM. We
basically can remove IBM dependency from our future. That
dependency up to now has kept us fearful of cutting the cord.
We express anger at IBM for not offering more support for an
unnecessary dependency.

It's time that we faced up to whether or not we can do the
necessary work from within our own resources. If we can,
then forget IBM and let's get on with it. If we cannot, then
forget IBM and get on with something else. In either case
thank IBM for their support thus far, but no thank you from
this point on.

Cut the cord.

#737 From: "Tom Lee Mullins" <tomleem@...>
Date: Wed Aug 20, 2003 5:07 pm
Subject: Re: An E-Mail to IBM? bigwarpguy
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


--- In osFree@yahoogroups.com, "Lynn H. Maxson" <lmaxson@p...> wrote:
> Tom Lee Mullins writes:
> "The purpose of the e-mail to IBM was not to beg for charity
> (or anything else). I apologzie if that is how you interpret
> what I had posted (I am not the greatest of 'writers' and do
> not always convey what I am trying to say). I was suggesting
> to them a possible alternative to just dropping OS/2 but also
> helping those who wish to continue to use 'Warp' yet satisfy
> a certain company."
>
> Well, that's two of us who sometimes fail to communicate
> properly. Not seeing the message you sent to IBM and to
> whom you sent it, I could not possibly do more than speculate
> on its content. I made no judgements on it for lack of
> evidence.
>
> I did, however, want to emphasize that IBM is a business and
> that currently open source with respect to Linux does off an
> avenue of profit even if indirectly, lower software costs
> associated with the operation of their hardware servers. I
> don't know your experience with the IBM OS/2 lan server,
> which remains a quality product but unprofitable.
>
> Serenity Systems managed to strike a deal with IBM while
> Stardock managed to strike out. As a result we now have
> eCS a client version of the OS/2 e-business server. Serenity
> Systems, which is also profit oriented, will continue with eCS
> as long as it remains profitable. It will discontinue it when it
> shifts below the line.
>
> I've made the arguments before that even if IBM gave up its
> wholely owned portions of OS/2 source code, we, one,
> wouldn't want to use it, and, two, we couldn't use it. To do
> so means having the same level of necessary resources to
> maintain it as IBM had, whose cost forced them eventually to
> cut their losses. We can't afford to use IBM code "as is" with
> the available tool set, even if that tool set itself is open
> source and thus free.
>
> In short if you do it with basically the same tool set as IBM,
> you will have to have the same level of people resources and
> skills. Serenity Systems has taken years now in the effort just
> to replace the IBM installation procedure. It has taken years
> because they couldn't afford the people resources to do it in
> less time and receive an accecptable ROI, i.e. profit.
>
> No one knows how the IBM/SCO conflict will turn out. That
> argument centers over source code. I would argue that the
> last thing I would want to do is "physically" copy it. I would
> want to know what it "logically" does, i.e. use it for
> documentation purposes only.
>
> As I am only interested in its logical aspect as a source for its
> physical implementation, we have more than enough
> information as "source" for writing an open source OS/2
> replacement for the "kernel" and eventually the "package".
> For the moment IBM offers much of that information for
> "free", including the OS/2 Toolkit 4.5. That documents the
> OS/2 APIs. Those in turn determine the underlying kernel
> logic. What you need is a handful of skilled people capable of
> determining an efficient and effective kernel logic.
>
> The truth is that we have all that we need from IBM. We
> basically can remove IBM dependency from our future. That
> dependency up to now has kept us fearful of cutting the cord.
> We express anger at IBM for not offering more support for an
> unnecessary dependency.
>
> It's time that we faced up to whether or not we can do the
> necessary work from within our own resources. If we can,
> then forget IBM and let's get on with it. If we cannot, then
> forget IBM and get on with something else. In either case
> thank IBM for their support thus far, but no thank you from
> this point on.
>
> Cut the cord.

I had - in the past - asked IBM to open sourc Warp ver 3. The
e-mail I had sent them recently was not asking to open source
any version of Warp but to assist in the developement of
OSFree so that they could eventually drop OS/2 while supporting
a version of it for Warp users to migrate to and at the same
time comply with MS wishes (which could result in IBM being
able to pay less for their Win licences/products that they
'buy' from MS). By helping Warp users migrate to a platform
that does not require IBM's help to maintain, they could
drop what might be an unprofitable product (it is a shame that
IBM did not promote it as well as I had hoped they would - yet
they still support Warp by continuing to update the drivers
for it [the free ones and the ones that require Software Choice
to access]). I will try to clarify this to IBM even more and try
to appeal to their business sense.

Thank you for your opinions. They are truly appreciated. Through
it, I will update/re-word my e-mail/letters to IBM.

BigWarpGuy

#738 From: "Lynn H. Maxson" <lmaxson@...>
Date: Wed Aug 20, 2003 6:44 pm
Subject: Re: Re: An E-Mail to IBM? lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Tom Lee Mullins writes:
"I had - in the past - asked IBM to open sourc Warp ver 3. The
e-mail I had sent them recently was not asking to open source
any version of Warp but to assist in the developement of
OSFree so that they could eventually drop OS/2 while
supporting a version of it for Warp users to migrate to and at
the same time comply with MS wishes (which could result in
IBM being able to pay less for their Win licences/products that
they 'buy' from MS). By helping Warp users migrate to a
platform that does not require IBM's help to maintain, they
could drop what might be an unprofitable product ..."

In theory, as no one has even hinted otherwise, IBM could
offer the source for OS/2 for the PowerPC as open source.
Again in theory IBM could have offered it for the Intel
platform, freeing themselves completely from paying M$ and
others anything. Not doing so leaves open the possibility that
these costs didn't raise as much an issue as others like
ongoing maintenance. If you accept that, then you must
accept that IBM's giving it and the OS/2 community's accepting
the gift means the OS/2 community's willingness to absorb the
cost IBM decided against.

It's not a cost measured in dollars as that's the cost in the
business model for a for-profit enterprise like IBM and other
software vendors. Rather it's a cost common to both open
and closed source, the cost of needed people resources, i.e.
man-hours. Closed source pays for it directly in dollars while
open source pays for it indirectly as a form of subsidy,
afforded by getting pay from some other source. A
considerable portion of this subsidized cost comes from closed
source employers.

Unfortunately due to different organizational and project
management control between the "paid" workers of closed
source and the "volunteer" workers of open source, the
actual man-hours consumed for the same effort in large
multi-person projects is higher for open than for closed
source. The net result of IBM "giving" the OS/2 source and our
using it is that we would have to commit an even larger
amount of people resources to maintain it.

Designing a kernel replacement for an operating system like
OS/2 given the amount of documentation that already exists is
not difficult, just time and thus people consuming. However,
you only need a small number of skilled people, 6 or less.
Implementing the kernel design is probably not that difficult
either. So if this cost seems reasonable even for a small OS/2
community how did it get so out of hand for IBM?

The answer is that IBM's ongoing costs did not lie in the
kernel, but elsewhere. The elsewhere refers to the
"package" which is OS/2, those things which rely on the
kernel. Updating of components of the package, synchronizing
all their inter-dependencies, and the testing required before
releasing make up the bulk of the cost. It's not the kernel;it's
the package. IBM could give you the kernel. You couldn't
afford the package. You do not have enough skilled people
with enough volunteer time committed to a project schedule
in a competitive time frame to do the job.

In short you have a kernel with no place to go...except to
existing users who already have one.

I've made the point before that it's not the OS/2 kernel
replacement that is the issue. It's the OS/2 package
replacement. That in part caused the spin off from the
original "freeos" effort to the "osfree" one. While the freeos
people could argue endlessly about either a layered approach
on Linux or a uK, the osfree folks could get their teeth into
writing code, not simply talking about it, to replace the
package components, which in theory would run on either.

So you had the situation where the kernel folks who had the
least to do in terms of writing source doing the most talking
while the package folks stopped talking in order to start
working. The net result was the kernel folks stopped talking
and the package folks stopped working. The forums became
quiet except for the occasional inquiry about whether they
were active or not.

At some point we will have to discuss OS/2 as a "system"
replacement and not simply a kernel replacement.
Unfortunately the phrase "operating system" can mean
anything from a uK on up. OS/2 as a system, as a package,
lies quite high on the "on up" scale. No amount of movement
lower down in kernel development has any meaning unless it
leads to the movement of the entire system (package).

Thus you have one cost, the kernel replacement, which the
community can afford, and the other, the package
replacement, for which IBM threw in the towel. That's a
reality.

When I made the original Warpicity Proposal at WarpStock98
in Chicago it had three parts: (1) an organization in which the
OS/2 members acted as a board of the whole, (2) a staffing,
and (3) a methodology. The purpose of the methodology lay
in bringing down the people resources, thus the cost, required
to maintain an OS/2 replacement package.

I made the point then as I have continually made it even up to
this message that the last thing we wanted was for IBM to
release the source code for OS/2 for our use as it would bury
us even more devastatingly than it had IBM. We needed to
understand the logic to insure compatibility, but given the
completeness of the OS/2 toolkit plus available documentation
we didn't need the source.

At this point we don't need IBM. We need some means of
bringing the people cost within our capacity. We can't do that
with the tools currently in use in open source as they employ
the same methodology that has seen as many (and perhaps
more) open source projects falter as closed source.

I guess I could end this with a reminder that you have to be
careful what you ask for as you may get it.<g>

#739 From: Dale Erwin <daleerwin@...>
Date: Wed Aug 20, 2003 6:39 pm
Subject: Re: Re: An E-Mail to IBM? dale_erwin
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Lynn H. Maxson wrote:
>

<< a lot >>

>

Lynn,

You have written several very lengthy articles to this list about what
we, the OS/2 community, can't do. Since you offer nothing saying what
we CAN do, it sounds like you are saying we should give up. Is that
your stance in this matter?

I am not nor have I ever been an IBM employee. I did work for about a
year and a half on a contract for IBM Global Services from 1999 to 2001.
My perception of IBM is that they are, internally, very bureaucratic and
strapped with all the waste that a bureaucracy thrives on. I would venture
to say that a smaller, tightly-run company could replicate an IBM project
for half the cost. Of course, almost all large corporations fall into this
category, not just IBM.

--
Dale Erwin
Salamanca 116
Pueblo Libre
Lima 21 PERU
Tel. +51(1)461-3084
Cel. +51(1)9743-6439

#740 From: "Lynn H. Maxson" <lmaxson@...>
Date: Wed Aug 20, 2003 9:37 pm
Subject: Re: Re: An E-Mail to IBM? lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Dale Erwin writes:
"You have written several very lengthy articles to this list
about what we, the OS/2 community, can't do. Since you
offer nothing saying what we CAN do, it sounds like you are
saying we should give up. Is that your stance in this matter?
..."

What we have here is a failure to communicate. Using your
estimates about bureaucratic waste in IBM, the OS/2
community hasn't the resources for even have that cost,
certainly not in money (at one-half some $250 million per
year) nor in aggregate, dedicated skilled people resources.

The problem lies not in the bureaucracy you mention but in
the one you do not: the methodology along with the
languages and the tools used. You do it the same way, you
use the same languages and tools, you get the same costs.
You get them and every OS/2 ISP that has fallen by the
wayside got them. For the OS/2 community to commit itself to
following in those footsteps I offer a paraphrase of "imitation
is the sincerest form of failure".<g>

I don't want us to fail. In my mind nothing kills incentive like a
success in an initial stage sets up for failure in the following.
What you want is not only to succeed initially but to do so in
a way that you succeed in what follows as well. The answer
lies in not imitating the failures: don't do it like they did it. If
you do, you will fail as well.

That simply says you do it differently...from the beginning so
that you don't have to undo what you have done. A small
community like ours has to guard against waste.

Now how do you do it differently? For one thing you get off
third generation programming languages, object-oriented or
not. You have five stages of software development: (1)
specification, (2) analysis, (3) design, (4) construction, and (5)
testing. Third generation languages require that you do each
of these manually along with the manual translation required
to go into a successive stage.

In a fourth generation language based on logic programming
only two stages, specification and testing, require manual
effort. The other stages (analysis, design, and construction)
get done by the software. Moreover the other stages will
accept unordered input from the first. So you don't even have
to manually order the input. If you use a form of logic
programming using predicate logic, the software based upon
the data rules on input can create an exhaustive set of test
data. Thus you have no use for something as commonly
accepted now as beta testing.

So you need only one language and one tool, not four
different assembly languages (masm 5.1, masm 6.0, alp, and
wasm), three different C compilers (VACPP, Watcom, and
GCC) where one of them comes in a package with 50 different
utilities each which a language of its own. and a host of
different other programming languages (Python, PHP, Maude,
etc.).

It short you can make it difficult or hard for yourself. If you
choose to make it hard despite all the warnings about doing
so, then so be it. I personally want to have the proper tools
in place as the first step before undertaking even the writing
of a kernel.

Contrary to your statement I have consistently said that we
can change our tool set which will have the greatest effect
on insuring our success. I said it in Chicago in 98, repeated it
in 99, have continued to repeat it since then, and will continue
to do so into future tomorrows. The current tool set and the
ongoing cost associated with using it forced IBM to back off
from OS/2. Our using them will cause us to back off even
sooner.

#741 From: "kidmarc_arcor" <kidmarc@...>
Date: Thu Aug 21, 2003 12:16 am
Subject: Re: An E-Mail to IBM? kidmarc_arcor
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


--- In osFree@yahoogroups.com, Dale Erwin <daleerwin@i...> wrote:
>
> You have written several very lengthy articles to this list about
> what we, the OS/2 community, can't do. Since you offer nothing
> saying what we CAN do, it sounds like you are saying we should give
> up. Is that your stance in this matter?

Hello Dale,

You may want to go through the archives and read what Lynn has
proposed. His points do include what "we" can do.

Lynn is proposing that creating an OS/2 replacement has to be better
than the existing one (uK kernal with OS personalities side-by-side),
and in doing so we must not adapt the method the others (both closed
and open source) have in creating one. A starting point is the tool
set.

It [tool set], in short, must account for what is lacking -
programming hours. The tool set must be efficient to do the work of
thousands of programmers (minus the mistakes, typos <g>). The tool set
must allow people to do what they do best - design/writing
specifications, and take those specifications and allow the computer
to do what it does best write/compile the program.

Here are some old links for clarification:

http://www.os2ezine.com/v4n3/wright.htm

http://www.os2voice.org/VNL/past_issues ... newsf2.htm

http://www.scoug.com/warpexpowest/Prese ... icity.html

Peace
marcus

#742 From: Dale Erwin <daleerwin@...>
Date: Thu Aug 21, 2003 2:02 am
Subject: Re: Re: An E-Mail to IBM? dale_erwin
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Lynn H. Maxson wrote:
>
> Contrary to your statement I have consistently said that we
> can change our tool set which will have the greatest effect
> on insuring our success. I said it in Chicago in 98, repeated it
> in 99, have continued to repeat it since then, and will continue
> to do so into future tomorrows. The current tool set and the
> ongoing cost associated with using it forced IBM to back off
> from OS/2. Our using them will cause us to back off even
> sooner.

OK, this is more like it. Maybe I missed part of it. I got the part
about not having the proper tools, and I whole-heartedly agree, but I
don't recall seeing before the part about being able to get them. How
do we go about acquiring the proper tool set? I've not seen any of
these languages of which you speak. All the fourth generation languages
I've had experience with were quite different from what you describe.
How about some specifics... or have you already posted that in some prior
article? I'm relatively new here, but I'm interested in doing this if
it's at all doable.

Are you thinking of development on some other platform?

--
Dale Erwin
Salamanca 116
Pueblo Libre
Lima 21 PERU
Tel. +51(1)461-3084
Cel. +51(1)9743-6439

#743 From: "Lynn H. Maxson" <lmaxson@...>
Date: Thu Aug 21, 2003 8:08 am
Subject: Re: Re: An E-Mail to IBM? lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Dale Erwin writes:
"OK, this is more like it. Maybe I missed part of it. I got the
part about not having the proper tools, and I whole-heartedly
agree, but I don't recall seeing before the part about being
able to get them. How do we go about acquiring the proper
tool set? I've not seen any of these languages of which you
speak. All the fourth generation languages I've had
experience with were quite different from what you describe.
How about some specifics... or have you already posted that in
some prior article? I'm relatively new here, but I'm interested
in doing this if it's at all doable.

Are you thinking of development on some other platform?"

I've only focused on three programming languages: LISP, APL,
and PL/I. They are pre-1970 or pre-C languages. These three
contain all the data types, features, functions, and more than
all other programming languages put together. Basically I
have worked on a synthesis of all three: selecting the syntax
and data types of PL/I, the operators and symbol set of APL,
and the list aggregate and operators of LISP. Together you
have a "universal" specification/programming language.

To this mix of third generation languages you need to add the
fourth generation capabilities of logic programming. Instead of
the clausal logic of Prolog you use predicate logic. Predicate
logic allows the range of values of a data variable in its
declaration: "for all x where x ....". This allows the exhaustive
true/false proof of the two stage logic engine used
throughout logic programming to automatically generate as
well as test the necessary test data.

Your experience with fourth generation languages may come
up short because, one, they don't support the full range of
data types and operators proposed, and, two, they exclude
the use of third generation expressions, namely the
assignment statement. As every fourth generation
implementation must resolve into assignment statements,
which basically represents what occurs within machine
instructions, no "existing" fourth generation language is
capable of completely producing itself. If it can't produce
itself, then it has no possibility of becoming a universal
specification language.

A universal specification language is capable of expressing not
only itself (self-defining) but also its enhancements
(self-extensible). As a result it encompasses all of formal
logic operators and operands (data). That means it also
encompasses all of the language generations which preceded
it. The net result is that you only need one language
regardless.

As it turns out you only need one tool, tentatively named the
Developer's Assistant, which itself is written in the language.
One tool. One language. Both universal in application. Both
open source.

It's doable as it relies on what already exists. There's no new
software technology required. It's an extensive reworking of
existing technology.

Finally it is a specification language that supports both
machine-dependent as well as machine-independent
specifications. As Intel kindly shows us in its language
reference manual for the Pentium family of processors every
machine instruction has an HLL form. Thus you can enter
entire instruction sets of any platform, machine-dependent
specifications, as unordered input mixed with
machine-independent specifications. Ultimately then you have
the means of transforming any higher level
machine-independent specification into a set of lower level
machine-dependent specifications: code generation.

Any platform for which you have its machine-dependent
specifications you can use to translate the same set of
machine-independent specifications. Thus you have
cross-platform support.

Now this doesn't occur automatically until you have written
the software that does it. For that you have to start from
scratch. Therein lies the rub. Therein also lies my emphasis
on producing such a language and tool, prior to implementing
but not designing, an OS/2 kernel replacement. I should also
mention the lack of any need for makefiles, linkage editors,
and utilities like grep, awk, cvs, and a host of others. It's one
language and one tool. That reduces the learning curve
significantly.<g>

#744 From: "Lynn H. Maxson" <lmaxson@...>
Date: Sat Aug 23, 2003 8:18 pm
Subject: Re: Re: An E-Mail to IBM? lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Dale Erwin writes:
"All the fourth generation languages I've had experience with
were quite different from what you describe. How about
some specifics... "

I probably need to offer more meat for these bones. All
fourth generation languages, all AI, all neural nets, all SQLs (a
fourth generation language), all software based on logic
programming use a two-stage proof engine. The first is a
"completeness" proof and "if true" (complete) followed by a
second "exhaustive true/false" proof.

While SQL is probably the most popular fourth generation
programming language most people using it probably don't
regard themselves as programmers. Programmers are used to
saying "what" they want done by writing "how" to do it. SQL,
like everything else based on logic programming, reduces this
to a "what" by the programmer, leaving it up to the software
to determine "how".

Now Prolog probably dominates the field of fourth generation
programming languages. In 1988 I acquired a DOS program
called Trilogy, a fourth generation language. While they
differ significantly in syntax, in my opinion one of the major
drawbacks of Prolog, they also differ in the form of formal
logic they use. Prolog uses clausal logic. Trilogy uses
predicate logic. As I mentioned before the primary difference
lies in predicate logic's ability due to automatically generate
test data to the rules associated with its data declarations as
part of the exhaustive true/false proof stage.

With these mentioned and now set aside the one major
advantage of logic programming lies with its ability to accept
unordered input of program units. These program units can
range from a single statement, e.g. a rule instance or a data
declaration, up to any named statement assembly, e.g. a
procedure. Thus while the order within a statement assembly
remains fixed no order is imposed on input of statements and
assemblies. It is left to the completeness proof to determine
the necessary (complete) and optimal order.

Now here you have a primary difference between third and
fourth generation language. In third generation languages the
programmer must manually order the input prior to processing
which in fourth generation languages gets done by the
software. That means that any change to the logic impacting
the hierarchical order is left up to the software, not the
programmer, to rewrite.

Now understand that every programming language is a
specification language, because it has a compiler or
interpreter to produce executable code, but that every
specification language is not a programming language,
because it may not. Also understand that after the
specification stage the two purposes of analysis and design
are completeness (analysis) and order (design) prior to
construction (coding).

If the software as part of the completeness proof effectively
does analysis, design, and construction, then the programmer
shifts roles from the construction stage, where third
generation languages force him to reside, to that of a
specifier in the specification stage. Moreover you can write
each specification, consisting either of statements or
statement assemblies, in the order in which they occur and
submit them without concern for their overall order, i.e.
unordered.

Now you have taken four manual stages--specification,
analysis, design, and construction--and reduced them to one,
specification, leaving it up to the software to do the other
three, which includes the writing of the order and its rewriting
when when changes occur.

Now all this occurs because logic programming accepts
functionally independent units smaller than a procedure on
input: anything from a statement on up. It also accepts them
in any order, in effect unordered. This means that you can
enter changes into a system, brought on by the dynamics of
the user environment, essentially at the rate at which they
occur. You can do this without any concern for the rewriting
which must occur as this remains a software responsibility.

Now SQL is a poor example because it is a "structured" query
language of the form "select....from....where..." where this
order is imposed, although no specified order is imposed within
these clauses. It doesn't take much imagination to see that it
is structured by choice, not necessity.

You can even retrofit this two-stage proof engine onto third
generation languages like C. That means you have to change
some of the restrictions in C, but you can change them while
still offering backward compatibility with existing C programs.
Let me suggest the following changes.

First, eliminate the use of nested (internal) procedures. The
hierarchical relationship exists through internal references
from the calling to the called procedure. This logical
connection does not require a physical counterpart. The
software can function just as well with a set of unordered
procedures, ordering them on the basis of their internal
references.

Second, eliminate the restriction of "main" as the name of the
main procedure. Only UNIX still uses OCL which is the only
reason this restriction exists to begin with. Allow every
procedure to have a programmer-assigned name just as every
sub-procedure does now.

Third, shift the C compiler from single-pass to multi-pass.
This makes unnecessary the use and writing of "void"
statements except where a called procedure does not
terminate with a return code.

Fourth, eliminate the "implementation" restriction limiting a
compilation unit to a single object module. There's no reason
that a single compile cannot produce multiple object modules
based upon the hierarchical orders determined as part of the
completeness proof. You can have multiple "main"
procedures, procedures not referenced from within any other.
In this manner through a single compile of changed source you
can synchronize all affected modules. These could number
from one to an indefinite number. The compiler can maintain
a list of "main" hierarchies, iterating through them one at a
time until exhausting the list.

In doing all this you eliminate the need for linking, for
makefiles, and for versioning (CVS). In doing all this you
haven't had to change a single line of code of existing C
programs. You can apply this to every other third generation
language.