Maple has many uses, from glorified calculator on up.  The high-end, where I think that Maple can be part of a paradigm shift [and there is already evidence that it is -- see the interview with Gaston Gonnet, which we have talked about before] is to use Maple as a prototyping platform for solutions which would (eventually) be deployed to non-Maple users.

I was very hopeful some releases ago, when I saw all sorts of work on CodeGeneration, that this was where things were headed.  But somehow that seems to have been put onto the backburner for now. 

Yes, we do seem to have miscommunicated.  The engineers that I have in mind, and I believe Maplesoft is trying to capture, are the "creative engineers", those who have to find solutions to 'new' problems where old solutions do not readily apply, or have to optimize old solutions in directions where, again, old solutions do not readily apply.  Sure they likely are in the minority, but still a non-trivial market.  These people can use Maple as part of their work.

There seems to be a $80 million market for Matlab out there.  That is rather sizeable!  For a number of uses of Matlab, Maple would be even better.  Of course, The MathWorks also has a bunch of toolboxes that Maplesoft does not, in areas where Maple is not so strong.  But still, there definitely has to be something there!

[For some reason, right now my Maple 9 does not start, and I don't have Maple 9.5 on this machine]

Compare the context menu obtained from the (output of) <<1,2>|<3,4>> in Maple 8 and Maple 10-11-12.  Very different.  Also note how much faster the Maple 8 version of the menu comes up compared to 10-11-12.  The original design of the context menus [I know, I did it] prized two things: 1) speed, 2) usefulness. 

But pretty much every single context menu (on integers, polynomials, etc) have changed between 8 and now.  Sometimes they are better now, sometimes they are much worse.  Pretty much always they are much slower to come up.

I agree that 'fragile code' and 'fragile tests', ie code/tests that depends on the syntactic shape of the result of another, usually top-level, command, to work properly, is a real problem.  It can definitely slow down development a lot.  But it also goes against years of development practice!  In the past, to be considered a true Maple Master, you had to be a wizard with 'op'.  Slowly, as the years went on and maintenance grew harder and harder, it dawned on people how fragile op-oriented code was.  And slowly, new code is less representation sensitive.  But old code and old tests persist, and they do create a fair bit of inertia that prevents progress.

Those cases where the problems themselves are not well-defined are one of the aspects of the research work in this domain that I have worked on myself.  I have notes for clarifying a whole bunch of further issues [they have been about 8 years in the making, the issues are really complex] which I hope to piece together into something I can show others in the fall.

On performance, I am torn.  Certainly anywhere Maple is 100 times slower (or worse) than the state-of-the-practice, that is a serious problem that should be fixed, because that can indeed prevent forward progress.  But 2-5 times slower is rarely something to worry about soon.  The hard call is when Maple is 10-20 times slower than state-of-the-practice.  To me, resolving that requires hard data, viz a lot of measurements.

Maybe I should renew my offer to Maplesoft the help of one of my grad students [now via a MITACS internship] to collect such measurements. 

I find wikia pages to be really cluttered with useless stuff.  It might still be the best choice for the community to build a Wiki.  I'll just wince everytime I look at the pages!

I don't remember.  Too bad the wayback machine isn't searchable!

I don't remember.  Too bad the wayback machine isn't searchable!

That is one of those questions where I know the answer but it would be inappropriate for me to reveal it.  There are a few clues on the web, but not enough.

I cannot offer you proof [that would violate my NDA, and would also stop most of my information flow].  In fact, I do not divulge any information that (in my opinion) is not already externally observable in some way.  Most people would not take the time to collect such information, sure, but it is available.  For example, one can tell a lot about where a company is going by looking every ~3 months at its job postings [I correctly guessed a number of things going on at Wolfram Research that way].

I live in Waterloo.  I still get to go to some Maplesoft functions. I know many of the developers in R&D and I talk with them not infrequently.  I also know several people in Marketing, even in Sales.  By talking with various Maplesoft employees, I know what most of them do.  I have known the people at all the Maplesoft-sponsored labs for over 15 years, and I work with them still [papers in common, go to the same conferences, etc].  At these conferences, I keep up with all these people, so I know what they work on.  I do this because I need to, to do my own research.

