[M3devel] Think we need a new release.

[Daniel Alejandro Benavides D.]

Hi all:
In any case wondering whether he looses or not, fixing bugs is an important task in all computer programs, that's why ESC and others are important. But if you see those technologies back then were unsuccessful to find much use (because Modula-3 sources had not much RT errors, in Rd/Wr implementations, more in UI libraries), but just because doing annotations that restriction eases the test automation but costs are somehow seen as too high for doing that (even as relaxed in ESC/Java) respect of fixing them in the later stages (something they can compare because if they didn't use that tool they would know how much burden can be for doing that).
In reality people don't code faster but making painfully "slow releases" shows the "importance" of their work (and by that lack of productivity which is an symptom of the Crisis, and one of Objective of ESC).
GN asked why not produce code checkers that spend more computer time (even if they take extra time than night builds), well that's the reason, because they don't want to do that, they want short releases and bug-fixing by hand. 
That's why in the other hand Software Engineering is in Crisis, spending time in bugs fixes rather than writing code is another symptom Software crisis itself..
I will replay Greg Nelson lecture in U of Washington, I assume some principles are applied aside of checkers in systems development like in VHDL and some other tools:
http://www.uwtv.org/video/player.aspx?mediaid=1577083988

Of course there is a possible answer to that question, in the context of another Static checker, but my knowledge of that is it isn't operated  with that other checker or anything else (which was necessary in ESC case). This is if the program makes a big O() function I don't know.

Thanks in advance  



--- El lun, 13/2/12, Rodney M. Bates <rodney_bates at lcwb.coop> escribió:

> De: Rodney M. Bates <rodney_bates at lcwb.coop>
> Asunto: Re: [M3devel] Think we need a new release.
> Para: m3devel at elegosoft.com
> Fecha: lunes, 13 de febrero, 2012 12:31
> 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.
> >
>