>
> Assuming that number of statements, 6.6 million might apply to
> an operating system like OS/2 or Linux or (God-forbid)
> Windows. compiling an entire operating system as a single unit
> of work with complete synchronization of all source, having
> an executable form ready for regression testing in under 3
> minutes would set a new world record. Then again what the
> hell do I know about productivity?
Well, now that we have the right methodolgy it is great to
know that *I* will be able to understand 6.6 million lines of
code in under three minutes.
> I regret to inform you and Mr. Wilson that you cannot develop
> software absent a development process, regardless of how
> you choose to do it. That's why they call it development.
>
> Four of the stages--specification, analysis, design, and
> construction--offer a "natural" sequence or order. You can
> do them out of order. I've certainly experience my share of
> "program now, think later" programmers.
Well ALL of the graduate students in chemistry, physics,
engineering, biology, and astronomy who "develop" software
for their graduate degree know only about one of the
four stages: construction.
> Each in third
> generation and earlier programming languages involve a
> different written form, thus different source.
Written form for specifications?
Written form for analysis?
Written form for design?
What have you been smoking? University graduate research
has nothing to do with specification, analysis, or design.
Sooner or later.... Maybe.... If the software escapes from
the univerisity or national lab, then someone adept at
hearding cats might impose a real development process on
future versions of the software.
> Fourth
> generation, which doesn't include JAVA, involves only one
> written form, thus one source. Moreover the logical units of
> that source can appear in any order, i.e. unordered or random,
> on input, another advantage over third generation
> (procedural) languages.
>
> FYI, I did a google search on American Scientist, located your
> author, his article, and read it. As I advocate a development
> process similar to what he does in terms of taking advantage
> of available technology I don't see where we differ. He has
> just not had the advantage of reading my work.
Well, Dr. Wilson has a decent track record of publication
in the professional literature. We could go back and select
some of his articles to add to our reading list.
However, I would suggest that we first go to www.jedit.org and
follow the links to the jEdit user manual on Source Forge.
The manual is 130 pages long. The first half is pretty
much a user manual. The rest of the manual is a guide to the
guts of the system. What is not explained in the sixty odd
pages about the program data structures and API will certainly
be clairified by the 2000 pages of Java source.
I am so thrilled with the new methodology that will allow me
to understand this much Java code in under three minutes.
That is less time than it will take to read the sections on
the Plugin API in the jEdit manual.
--
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".
=====================================================
<< Previous Message <<
Return to [ 15 |
January |
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.
