Between the product and the prototype

So, it seems lead isn't a good material for wings
(Australian War Memorial collection, No restrictions, via Wikimedia Commons)

These days I had a conversation with my colleagues about Python. One of them supported strongly the argument that Python is a good language for prototyping, but not for a final product. As stylists prepare prototypes for their new dresses with cheap fabric and then made the final product with the costly silk they designed from the very beginning.
To better support the paragon, they asked me: would you make the software control of a robot in Javascript or PHP?
Strong opinion, indeed. My answer was "no, because they are languages with big ambiguities".
But Python?

What's a prototype? What's a product?

Jesse Shell in his masterpiece "The Art of Game Design" says that a prototype is a tool we make to answer a question. If we work on an autonomous rover, possible questions are:

1. are the states on the state machine enough for all the possible situations?
2. is OpenCV able to distinguish between a rock or a hole?
3. how we can integrate a depth sensor with the camera we said before?
4. how we synchronize the four engines to let the rover go straight?

All these questions can be aswered making a simple prototype and see if the results are in line with the requirements. If so, the prototype answered the question and can be thrown away.
Why throwing it away?
Because a prototype is just a tool to explore a question. Sure, you can copy-and-paste that part that initialize a device or the specific element responsible for image recognition. But a prototype is a tool limited in the space of the question it was designed to answer.
A product is something different: it's a set of modules that communicate to each other to satisfy the User Requirements. A product is engineered to forecast some possible changes in the future and has a development plan, milestones, documentation, deadlines and tests. Moreover, it has a delivery procedure, while a prototype is finished when the we have the answer we where looking for.

Is the language an indication of what are we developing?

That said, can we assume the language as an indication of what we are working on? Since this piece of software is in Python, is it just a prototype?
According to what I said before, no. If we planned to use Python for that specific module, because we know that there's no advantages on writing it in C++; if we have the tests for that module; if we have the delivery procedure and milestones; then we have a product.
Under this point of view, even my thoughts made on the beginning were wrong: if we have all these things, even Javascript or PHP are an option for a robot.

Prototype often

Prototypes are an incredible tool: we humans are still monkeys and monkeys love to use their hands and manipulate the environment. Having a prototype is a way to explore a concept and a problem. It's basically a toy. And even when we use pieces of paper with labels and we start to manipulate this "paper prototype", we can grasp easier the good and the bad things of a specific design.
Prototype often, enjoy doing it and don't feel guilty if in your user requirements there's no trace of the programming language: maybe it's really not a requirement.