@Carl Love Given the number of topics covered, it is not surprising that my view has been lost in the process.

1) First and foremost, I am a physicist with lots of CS exposure, not a CS researcher/educator. I use, and we teach, top down thinking in physics. (It is also how I approach all research questions.) All applications of physics must be based upon physical principles. Start with the principle and then add a level of details and keep adding details until you have reached the bottom.

2) And thus, I truly appreciate Maple’s ability to allow me to model through the top-down approach. It is my experience that once the undergraduates reach an understanding, and mode of thinking, using Maple's capabilities, they learn physics more quickly and have a richer understanding of the principles. As a consequence, when we must move to Python and/or MATLAB, the undergraduates often become frustrated with Python's and MATLAB's bottom-up approach and the one-level evaluation limitations. Yes, it is true they could load some symbolic libraries, but, compared to working with Maple, the usage process ain't pretty. Many undergraduates return from REUs (research-experience-for-undergraduate programs) telling me how they don't understand why their research group battles with MATLAB when the problem is more easily solved in Maple.

3) However, since this full level evaluation does not occur in procedure, the pedagogical advantage of Maple is lost when problem solving within procedures. I understand why this is the policy – improved efficiency. And fortunately, now that I know this property of the Maple system, before I return any of my work using a top-down approach, which is yes, less efficient, I need fully evaluate. It is not a hardship, but I wish I had been aware of this difference years ago because in the vast majority of my work with Maple, I’m expecting, and usually receiving, full evaluation with every statement. Knowing the one-level evaluation would have saved many moments of misunderstanding the reason for the outcome of my procedures. That is on me. And now I know.

4) You wrote, "I think that you've misconstrued the comment about other programming languages. In a language without symbolic variables, it's impossible for there to be any distinction between full and one-level evaluation." What I meant was, my complaint about the lack of full evaluation capabilities in procedures is unwarranted given that virtually every other language I have used, assembly, FORTRAN (66, 77, 90), Pascal, BASIC, C, C++, Python, MATLAB (I'm sure I'm missing some), possesses only one-level evaluation. However, it is possible to use a one-level evaluation programming language to construct a full level evaluation language which only produces numerical outcomes.

I hope this lengthy reply provides you with some contextual understanding about a person whose experiences and approaches mimic a larger percentage of North America’s physical scientists and educators. I certainly would not have made the effort if I didn’t value your knowledge, experience and efforts to help others here on MaplePrimes