SCOUG-Programming Mailing List Archives

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

Date:	Fri, 17 Mar 2006 08:34:45 PST8
From:	<n_woodruff@bellsouth.net >
Reply-To:	scoug-programming@scoug.com
To:	<scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Off We Go......

Content Type: text/plain

Just my $0.02.

I think there needs to be a little less talk and a little more action.

The editor that you guys talk about, already exists.

Nathan
>
> From: "Lynn H. Maxson"
> Date: Fri, 17 Mar 2006 07:53:41 PST8
> To: "scoug-programming@scoug.com"
> Subject: SCOUG-Programming: Off We Go......
>
> "OK. I'm sure you have heard the saying "the road to etc. etc.
> etc."
>
> Steven"
>
> Unfortunately the saying never tells us about the road filled
> with bad intentions which certainly leads to the same place.
> Surely we need something more than intentions to determine
> the path taken. I had thought a road map based on existing
> tools and technology applied differently did that. Whether or
> not it does depends upon seeing "what" the road map leads
> to, which will determine the path taken.
>
> The road to either a compiler or interpreter begins at some
> point with an editor, a means of providing source. You can
> make it either a separate or integrated feature. IDEs tend to
> treat them as integrated even though "under the covers" they
> exist separately. "Smart editors", for example, perform
> syntax checking with colorization. Separated compilers and
> interpreters perform their own syntax checking normally
> without colorization.
>
> The question arises whether to produce an integrated product
> or a set of separate ones. The road map proposes integration.
> This means that syntax checking occurs only once. The road
> map proposes an even "smarter" editor which does semantic
> analysis. Having gone that far it further proposes to use a
> two-stage proof engine, which logically and optimally
> organizes source: the completeness proof. It then generates
> executable code either interpretive or standalone. It then
> uses a range of values entered for variables to generate test
> data as part of an exhaustive true/false proof.
>
> Now if the completeness proof logically and optimally
> organizes the source, you may overlook the implication that
> user does not pre-organize the source, a requirement
> currently of third-generation programming languages. That
> implies that the source may appear on input in any order, i.e.
> unorganized and at random.
>
> Now having an integrated IDE with a builtin interpreter mode
> means that the completeness proof must continually attempt
> to come up with a "true" condition, meaning that it has all
> that it needs to now generate executable code. If it it
> doesn't, then it must through its backtracking mechanism
> inform us of the "missing pieces" or "gaps" in logic.
>
> You may have forgotten in all this that interpretive implies
> "real time", i.e. immediate feedback. The completeness proof
> may overall indicate "false", but may also include partial
> truths, i.e. subsets of "true" segments. That means it can
> provide a "visual", i.e. graphical, result of the current state of
> the input source...in real time. As it is entered.
>
> That means that you can input code snippets as they occur to
> you, i.e. randomly. The tool will provide a visual, i.e.
> graphical, view of the current state of the input, what
> connections exist, which do not. The user then can pick and
> choose which connections he needs to change, i.e. where the
> tool indicates an unintended connection (a user logical error),
> or which he needs to make. Again the results of either
> appear in real time, i.e. immediate feedback.
>
> That's the result of integrating CASE tools with the
> completeness proof. You can brainstorm to your hearts
> content writing only specifications with the software saving
> you from first drawing "little" pictures, redrawing them until
> you get a big picture, and then writing the corresponding
> source code. You may enjoy spending your time in this
> manner to get to the ultimate source code, but why not begin
> with the source code to end with it? Particularly if the
> software will "instantly" rewrite it, i.e. reorganize it, based on
> changes in logic among segments.
>
> Now if you have a library of source code "snippets" to draw
> upon you can "list" them as input...by name. You could, for
> example, input an entire application system, a set of
> associated programs, make a change in the logic within one or
> more "snippets", have it reflected throughout immediately and
> then exhaustively tested.
>
> That to me reflects the intent of open source which
> empowers an individual to seek his own path...successfully. It
> does increase the scope of effort in which an individual can
> succeed or undertake in a practical manner. You do not
> require the services of 1400 testers, as a leading proponent of
> open source has used an an example of his own effort. Even
> with them or even 14,000,000 you may not get an exhaustive
> test.
>
> I don't really understand how you can "brainstorm" and get to
> a successful result any easier or more quickly. If you don't
> care how much time you spend or how much of your physical
> rework occurs during the course of it, then this tool is not for
> you. It's only for people who want to get the most for the
> least effort. Those who do not need not apply.
>
> I have yet to understand where I objected to plugins or to
> jEdit whose performance challenges my 1.67 GHz ThinkPad
> and overwhelms my 200 MHz Pentium Pro machine on which I
> do most of my work. I have no objections to plugins insofar as
> integrating them within the tool. That means I have their
> source in SL/I where plugging and unplugging is a matter of
> "specification" as part of the completeness proof applied to
> the source of the tool.
>
> At some point it will dawn upon you that I have no interest
> other than empowerment, a more complete enablement, of
> the individual developer. I see no reason to place an arbitrary
> upper limit on the scope of that empowerment. That doesn't
> prevent collaboration. In fact it enhances it without ever
> "endangering" the independence of the individual to go his
> own way.
>
>
>
>
>
> =====================================================
>
> 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".
>
> =====================================================
>
>
>
>

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

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