Other mixed functional/imperative languages have noticed this utter waste of returning a result from a map or zip call when the intent is really for the side-effect rather than the value. This is why the List module in Objective Caml contains both map and zip (there named map2) as well as iter and iter2. Because there is no need to allocate space for the result, these calls are significantly faster and more efficient.

Other mixed functional/imperative languages have noticed this utter waste of returning a result from a map or zip call when the intent is really for the side-effect rather than the value. This is why the List module in Objective Caml contains both map and zip (there named map2) as well as iter and iter2. Because there is no need to allocate space for the result, these calls are significantly faster and more efficient.

It seems like 'locale' is somehow hard-wired into the plot drivers [but not in other parts of Maple]. That would be a bug.

You have exactly described the basic steps of the process done by MapleNet [a project I was involved in]. Parts of the problems with the <maple> tag is that the "pretty printer" for Maple to gif is different that the other pretty-printers, and thus it has its own separate set of bugs, weaknesses and quirks. It is however possible that the process has changed since I last saw the internals.

You have exactly described the basic steps of the process done by MapleNet [a project I was involved in]. Parts of the problems with the <maple> tag is that the "pretty printer" for Maple to gif is different that the other pretty-printers, and thus it has its own separate set of bugs, weaknesses and quirks. It is however possible that the process has changed since I last saw the internals.

This is useful in at least two ways: 1. for new users, so they can learn from other's common mistakes 2. for developers, so that they can fix the underlying issue or at least find ways to mitigate the problem. It would be a very serious usability improvement to Maple if every one of those issues had some 'mitigation strategy' implemented. I have some ideas of how I would deal with most of those issues myself, but perhaps the best thing to do is to not limit developers' imagination on possible improvements by prematurely making suggestions. But I seriously think that this could be a real feather in Maplesoft's cap as well as a great marketing opportunity, especially as most of the competitors have a reputation for being rather disdainful of their actual users, if these things were addressed.

This is a bug that should be filed as a 'regression bug', ie a feature that Classic could handle seamlessly that does not work in Standard. Standard should simply be fixed to make this work. It certainly is in Maplesoft's best interest to give the most active users in the Maple community as few tangible reasons as possible to prefer Classic!

This is a bug that should be filed as a 'regression bug', ie a feature that Classic could handle seamlessly that does not work in Standard. Standard should simply be fixed to make this work. It certainly is in Maplesoft's best interest to give the most active users in the Maple community as few tangible reasons as possible to prefer Classic!

That is exactly the issue - jakubi seems to be pasting in Maple input, Doug is pasting in output. The results are quite different indeed, and it is confusing to users that this is so.

That is exactly the issue - jakubi seems to be pasting in Maple input, Doug is pasting in output. The results are quite different indeed, and it is confusing to users that this is so.

Cut-and-paste should be a useful tool that allows you to get work done by seamlessly allowing you to move data between different contexts and applications. That it is so not seamless that it can be used as a debugging tools boggles the mind. I guess my problem is that I have seen what was possible in 2007 as far as friendly user-interfaces are concerned: the web browser on the iPhone comes to mind. And I have implemented my share of 'seamless' cut-and-paste (several times, in particular in '89 and in '92). It is indeed challenging, but it is by now a fairly well-understood problem; the people who understand it best are actually those from the database community, as they have had to worry about this issue the longest [they don't call it cut and paste, naturally, but the underlying problem that needs to be solved is isomorphic].

Cut-and-paste should be a useful tool that allows you to get work done by seamlessly allowing you to move data between different contexts and applications. That it is so not seamless that it can be used as a debugging tools boggles the mind. I guess my problem is that I have seen what was possible in 2007 as far as friendly user-interfaces are concerned: the web browser on the iPhone comes to mind. And I have implemented my share of 'seamless' cut-and-paste (several times, in particular in '89 and in '92). It is indeed challenging, but it is by now a fairly well-understood problem; the people who understand it best are actually those from the database community, as they have had to worry about this issue the longest [they don't call it cut and paste, naturally, but the underlying problem that needs to be solved is isomorphic].

If you, as an insider, already know that beginner users typically make this mistake, why haven't you made sure that this flaw gets fixed in the product? Secondly, since Maple "knows" that this is a problem (ie if you cut-and-paste, you get a meaningful error message), then why isn't that the error message you get the first time? That doesn't make any sense!

If you, as an insider, already know that beginner users typically make this mistake, why haven't you made sure that this flaw gets fixed in the product? Secondly, since Maple "knows" that this is a problem (ie if you cut-and-paste, you get a meaningful error message), then why isn't that the error message you get the first time? That doesn't make any sense!

In the TTY and Classic, having lone single and double quotes gives you quite clear error messages as to what's wrong. I would expect something similar for mis-using double-quotes in a 'differentiation' context in Standard too, not a really really weird message from deep inside dsolve! The error and its symptom are simply too far removed from each other, something which I personally consider to be VERY unfriendly (one of the many enemies of 'usability'). It is doubly ironic that it is a 'usability' feature which is at fault!