Re: Build language with weak typing, then add scaffolding later to strengthen it?

["Randy Brukardt" <randy@rrsoftware.com>]

"Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message 
news:87a8wnu3v0.fsf@adaheads.sparre-andersen.dk...
> Randy Brukardt wrote:
>
>> We don't. As with all old languages, it's political. We can't remove
>> old features (as that would break existing programs),
>
> But aren't the existing programs being compiled with compilers for the
> appropriate (old) versions of the language?

Until they need some part upgraded. For example, I'm (slowly) moving my web 
and mail servers from Janus/Ada on a W2K machine to GNAT on a new Linux 
machine. It's likely that I'll want/need to use some new capabilities when 
that's done. Changing lots of code because someone didn't like some existing 
feature is unappealing.

Similarly, I know that pretty much any Ada code that I have will still work 
if I need it in some program. Reuse is a valuable benefit of Ada, and that 
cuts across time as well as projects.

> How large is the actual benefit of maintaining practically full
> backwards compatibility?

It's hard to say. Some people (Robert Dewar in particular) think we abandon 
compatibility far too easily in the ARG as it is. And we don't do that 
lightly as it is. He claims that compatibility issues discouraged many from 
using Ada 2005; the aspects and preconditions in Ada 2012 were enough to 
break through that barrier, but it would be easy for Ada 202y to fall into a 
similar trap (not enough important to make up for incompatibilities).

> Isn't it more a matter of not being able to agree on what is important
> to keep, and what isn't?

No. There definitely is a group that think that almost any incompatibility 
is unacceptable. And someone is using every core feature (even stuff like 
generic formal in out parameters); how do you decide who's code is not 
important enough to support.

>> I'd think it's getting close to time to start over with Ada, not
>> because of any major problem, but simply the accumulation of
>> cruft. The problem is that if you think its hard to convince people to
>> use Ada with all of its track record, try doing that with a new
>> language with no record. So I don't think there would be much of a
>> market for that.
>
> Isn't that in itself an argument for letting Ada 2020 be a major change,
> where backwards compatibility isn't as important as using our current
> knowledge to improve the language?  I wouldn't want an Ada 2012 program
> to be accepted by an Ada 2020 compiler with a different meaning, but I
> wouldn't mind it if the Ada 2020 compiler told me that I have to do
> things differently in Ada 2020.

Sure, it's an argument. But what's typically happened when languages made 
big breaks is that the new version is much less used than the original. That 
goes all the way back to Algol 60 vs. Algol 68. I doubt Ada could survive a 
much less used version.

                                           Randy.