I know PM does not like the word 'stability' for language development,
and I have just posted a response to Wendell Hatcher's question
justifying Patrick's approach.
However, some other questions arose when I was considering 'usability',
which Patrick sets as a goal for Rakudo *, as opposed for 'stability'.
I have already written an application in Rakudo (alpha) to process data
in my commercial field and to indirectly obtain graphical output, and
the results were published in a banking journal (in Russian). So in a
sense, Rakudo alpha was usable.
The problem is that each time I want to reuse the program, I need to tweak some
part to handle changes in spec.
I want to be able to re-run the application each month to handle
incremental data, but before I can hand this off to the operations
people, there needs to be some form of stability in the areas that are
utilised in the application.
This is a very small real-world application. But in order for more
real-world applications to be written, there has to be some assurance
that once the code is working and tested, it can be left unattended for
some reasonable period of time, eg., a year. Without some form of
assurance about the type of maintenance, it is not possible to justify
allocating resources to 'real-world' applications, and thereby provide
the feed-back needed by language designers.
Suppose we define a domain of stability as syntax/functionality/features
that will not be changed until a milestone is reached, with the
guarantee that if the language specification changes before then,
backwards compatibility will be retained so that the
syntax/feature/functionality will continue to function without a need to
change it or the surrounding code.
Perhaps different levels of stability could be defined for different
domains, eg.,
'fossilized' : syntax/functionality/features set in stone for the
lifetime of the language, eg., until perl7.
'stable': syntax/functionality/features are stable until the next major
review, eg., perl6.1
'organic': ... may change but modifications will be flagged with a
deprecation notice and a deadline after which
syntax/feature/functionality will not be supported in current form.
'experimental': subject to change at will, to be avoided if 'stable'
code is needed.
In this way, subsets of the language can be defined to have different levels of stability,
thus allowing developers to choose how to write code and to know what
level of maintainability will be needed.
It seems to me this sort of approach is consistent with the whirlpool /
strange attractor concept of language design, whilst addressing the
desire of commercial developers to be able to predict the resources
needed to write and maintain code.
- Stability domains in rakudo * Richard Hainsworth
-
