search

AdaCore / ada-spark-rfcs

Platform to submit RFCs for the Ada & SPARK languages
63 stars 28 forks source link

Ada revisions should come out faster to keep Ada relevant #48

Closed Glacia closed 3 years ago

Glacia commented 4 years ago

Now that Ada 202x is around the corner i think it's appropriate to start talking about this.

Ada revisions take too long to come out, to the point it could affect Ada future and it's place in industry. It's time to admit that big revision every 10 years is not working anymore.

Popular programming languages have already moved on to a faster release schedule. C++ has a new revision every 3 years, Java has a new version semi-annually etc. It would be hard for Ada to remain relevant when all other languages evolve so fast. No one is going to wait for Ada 203x to have a borrow checker or pattern matching.

I'm not proposing anything, but i want to initiate a discussion on this topic. (I posted it here because Ada-comment sucks)

raph-amiard commented 4 years ago

Hi @Glacia,

While you should not take this as a commitment at this stage, know that we (AdaCore language design team) completely agree with you on the principle, and we are having discussions both inside of AdaCore and with the ARG to see what can be done about speeding the pace of evolution in some way, at the very least, by making features available as soon as they are ready in GNAT.

Now, a lot remains to be done, notably in terms of the scope of evolutions if we have shorter release cycles, knowing that our team is notably smaller than most of the other languages you mention, and Ada is a large language.

Lucretia commented 4 years ago

@Glacia I have mentioned this numerous times in various places and felt I was getting nowhere, to the point where I keep thinking, I can write an Ada compiler and extend it the way I want to, but that would take too long even though others would likely join in on the development. But I also keep thinking about developing my own language and compiler instead of working on Ada, it'd still be slow, but at least I could get something going fairly fast I just don't have the time left to wait for another Ada revision.

@raph-amiard I still think that creating a new Ada by taking the good bits and dumping the stuff that are considered bad experiments, mistakes, etc. is a good way forward and could:

  1. Attract more people.
  2. Be smaller and easier to modify, therefore creating faster revisions.

Especially, if we took experience from other languages, especially new ones.

I just feel that the ARG isn't going to budge on this and Randy certainly won't allow things to either be removed or certain features to be added due to what Ada is, an imperative/OO language.

Glacia commented 4 years ago

@raph-amiard Thank you for your reply, hopefully you guys can figure it out.

@Lucretia I agree with you, i thought about creating ada-like language too. But i gave up on this idea since it doesn't really solve a problem we have. Imo, the real answer is to accept that removing technical debt from language is actually good, even if it breaks backward compatibility. I don't think it's that bad for Ada anyway, considering that:

Lucretia commented 4 years ago

@Glacia I've said before that even if they break compatibility there are previous versions of the compiler which can still be updated with bug fixes.

jere-software commented 4 years ago

I was always surprised that the ARG didn't just leverage each version as breaking point when it comes to compatibility. If Ada X + 1 is not fully backwards compatible with Ada X, then that should be fine. People wanting new features will start the process of making their code compatible with the new version, but if that is too onerous, then they can just stick with the current version of the language. The current method of preserving backwards compatibility really hasn't worked positively. Only one compiler has come close to being fully conformant with the 2012 rules. There are two others that I know of that are working on it (Janus and ObjectAda), but it's already 2020 and they are still working on it. I don't feel that maintaining backwards comparability is really encouraging all the vendors or users to want to upgrade to the new version.

On the flip side, Rust successfully released an incompatible version along side the previous one and just let the users choose. I think that worked out great. You saw a lot of people who wanted to use the new version migrate their code so it would work with the new version. While they were doing that, they could continue to use the older version for current production.

Lucretia commented 4 years ago

I was always surprised that the ARG didn't just leverage each version as breaking point when it comes to compatibility. If Ada X + 1 is not fully backwards compatible with Ada X, then that should be fine.

Dead on. This is how Wirth did his, all his languages are versions of Pascal, similar syntax, just different. Pascal -> Modula-2 -> Oberon

The current method of preserving backwards compatibility really hasn't worked positively. Only one compiler has come close to being fully conformant with the 2012 rules. There are two others that I know of that are working on it (Janus and ObjectAda), but it's already 2020 and they are still working on it. I don't feel that maintaining backwards comparability is really encouraging all the vendors or users to want to upgrade to the new version.

Ding Ding Ding! ^^^^ This ^^^^

raph-amiard commented 3 years ago

This is out of the scope of discussion of this repo. Since the discussion has also died down for the moment, we'll just close issue. On a more positive note, and as said in the first messages, know that we're aware of the problem, and doing our best to make the language evolve in a more lightweight and regular fashion.