wrote:
> Steven,
>
> You were doing well with respect to Uncle Lynn until "The
> question is how much, if any, of the details the tool will
> expose to the developer. Lynn's goal appears to be for the
> development system to be essentially black box." I take it
> from the prison guard in Hud that, "What we have here is a
> classic failure to communicate."
>
> I propose one open source, self-defining, self-extensible,
> universal programming/specification language. I further
> propose one open source tool written in the language. The
> tool contains within it an open source database manager,
> ultimately also written in the language. At the successful
> conclusion of the completeness proof of the two stage proof
> engine the "programmer" has the option of producing any of
> the different output forms available from existing CASE tools,
> applicable to both the tool and language source.
Which is all well and good when there is an existing code
base to build on. And it is also short sighted with respect
to the DESIGN stage of a project before any code is written.
> That plus
> the fact of the "backtracking" mechanism builtin to every
> fourth generation two-stage proof system, which will not only
> show you the logical paths in either the tool or language
> source, but also the reasons for any particular branch off any
> path.
OK, we get a proof that the logic is correct. However, just
because the logic is correct does not mean that it really
applies to the situation at hand. Go ahead and try and use
the procedures that run an oil refinery to try and run an
automobile assembly line.
> Granted that the software is responsible for several orders of
> magnitude more of automatic writings of analysis, design, and
> construction than current "manual" IDEs based on
> third-generation languages. Thus the programmer can just do
> what the software cannot and the software what the
> programmer need not. You may regard this shift to software
> generation of documentation as something of a black box, but
> I regard any system, particularly any software development
> system, capable of documenting itself fully and thus lending
> itself to easier learning and understanding by the
> "programmer" less of a "black box" than current IDEs.
Clean documentation AFTER the fact is a great help. But the
drawings on the whiteboard are the important first steps that
you should also keep around to document what really happened
during the design brainstoming. I hope that Sheridan's pictures
from last month's meeting came out.
> Sometimes we forget that the purpose of open source lay in
> freeing the individual from dependence on other sources
> should he or she decide to deviate in some other direction.
> You can't have that freedom if you perceive the source either
> in volume or complexity beyond your capabilities either in
> terms of skill, available time, or effort. You don't have to
> have Greg count the number of statements in jEdit or VIM or
> the build structure of Open Watcom to know how daunting
> the task appears of, one, understanding, and, two,
> successfully undertaking changes on your own.
Let's take a look now at an open source project from my field
of chemical engineering. Process flowsheet simulation software
combines rigorous models for various chemical unit operations
such as pumps, compressors, heat exchangers, distillation
towers, furnaces, chemical reactors, etc. All of the units
need to be solved together for a complete chemical plant or
refinery specification.
A few years ago, a student at the University of Calgary did
a simulator called Sim42 in Python for his thesis. As funded
university research, the resulting copyright for the code was
licensed with terms similar those for BSD. In addition, there
was significant industrial involvement from the company that
produced the thermodynamic database used by the simulator.
The University set up a foundation with the industrial partners
to continue the development of Sim42. The foundation lasted
about a year. This was long enough for Sim42 to reach version
2.0. However, because of the BSD style license the industrial
partners were not obligated to put their contributions back
into the simulator.
So what does Sim42 have to do with Open Watcom?? Well, a month
ago discussion picked up on the Sim42 mailing list about reviving
an open source process simulator. And the talk about a new open
source simulator has focused on: SPECIFICATIONS. And the draft
for the specifications is written in ENGLISH. The discussion
so far has tended to a new language (Free Pascal), a new database
engine (Firebird), and a GUI framework (Lazarus). The original
Sim42 had no GUI framework and used an ad-hoc internal data
structure for the database.
So having the code is useful. Generating the documentation
from the code is useful. But when you come right down to it,
natrual language specification and simple diagrams have a LOT
going for them when developing open source programs.
--
Gregory W. Smith (WD9GAY) gsmith@well.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".
=====================================================
>> Next Message >>
Return to [ 17 |
March |
2006 ]
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.
