[M3devel] Think we need a new release.

[Jay K]

> 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.
I agree.But there is still work to do.Mainly increase portability and decrease platform-dependentness.    backend: such as via the existing M3x86, or LLVM     library: cooperative suspend   And/or at least update to newer gcc.  Improve debugging with stock gdb.  A C-generating backend should ease installation and integration into distributions and such, since there could be a more "tradtional" Csource.tar.gz...  - Jay > Date: Mon, 13 Feb 2012 11:31:04 -0600
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Think we need a new release.
> 
> 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.
> >
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120214/8a7f85a2/attachment-0002.html>