[M3devel] Think we need a new release.

[Rodney M. Bates]

This discussion reminds me of my first full-time software job.  The
division manager had a graph on his wall of bugs fixed per month.  He
considered a high fix rate evidence of success.  Some of us sat around
laughing about the incentives that created.

I also recall a wonderfully-written story about an aging programmer
who protected his job against the youth-is-smartest culture by keeping
carefully planned bugs in code that only he could fix.

I really do think the low level of activity in both the language
and its implementations reflects their having been done well to begin
with.  Unfortunately, I don't know how to sell that idea.  A lot of
people think like that division manager.

On 02/13/2012 08:06 AM, vintagecoder at aol.com wrote:
> Hello Daniel,
>
>> Agreed.  I can think of two reasons: adding "must have" stuff to the
>> standard library, and fixing bugs or improving library, compiler, or
>> runtime.  Note that "must have" should probably be evaluated in the
>> context of systems programming, which is what Modula-3 is for.
>
> For myself I tend to be very careful when it comes to "must have" in
> language design. If you feel the language spec is outdated or insufficient,
> then I think it's a dangerous, slippery slope to start adding features to
> the language even if they are a must have, without a standards committee.
> If people are not careful, they can turn a language that was designed well
> into a junk heap before they know it. The threat to the death of a language
> through inappropriate changes is far greater than the threat of death by
> lack of changes.
>
> If people agree the current spec is not sufficient, or wrong, it seems to
> me the first step is to form a language specification committee where the
> language can be carefully controlled- and this has to be from a purist
> view of the language with no concern for implementation and no "baggage"
> other than the existing language spec has to be respected- all the changes
> have to be aligned and harmonious with the original purpose and intentions
> and direction of Modula-3, otherwise what you said later about a new
> language comes into play. Optional features have to be clearly optional-
> extensions to the standard that don't make sense in the core have to be
> clearly deliniated and the spec has to be amended cleanly to separate core
> language, optional extensions, etc. The Ada specification is a good
> document to look at for examples of how to do this.
>
>> Even adding new platforms should not require bumping the version number
>> if it is the existing infrastructure that is being ported.
>
> Agreed.
>
>> There are loads of "greatest next thing" languages out there that you
>> have to re-learn every few releases.  Modula-3 is thankfully not one of
>> them.
>
> Agreed!
>
>> Want new stuff in the language?  Then you want Modula-3+ or Modula-4.
>
> Agreed again!
>
> People are so used to constant turmoil because of Linux. I come from a much
> different background and I value stability and evolution, not revolution.
> New is not necessarily good just like old is not necessarily bad. Good
> things pass the test of time and don't need constant changes. If we are
> talking about changing the underlying implementation without changing the
> language then of course this is fine and should not be held back. My
> concern is about letting the implementation drive the specification- I feel
> that is wrong, dangerous, and should be resisted.
>
> Many languages today are out of control. To grow a language properly is an
> extremely big challenge that has to be taken with a great deal of respect
> and concern.
>