The company does development, not research.  These are different things.  The company does do some maintenance on int, series, limit, etc.  But if they did a whole lot of improvements, don't you think that that would appear highlighted in the What's New?  You always see new things in the areas of DEs for each release, and that is because there is a dedicated person on that topic [again, this information is available on the web already].

Lastly, most of my posts contain opinion mixed in with facts.  I rather like it that way.

Clearly executives (like Tom 4) stopped reading this forum a very long time ago, even though they promised all sorts of great things, only some of which happened.  But I know that many developers still read it quite frequently.  So it is not a total waste, because individual developers can still make a difference, at least at the level of local tactics, if not at the strategic level.

The problem is not that Maplesoft doesn't present material for its more technical users - it does, but only in certain forums.  mapleprimes was a site driven by Marketing, while the technical information goes out through R&D, and thus through the channels that it controls [namely beta.maplesoft.com]. 

I do not think that Maplesoft has yet learned that "nothing is more expensive than to substitute existing customers".

It is my understanding that, as far site licenses for large universities are concerned, the market is fairly well saturated: those institutions either have Maple or Mathematica (or both) already.  Whether these universities actually use the software much used to be an open question.  This is because the people who control the budget for large purchases and the actual users are quite disconnected from one another.  So Maplesoft has contacts for the purchasers but not the end users, which prevents actual usage data from being collected.  The real danger is that these universities might decide that automatically purchasing upgrades is not such a good idea anymore and skip a few releases.

As far as engineering goes, it should be the case that Maple can handle medium-sized models, not just the toy ones from university.  Furthermore, it should be possible to manipulate those models symbolically to derive valuable properties of those models, without having to solve them (symbolically or numerically).  Model manipulation also allows many optimizations that purely numerical methods cannot -- this is something I have written a few papers about.  The gains can be from good (5x speedup) to fantastic (500x).  However, I have my doubts about the "approved by various classification and codification authorities": Matlab is used at a lot of engineering firm, and no competent authority would ever certify Matlab as "fit for purpose" [it's not the software, it is the methodology which is flawed].

What, you don't think that any of the research is good?  Or agree that all of it is not core? ;-)

Note that I did say 'most', not 'all'.  Your work on polynomial representations (and similar stuff) is core, as it underlies a lot of the core stuff.

But who works on int, simplify, series, limit, rsolve or assume?  No one at the labs currently sponsored by Maplesoft AFAIK.   "Computer Algebra" makes for good research, but to me 'core Maple' is much more about "Symbolic Computation".  And that is where less and less work is being done.

We know that the cost eventually gets too high: even Microsoft broke compatibility, first with XP SP 2, and then again with Vista.  Apple's OS X does it all the time, and to a certain extent, so does Linux.

For example, Java tends to be backwards compatible, but at a huge cost.  And they, like Maplesoft, have had to admit that some past designs were bad [Java: AWT; Maplesoft:linalg].  Actually, the Eclipse Foundation thought Swing was awful too, so they created own widget set!

The question about 'how far' is actually pretty easy to answer: until there is a viable competitor that does it better.  When will that be, now that is a rather difficult question!

That is what a company that thought of itself as having a mature product would do, yes.  But since companies with mature products rarely experience rapid growth [which the executives at Maplesoft have been trying hard to do], that is not the conventional wisdom.  So you get a 20 year old software company (ancient by almost all measures in the industry) with a 28 year old product (dinosaur!) strategically thinking in terms of a start-up, because that is the effective market-share they have in the area they are aiming for.

With the end result being that the amount of resources put towards keeping current users (you know, the ones who upgrade year after year, and who make up for the majority of Maplesoft's revenue) is rather small [if it was not the case, then the complaints above would not exist]. In a way, it seems that "What is Maple for?" has at least one answer: not really for its current users.

It exists, but it is full Maple.  There were old student versions which were 'crippled', but that was unsustainable [it was difficult to maintain, and the end results were not satisfying].