From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,577c9f9c0cdd76d
X-Google-Attributes: gid103376,public
From: kilgallen@eisner.decus.org (Larry Kilgallen)
Subject: Re: Help help.. please.i am totaly new in ada programing
Date: 1999/11/03
Message-ID: <1999Nov3.081300.1@eisner>#1/1
X-Deja-AN: 543938627
References: <7vbtof$de9$1@oceanite.cybercable.fr>
 <38199224_3@news1.prserv.net> <3819A44A.9F5E6B97@maths.unine.ch>
 <7vhh53$81f$1@nnrp1.deja.com> <381DE427.4A04F864@maths.unine.ch>
 <7vml31$pk0$1@nnrp1.deja.com> <381F0B97.8DBCFFC8@maths.unine.ch>
 <7vnddp$ck6$1@nnrp1.deja.com> <7vnf6c$e03$1@nnrp1.deja.com>
 <7vnhov$g0k$1@nnrp1.deja.com> <1999Nov2.195237.1@eisner>
 <7voc8j$3g1$1@nnrp1.deja.com>
X-Trace: news.decus.org 941634785 28964 KILGALLEN [216.44.122.34]
Organization: LJK Software
Reply-To: Kilgallen@eisner.decus.org.nospam
Newsgroups: comp.lang.ada
Date: 1999-11-03T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <7voc8j$3g1$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes:
> In article <1999Nov2.195237.1@eisner>,
>   Kilgallen@eisner.decus.org.nospam wrote:
>> If it were a GNAT port, the one thing not possible without
>> scripts would be programmer portability.  It would not look
>> like GNAT on other platforms, which to some people would be a
>> considerable drawback.
> 
> 
> No, you very much miss the point, it is *program* portability
> that is the issue. Many large programs exist as a complex set
> of scripts, and any development environment which requires these
> scripts to be completely rethought is crippled in my view.

That would seem to be the case with my MMS files that run DEC Ada
if I were to switch to GNAT :-).  Yes, porting programs from machine
to machine is easier with the same build environment everywhere.
As someone who tends to need OS-specific interfaces, it is probably
one of the smaller problems I face in such porting.

> Also, real environments require total trackability. It is fine
> for people to point and click around, but the record of their
> points and clicks must be integrated into the configuration
> management system.

Audit trails are a different matter from text-based control mechanisms.
If you find a serious Macintosh user they probably have the Retrospect
backup product.  It has a highly refined audit trail (not called that)
which is accessed in a fully GUI fashion much better than the VMS use
of BACKUP/JOURNAL/SELECT.

> I don't begin to regard Think Pascal as a viable complete
> solution for the development of large projects (millions of
> lines with thousands of files) with strict configuration control
> and management of multiple development branches.

No, but it serves as a reference for GUI-based development.  Someone
with committment to a product (unlike Symantec) and a market for that
sort of GUI-based development (unlike ACT I presume, given the strong
emphasis on platform portability) _could_ build a highly useful tool.
But like many things in software, there is a question of how many are
interested.

I believe the original contention to which I was responding was
that it was technically impossible, as distinguished from not a
viable economic proposition.

Larry Kilgallen