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=-1.3 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ac39a12d5faf5b14 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-04-12 10:39:03 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!deine.net!freenix!enst!enst.fr!not-for-mail From: =?iso-8859-1?Q?M=E1rio_Amado_Alves?= Newsgroups: comp.lang.ada Subject: RE: Rant! (was) Development process in the Ada community Date: Fri, 12 Apr 2002 18:38:14 +0100 Organization: ENST, France Sender: comp.lang.ada-admin@ada.eu.org Message-ID: Reply-To: comp.lang.ada@ada.eu.org NNTP-Posting-Host: marvin.enst.fr Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: avanie.enst.fr 1018633143 22512 137.194.161.2 (12 Apr 2002 17:39:02 GMT) X-Complaints-To: usenet@enst.fr NNTP-Posting-Date: Fri, 12 Apr 2002 17:39:02 +0000 (UTC) Return-Path: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <87ads8sugb.fsf@deneb.enyo.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: comp.lang.ada mail<->news gateway List-Unsubscribe: , Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org Xref: archiver1.google.com comp.lang.ada:22440 Date: 2002-04-12T18:38:14+01:00 "Scripting languages like Perl and PHP encourage a development model which is mostly incompatible with Ada." (Florian) Do you mean the "write once never read" attribute of PERL (and likely of PHP as well) i.e. maintainability, short vs. long lived applications? How about when the requirements configure a short life span in the first place (as it is often the case today)? --MAA