Whatever happened to Maplesoft's strong support for MathML?  [Check out Maplesoft's press releases for Maple 7, MathML was all the rage then]. Clearly the support has waned, as evidenced by the fact that the official MathML pages on Maplesoft's site (here and here) are for Maple 9.5 and Maple 10 respectively.

That Maplesoft itself cannot use MathML on its own community web site (Will's reasons are sound) speaks volumes about the success of MathML.

The 'indent' button does not seem to do anything useful - at least not under preview.  It seems that somehow the site swallows style attributes (which is what the button does).  I had to go in a previous post and put in explicit <blockquote> around 2 paragraphs where before I had used the editor to 'indent' them, to no avail.  That is really rather misleading to have a no-op button on the editor!

You are quite right that the term 'elementary' is used a lot in mathematics, and that my use is perhaps not the most common.

I should have been more precise and described it more at a meta-mathematical statement.  In other words, it is really about proofs/arguments rather than about a specific piece of mathematics.  This is indeed closest in spirit to the use from number theory.

You don't have auto-completion (which is indeed handy), but you do have completion.  When typing a command, hit ctrl-space, and it will complete as much of that command as it can.

You don't have auto-completion (which is indeed handy), but you do have completion.  When typing a command, hit ctrl-space, and it will complete as much of that command as it can.

One reason might be that, as of yet, there is no serious alternative.  Mathematica is just as problematic as Maple, but with the problems in entirely different places -- not really an improvement.  And none of the current open source alternatives have nearly the computing power of Maple.

If you are on Windows or Linux, Classic is a decent alternative.  If not, then a lot of people use the TTY version from within an emacs shell and are quite happy with that.

One reason might be that, as of yet, there is no serious alternative.  Mathematica is just as problematic as Maple, but with the problems in entirely different places -- not really an improvement.  And none of the current open source alternatives have nearly the computing power of Maple.

If you are on Windows or Linux, Classic is a decent alternative.  If not, then a lot of people use the TTY version from within an emacs shell and are quite happy with that.

I really am missing those notifications, they were really useful.

There were open issues that need to be "kept open" by making sure they stay fresh and visible.

Isn't it interesting how often we have encountered the issue that creeping featuritis seems to cause a product (be it Maple of MaplePrimes) to regress in usability?  WYSIWYG, if it is not absolutely perfect (and even then) sure seems to hinder rather than help. 

Will, trying to help us, has actually caused many people hardship.  And since the strength of MaplePrimes is that its frequent posters hang around to answer questions, causing them pain is, er, counter-productive, shall we say?  If us red-leaf holders [welcome John!] leave, this site will wither away.

Generalizing this: whenever the kernel sends an object (to be printed) to the GUI, it should send a pair PRINT(DAG, print_form) where DAG is a handle to the kernel object, and print_form is something worthy of printing.  In fact, a good print_form would be made up of similar pairs!  [Note how this is exactly one of the methods for content/presentation MathML pairing].  One could also send 2 directed acyclic graphs with cross-pointers (another possibility in MathML), but I somehow don't like that as much -- I could be convinced otherwise though.

This could allow more 'structured' editing, where an edit of the presentation would not have to "guess" what a lot of the presentation means, because it would most likely not have been edited, and so the link back to the content part could be re-used.  This would also give context for those parts where the edited bits come from, thus increasing precision (and speed).  It would fix a lot of bugs in the current context menus.  It would allow other features (like drag-and-drop) to work better too. 

And guess what?  That would be equivalent to an implementation of model-view-controller where the GUI implements the interface to the controller and the view, the kernel controls the model 100%, but the view is fully programmable because it could be generated by the kernel, as well as being possible to manipulate it in the GUI.  The additional nicety would be that the GUI would only really need to know about the 'display' language, and could be made independent of the actual DAG representation, which is a clear win regarding proper modularization.  If you look carefully enough at a number of Mathematica 6 demos, you'll see that it looks like that is exactly what they have done.

[I have some comments to make about what acer said too, but I don't have the time right now, I will come back to that later.]

acer already mentionned that these extension facilities are spottilly documented, and some extensions appear to be completely undocumented [quite possibly on purpose!].

However, the main example is the most dangerous one: the print/ mechanism was never really thought through, it was just implemented because it was easy to do so.  In fact, this mechanism goes back to 3 or 4 versions ago of the pretty-printer (in other words, it dates from around Maple 4.2, roughly 1987).  In other words, it was not designed with a GUI in mind, and certainly not with interactivity in mind.  So while this extension mechanism works quite well when you are using the TTY version, or whenever you are using Maple in a TTY-like manner in Classic, the paradigm breaks down spectacularly as soon as you try to use any of the ``newer'' features (like Context Menus, which are over 10 years old now...).

Basically this is due to the following: the current interface paradigm pretty much expects the kernel to hand over a representation of an object which corresponds to the kernek's semantic view of that object.  The GUI (sometimes by asking the kernel/library) then works rather hard to translate that to a nice display.  This means that when one asks for an operation on that object (via the GUI), a handle to the model is available, and passed back to the kernel.  But what happens when you use `print/`?  Well, what the GUI now gets is no longer semantic, but a piece of hacked-up Maple commands which happen to display nicely (ie what is known as a view in the classical MVC model).  That really breaks the whole paradigm, since the GUI really expects to be handed a model from which it generates a view; but when it is handed a view, it generates its own view of that.  Now any kind of round-trip back to the kernel is pretty much impossible.

As far as I know, there is still no replacement available for this print/ mechanism.  In other words, again AFAIK, the GUI's view-generation algorithm is not extensible (well, it probably is, in Java, if you knew all the dark secrets, but we don't, plus Java, yech!).

So there you have it, the worst of all worlds: because of backwards compatibility, print/ still works, but because its design is incompatible with modern GUI-based interaction, using it is extremely dangerous; and there is no replacement mechanism that nicely works with the modern design.  Nice, eh?

If you are still reading this, then take a look at Symbolic Interface Construction, and Dynamic Interactivity, new stuff in Mathematica 6.  That shows some pretty amazing stuff you can do when you get your MVC model right, and allow full programmability.

Perhaps what was sought after are values of k and j where the ODE given indeed has solutions?  Using

 DEtools[formal_sol](de,y(x),x=1, 'order'=2);

                /
          (k/2) |
  [(x - 1)      |1 +
                \

        /                  2           2                \
        |      k          j           k            j    |
        |- --------- + --------- - --------- + ---------| (x - 1) +
        \  4 (k + 1)   2 (k + 1)   4 (k + 1)   2 (k + 1)/

                   \                 /
                 2 |         (- k/2) |
        O((x - 1) )|, (x - 1)        |1 +
                   /                 \

        /      2                       2                \
        |     j            j          k            k    |
        |- --------- - --------- + --------- - ---------| (x - 1) +
        \  2 (k - 1)   2 (k - 1)   4 (k - 1)   4 (k - 1)/

                   \
                 2 |
        O((x - 1) )|]
                   /

one can see that k=0 is necessary. Doing this again on eval(de,k=0) at order=3, one then sees that j=-1 and j=2 are two possibilities. In fact, both work and give solutions that satisfy this requirement. Of course, both solutions are just y(x)=x ! Otherwise, as Robert stated, none of the solutions satisfy these requirements.

Perhaps what was sought after are values of k and j where the ODE given indeed has solutions?  Using

 DEtools[formal_sol](de,y(x),x=1, 'order'=2);

                /
          (k/2) |
  [(x - 1)      |1 +
                \

        /                  2           2                \
        |      k          j           k            j    |
        |- --------- + --------- - --------- + ---------| (x - 1) +
        \  4 (k + 1)   2 (k + 1)   4 (k + 1)   2 (k + 1)/

                   \                 /
                 2 |         (- k/2) |
        O((x - 1) )|, (x - 1)        |1 +
                   /                 \

        /      2                       2                \
        |     j            j          k            k    |
        |- --------- - --------- + --------- - ---------| (x - 1) +
        \  2 (k - 1)   2 (k - 1)   4 (k - 1)   4 (k - 1)/

                   \
                 2 |
        O((x - 1) )|]
                   /

one can see that k=0 is necessary. Doing this again on eval(de,k=0) at order=3, one then sees that j=-1 and j=2 are two possibilities. In fact, both work and give solutions that satisfy this requirement. Of course, both solutions are just y(x)=x ! Otherwise, as Robert stated, none of the solutions satisfy these requirements.

is is powerful, not fast. It does have some code to try to resolve the really simple cases quickly, but this has limits. So if efficiency is something you care about, then it is worthwhile to do this.

That said, I tend to want my inner loops to be as fast as possible, while I like my interface code to be as smart as possible.  By interface code, I mean the entry points to big routines like solve, dsolve and so on.