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.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.58.54.97 with SMTP id i1mr930897vep.40.1386779805264; Wed, 11 Dec 2013 08:36:45 -0800 (PST) X-Received: by 10.50.73.132 with SMTP id l4mr546955igv.0.1386779805221; Wed, 11 Dec 2013 08:36:45 -0800 (PST) Path: border1.nntp.dca3.giganews.com!backlog4.nntp.dca3.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!ie8no8780136qab.0!news-out.google.com!9ni7231qaf.0!nntp.google.com!ie8no8780132qab.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 11 Dec 2013 08:36:43 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=86.140.183.44; posting-account=pmkN8QoAAAAtIhXRUfydb0SCISnwaeyg NNTP-Posting-Host: 86.140.183.44 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Compiler Revisions Should go Out As Well as Going Up. From: Austin Obyrne Injection-Date: Wed, 11 Dec 2013 16:36:45 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Original-Bytes: 4287 Xref: number.nntp.dca.giganews.com comp.lang.ada:184199 Date: 2013-12-11T08:36:43-08:00 List-Id: On Wednesday, December 11, 2013 1:04:41 PM UTC, Simon Clubley wrote: > On 2013-12-11, Austin Obyrne wrote: > Decoded= , I am saying here that there is a tendency in my opinion to view new > com= piler versions in a hierarchal sequence that tacitly suggest one should > a= lways use the most recent compiler version. I don?t think this is right and= > instead older compilers should still be kept in hand as befits the users= ? > needs for specific applications without any suggestion of being outdate= d. > Very often there is nothing to be gained except a whole load of troubl= e in > changing to newer compiler versions of the same language. Actually, = I don't use the most recent compiler versions. However, I also don't use co= mpiler versions from around the late 1990s. I do quite a bit of embedded wo= rk as a hobby and hence I have multiple gcc toolchain versions installed fo= r the various embedded environments I use. About every couple of years or s= o, I go through a sequence of upgrading the embedded and native gcc version= s so that the oldest version is dropped and a more recent version than the = most recent version I was using is installed. That's not the very latest ve= rsion at that time, but a version that's been out for a while and is percei= ved as a stable version. I also use the same compiler toolchain versions to= compile code written in other languages such as C and C++ so that's also a= factor as well as well as the fact the packages being compiled have their = own minimum required gcc versions. Simon. -- Simon Clubley, clubley@remove_= me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a= 21st century world I must confess to being a bit blinkered in my outlook possibly because of m= y preoccupation with cryptography but I am trying hard also to empathise wi= th you guys who are up front at the cutting edge of all the diverse applica= tions to Ada. My overview (admittedly as a layman) is that the current 'one compiler does= all is' modus operandi is extravagant in many cases that do not need the u= pdate. I use a concept of mutual databases in my cryptography which if you think a= bout is also very prevalent in commerce, military. financial situations. In essence then the question boils down to this? would Ada be better deploy= ed by becoming fragmented to suit a wider scope of needs instead of one all= powerful compiler that fits all cases but with considerable redundancy. = =20 I repeat " The custodians of the langauge will no doubt have given much tho= ught to this"=20 Given that it is still early days in IT (even half a century is quite samll= compared with other sciences and technologies)there is still vast changes = to come in fighting malaware infections, identity theft, information securi= ty etc. Ada programming will see much more change still to come in my view - it is = not ridiculous to suggest rationalising this change as I am suggesting here= . Austin O'Byrne