<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
> I really do think the low level of activity in both the language<br>> and its implementations reflects their having been done well to begin<br>> with. Unfortunately, I don't know how to sell that idea. A lot of<br>> people think like that division manager.<br><BR>I agree.<BR>But there is still work to do.<BR>Mainly increase portability and decrease platform-dependentness. <BR> backend: such as via the existing M3x86, or LLVM <BR> library: cooperative suspend <BR> And/or at least update to newer gcc. <BR> Improve debugging with stock gdb. <BR> <BR>A C-generating backend should ease installation and integration into distributions and such, since there could be a more "tradtional" Csource.tar.gz...<BR> <BR> - Jay <BR><div><div id="SkyDrivePlaceholder"></div>> Date: Mon, 13 Feb 2012 11:31:04 -0600<br>> From: rodney_bates@lcwb.coop<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] Think we need a new release.<br>> <br>> This discussion reminds me of my first full-time software job. The<br>> division manager had a graph on his wall of bugs fixed per month. He<br>> considered a high fix rate evidence of success. Some of us sat around<br>> laughing about the incentives that created.<br>> <br>> I also recall a wonderfully-written story about an aging programmer<br>> who protected his job against the youth-is-smartest culture by keeping<br>> carefully planned bugs in code that only he could fix.<br>> <br>> I really do think the low level of activity in both the language<br>> and its implementations reflects their having been done well to begin<br>> with. Unfortunately, I don't know how to sell that idea. A lot of<br>> people think like that division manager.<br>> <br>> On 02/13/2012 08:06 AM, vintagecoder@aol.com wrote:<br>> > Hello Daniel,<br>> ><br>> >> Agreed. I can think of two reasons: adding "must have" stuff to the<br>> >> standard library, and fixing bugs or improving library, compiler, or<br>> >> runtime. Note that "must have" should probably be evaluated in the<br>> >> context of systems programming, which is what Modula-3 is for.<br>> ><br>> > For myself I tend to be very careful when it comes to "must have" in<br>> > language design. If you feel the language spec is outdated or insufficient,<br>> > then I think it's a dangerous, slippery slope to start adding features to<br>> > the language even if they are a must have, without a standards committee.<br>> > If people are not careful, they can turn a language that was designed well<br>> > into a junk heap before they know it. The threat to the death of a language<br>> > through inappropriate changes is far greater than the threat of death by<br>> > lack of changes.<br>> ><br>> > If people agree the current spec is not sufficient, or wrong, it seems to<br>> > me the first step is to form a language specification committee where the<br>> > language can be carefully controlled- and this has to be from a purist<br>> > view of the language with no concern for implementation and no "baggage"<br>> > other than the existing language spec has to be respected- all the changes<br>> > have to be aligned and harmonious with the original purpose and intentions<br>> > and direction of Modula-3, otherwise what you said later about a new<br>> > language comes into play. Optional features have to be clearly optional-<br>> > extensions to the standard that don't make sense in the core have to be<br>> > clearly deliniated and the spec has to be amended cleanly to separate core<br>> > language, optional extensions, etc. The Ada specification is a good<br>> > document to look at for examples of how to do this.<br>> ><br>> >> Even adding new platforms should not require bumping the version number<br>> >> if it is the existing infrastructure that is being ported.<br>> ><br>> > Agreed.<br>> ><br>> >> There are loads of "greatest next thing" languages out there that you<br>> >> have to re-learn every few releases. Modula-3 is thankfully not one of<br>> >> them.<br>> ><br>> > Agreed!<br>> ><br>> >> Want new stuff in the language? Then you want Modula-3+ or Modula-4.<br>> ><br>> > Agreed again!<br>> ><br>> > People are so used to constant turmoil because of Linux. I come from a much<br>> > different background and I value stability and evolution, not revolution.<br>> > New is not necessarily good just like old is not necessarily bad. Good<br>> > things pass the test of time and don't need constant changes. If we are<br>> > talking about changing the underlying implementation without changing the<br>> > language then of course this is fine and should not be held back. My<br>> > concern is about letting the implementation drive the specification- I feel<br>> > that is wrong, dangerous, and should be resisted.<br>> ><br>> > Many languages today are out of control. To grow a language properly is an<br>> > extremely big challenge that has to be taken with a great deal of respect<br>> > and concern.<br>> ><br></div> </div></body>
</html>