Why do calculator manufactures like to reinvent the wheel?

[Tim Wessman]

I believe I've already explained this before. I'll try to make an attempt at it again. [EDIT] Thanks for linking to that! That discussion was one of the posts I was thinking about here.

First issue is memory. Without having control over the memory you get into trouble very fast. Most common languages or run times don't take that into account...

Second, we didn't invent a programming language. We made a parser to evaluate math. There is no difference internally between what you are looking at as a "program" and what you get if you evaluate the same commands in a command line.

Third, the capabilities and differences do not map to other languages cleanly. While all will have a very similar set of basics, what is offered past that quickly devolves into completely different goals and intentions.

Let's take a look at python (which is a good one since that is the first most seem to come up with). Does it have standard interfaces to do things like get keyboard input, draw to the screen, support every type of math object we support, support mapping to applications vs a global space, etc? Which libraries are you supporting? Who wrote those? Do they map to what we are trying to accomplish? Do those libraries you are talking about all even have consistency between each other in terms of numerical ranges, calculation methods, syntax, object support, etc. What about touch screen handling?

Forth, ;-) in revisiting the "different devices are different" in the last point, since there are no standard UI things that map cleanly across all devices (windows 8 anyone?) you end up wanting different UI things on different devices. While there some similarities, what happens in practice is you end up needing to write your own UI extension code and commands to provide the underlying "python" to let it interact with the system. So you end up with non-standard "python" that doesn't run directly on any other system apart from basic calculation and subroutine things.

A great example is the "Lua" that you mentioned on the Nspire. If you actually look at it, they HAD to extend it so much to give any sort of integration with the system that what you have in reality is essentially a completely different language.

You mention learning curves, yet the language on Prime is about as simple as you get. You can do something productive with it pretty much immediately. Trying to do more advanced things gets more difficult, which I think is true in basically any environment - hence being advanced-, but where things falls down is that there is not completely unified handling across all parts of the system.... which is exactly what your idea or thought to plucking a specific "common" language actually entails. You would end up with trying to merge multiple disparate systems together, have them work seamlessly, and not have any cracks showing between them. I believe that is exactly your complaining with the system right now. :-)

I've yet to see any common language or runtime that would work equally as well for a new math student, all the way through for professional use. Anyone who says "just give python or mathematica to a new student" should NEVER be allowed in a classroom.

Fifth, size. While some might say size doesn't matter, in the calculator space it traditionally has. The binary on prime is about 13 mb or so. The font takes up about 5mb there, the help content takes another very large piece. When I've looked at other run times, the only one that seems to come in at all close to the size our math libraries/parser takes is something like Lua, but that is very limited and tiny feature wise. What is the total size of a full python interpreter including libraries that will get you all the capability that is in the calculator right now? I don't think that is an easy question to answer, but I'd sure like to know. I'd highly suspect it is much larger though...