Introduction
In v1, generally, almost any change which can break (any documented behaviour of) existing scripts are out of the question, for ever. This has led to crap being piled upon crap, and consequently a crappy language. For v2 I would like suggest to adopt a less restrictive policy. Consider the following version system,
a.b.c.d:
- a: Major breaking changes.
- b: Moderate to minor breaking changes.
- c: Non breaking changes (mainly feature additions).
- d: Bug fixes.
Typical b-changes could be,
- Fixing quirks such as += behaviour at the start of a line vs inside and expression.
- Removal of #ifWinXXX after optimising and recommending #if WinXX().
- Removal of unquoted dllcall arg types.
- Throw on error policies vs silent failures.
- BIF parameter ordering and behaviour.
- ...
Motivation
With such a policy we can fix old mistakes, which relieves the burden of the developer to carve every change in stone, which might also increase the joy and speed of development. We might move into v2.0 faster and without feeling that the fun times of making the language better are over. A language where interesting (and necessary) changes are possible is more likely to attract developers, which can lead to a better language with more users, which again might lead to more developers and users, and so on. More frequent and smaller breaking changes are more likely to carry users over from one version to another, compared to when making all breaking changes at once.
Epilogue
Even big companies with a large teams of developers, which charges big money from their users, eventually demands their paying customers to update their software because they cannot maintain old versions. Users of free software cannot demand that every new feature of the free software is compatible with their old without any efforts on their own part. New (and old) users shouldn't pay the prize of countless quirks and limitations, only for the purpose that some ancients script are still able to run on the new versions.
Cheers
.
.
