MEP 00 - The Zen of Mathcad
The Bad Idea Fairy was drunkenly wandering through my brain, stomping down the grass with his size 13 boots, singing off-key, scaring the squirrels, and littering the place with ... well, bad ideas.
However, whilst I was pretending to tidy up, I looked at one of those ideas and thought, "Hmm. Maybe he'd stolen that one from his twin brother, the Good Idea Fairy (you can't tell them apart, sometimes)?".
The idea? "Now that Mathcad 11 has introduced Python Scripting, maybe it's time to introduce a Mathcad equivalent of PEP 20?".
Instead of proposing a "Feature Request" or reporting a suspected bug, perhaps we could introduce an MEP (Mathcad Enhancement Proposal)?
Starting with:
MEP 00 – The Zen of Mathcad 
1. >>> Range Variables Are Not Vectors <<<.
2. Think in two dimensions for layout and data.
3. Be like Zathras-- cover all possibilities. Zathras does not want other people being confoosed.
4. Yesterday's friendly hard limits are today's enemies.
5. Beautiful is better than ugly.
6. Explicit is better than implicit.
7. Unless implicit is better.
8. Simple is better than complex.
9. Complex is better than complicated.
10. Flat is better than nested.
11. Except where it isn't.
12. Sparse would be nice.
13. Readability counts.
14. Now is better than never.
15. Although never is often better than *right* now.
16. Functions should work over any data type.
17. Except where there is no meaning.
18. Special cases aren't special enough to break the rules.
19. Although practicality beats purity.
20. Errors should never pass silently.
21. Unless explicitly silenced.
22. But Exceptions should be Exceptional.
23. In the face of ambiguity, refuse the temptation to guess.
24. But see Zen 14.
25. There should be one-- and preferably only one --obvious way to do it.
26. But don't let that stop you doing it another way.
27. You'll probably need to-- this is Mathcad.
28. If the implementation is hard to explain, it's a bad idea.
29. If the implementation is easy to explain, it may be a good idea.
30. Yes, vec helps, but >>> Range Variables Are Still Not Vectors <<<.
Zen 4 -- Yes, I'm looking at you, recursion depth limit. 
Zen 2 & Zen 16 -- round, floor, ceil? What were you thinking? Those poor matrices are sobbing in the corner, feeling all neglected. Shame on you.
(What do you mean, you don't know who Zathras is??? 😲
https://youtu.be/1j-76eLz1hc?t=54)
MEP nn – Suggestions
1. The Empty Array is one honking great idea -- let's implement it! If an empty value is good enough for the string, the array is more than good enough for it.
2. Surrogate Pair characters are one honking great idea -- let's implement them! If surrogate pair characters are good enough for JavaScript, Mathcad is more than good enough for them.
3. Formatted strings are one honking great idea -- let's implement them! If formatted strings are good enough for TeΧ Sensei Donald Knuth, they're good enough for Mathcad.
4. Multidimensional Arrays (MDAs) are one exceptionally honking great idea -- let's implement them! If MDAs are good enough for every other programming language, Mathcad is more than good enough for them.
5. str2sym is one honking great idea -- let's implement it! If str2sym is good enough for Matlab, Mathcad is more than good enough for it. And let's have sym2str while we're at it!
Here, for example, is Zen 2 influencing MEP 3 and MEP 5:

I don't see why strings shouldn't be 2-dimensional. If multiple lines are good enough for compressed wood pulp, or even HTML, then surely Mathcad is more than good enough for them?
Thoughts?
Stuart
Shamelessly stolen from:
The Zen of Python (aka The Pythonic Way)
PEP 20 – The Zen of Python
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

