As I do have thoughts on this topic, I wrote them up in a blog post.

This is done in other software fairly routinely (like TP software).  And it is how mathematicians actually work.

Such contexts were proposed for Maple at least 12 years ago.  But it seemed to require retooling too much of the library for it to be really useful, so it never got put onto the schedule.

There is certainly one from IEEE, and perhaps IEC as well, not sure about ISO.  But unless you are a military contractor or you have legal liabilities to worry about (engineering, health, etc) because you are writing software covered by strict laws, no software shop follows those standard processes (they are too expensive).

Such processes do help.  But so does having really good requirements (including use cases).  But as long as customers keep buying, why worry about such things?

I agree with jakubi -- the TTY version of Maple in particular works fine even in 8 Megs of memory (for simple tasks).  But Standard will be rather painful, as Java will likely eat most of your memory, and the OS the rest.  It should actually 'work' though. 

The code base for Maple V R5 interface is largely the same as 'Classic' !  I guess some ``bug fixes'' in Maple 6 through 8 might have made things worse.

In any case, that won't work either, as there will be new DAGs in more recent Maple kernels which will likely crash the old GUI if it ever receives that.

Maybe they will have some time to turn their thoughts to things other than shipping product and perhaps think of some long term marketing initiatives (like a Wiki) instead.

I would find that useful too.

[Sorry for the late reply, I was away for a while]

I completely agree with your post.  If I were to rephrase the important points, I would say that it is the context (ie the underlying theory) in which you interpret an expression that gives it meaning.  And in the case of algebra and analysis [for example], the very same syntactic expression can have different (denotational) semantics.

This is a real problem from a computer science point-of-view (or at least from a programming language semantics point-of-view) as semantics is not normally context-dependent in this particular way.  Sure, we have polymorphism (whether parametric or ad hoc) which allows overloading, but that is somehow different.

At Maple, the department that does testing is 'Quality Assurance', not 'Quality Control'.  In effect, the difference is huge: QA people usually just measure the product for defects and report the results to others.  QC people make sure that quality is (measurably) at a high enough level.

But in this case, QA is a department within the R&D organization, so they do not have the power to overrule the developers and say 'no, this is not good enough'.  This is rather common in a lot of software development companies, where developers get all the prestige (and egos to go along), and QA/QC gets very little respect (and pay and ...). 

If by "Maple Express" you mean a reduced capability Maple, yes, it is technically very difficult to do that, with any release.  Building cross-release is just as hard, as every release has a library that definitely depends on kernel features of the same era.  It was tried a few times, and each time the effort was abandoned because the results were not satisfactory.

Actually, we have:

Maple 1.0 (January 1982)
Maple 2.0 (May 1982)
Maple 2.1 (June 1982)
Maple 2.15 (August 1982)
Maple 2.2 (December 1982)
Maple 3.0 (May 1983)
Maple 3.1 (October 1983)
Maple 3.2 (April 1984)
Maple 3.3 (March 1985)
Maple 4.0 (April 1986)
Maple 4.1 (May 1987)
Maple 4.2 (December 1987)
Maple 4.3 (March 1989)
Maple V (August 1990)
Maple V Release 2 (November 1992)
Maple V Release 3 (March 1994)
Maple V Release 4 (January 1996)
Maple V Release 5 (January 1998)
Maple V Release 5.1 (March 1999)
Maple 6 (February 2000)
Maple 7 (June 2001)
Maple 8 (May 2002)
Maple 9 (June 2003)
Maple 9.5 (April 2004)
Maple 10 (May 2005)
Maple 11 (March 2007)
Maple 12 (May 2008)
[I may have some months off a little, but most of these are well documented -- these are the versions of Maple that were 'publicly released' in one way or another].

So if Maple used a full linear scheme, next year's would not be 13 but rather 27.

Once a bug is 'closed', for whatever reason, most searches in the database will not find that ``bug'' anymore.  That is because most searches are coded to look only at bugs with a non-closed status!  It is possible to look at closed bugs, but it is harder.

Bugs closed as "works as designed" are very insidious.  A lot of things get swept under the rug this way.  The old square-root bug was once thought as "works as designed" for over 10 years.  Newer designs are the current orthodoxy, and thus it will take a lot of time and effort to convince those who created those designs of the error of their ways.

I have found that frontal assault (ie reporting that a flawed design is a bug) does not work.  However, indirect reports do work rather well.  By this I mean to make multiple reports which seem rather different from each other, but ultimately all are remote symptoms of the same underlying flawed design.  As long as the multiple reports really seem like genuine bugs, then that usually sows the seeds of doubt.  A few years later, that "works as designed" is changed [but usually not retroactively in the bug database] to "design bug" in the minds of developers.

Of course, that does not necessarily mean much - in this day where backwards compatibility trumps pretty much everything else (in the math, not the GUI), I don't know what actually happens to "design bugs" anymore.

Such a program is clearly a very powerful marketing tool, as Microsoft's experience already shows.  But it can be made even stronger: instead of trying to release a crippled Maple [which is technically very very hard to do], why not simply release a full version of an old Maple?  That would send a clear message: Maplesoft thinks that newer versions offer so much added value over older versions that we're willing to give you old versions for free.

I would suggest to release the oldest usable version, Maple 6, free.  Then next year when Maple 13 comes out, make Maple 7 free, and so on.  Making a version of the software that is 7 years old available free should not cut into current sales.  Anyone who argues that it would is also saying that their R&D efforts for the last 7 years have been totally worthless!

I am surprised that Will did not reply to this post.  Maybe he will now.