Re: Which old version is best to use? don't trust Adacore anymore

[Brad Moore <bmoore.ada@gmail.com>]

On Friday, August 24, 2018 at 6:44:10 AM UTC-6, pat...@spellingbeewinnars.org wrote:
> Hi Simon
> 
> Actually I use pretty simple features and I am not experiencing bugs, I was just going on what has been said on this list.
> 
> This version of ctags works with Ada:
> https://github.com/rtyler/ctags
> 
> So far things are going well.
> 
> The FSF is very democratic-oriented. If this is a group effort, patches will probably make it past the gatekeepers if the patches are in the best interest of the community.
> 
> If your not surprised about the demo-ware comment, maybe you could chip in, your smarter than I am :)

To me, the Adacore decision to not support earlier versions of the Ada standard in the "Community" GPL version seems like a sensible one.

The community edition encourages one to use the current standard version of the language. If one doesn't want to use newer language features, don't use them, your code should still compile.

There is value in at least knowing that the code is forward compatible to the current version of the language standard.

The FSF version supports the current version as well as older versions of the standard.

I have some libraries I maintain, with portability in mind, and maintain different versions of the code, so that the code bases for the older language standards will compile with vendors who do not yet support later versions of the standard, but also allowing me to try out and take advantage of newer language features in the newer code bases. 

For code bases that are written for older versions of the language, I do like to know that that code still compiles with newer versions of the standard. If I want to test forward compatibility, I might use the community edition to compile the code. If I want to make sure say that the Ada 95 version of the code is not using any later versions of the standard, I compile with the FSF compiler with the Ada 95 flag set (Or alternatively, use the FSF compile with the Ada 2012 flag set). At least there is a way to get the best of both worlds,
which I very much appreciate.

I recall Robert Dewar saying something to the effect, the greatest thing about Ada 2012 is that it is built on Ada 2005. The greatest thing about Ada 2005 is that it is built on Ada 95. The greatest thing about Ada 95 is that it is built on Ada 83. 

There are a few cases of backwards incompatibility, but for the most part a program written in Ada 83 will still compile in Ada 2012.

I recently ported a larger system of Ada code from Ada 83 to Ada 2012, from one compiler vendor to another, from one target platform to another (different OS, and different architecture. I was pleasantly surprised how little effort it took to do this. (Changing OS, Vendor, language standard version, target architecture) 

I also recently ported a set of applications written in C++ to just a newer version of the compiler provided by the same vendor, on the same OS (but newer version), same architecture. It was very painful, and consumed a much larger allotment of time and energy (in terms of time and mancount). (Same OS, just newer version, Same target architecture, same compiler vendor, just newer version of compiler)

Your mileage may vary, of course, but my experience has been that Ada code generally has good portablility, when compared to some other environments.

I also find the FSF version of the compiler to be of good quality, and pretty stable. When a new version of the standard comes out, there is a time when the newer introduced language features might be buggy, or not fully implemented, but as time goes on, these bugs tend to get addressed. It's been my experience that older language features work similarly well between the Adacore GPL version, and the FSF version. 

Brad