This may seem like weird advice since I have a previous article extolling the wonders of using the correct tool for the correct job. As my may have guessed this post is about when the correct tool for the immediate task is different than the tool for the finished product.
Shortly after starting college the advice for programmers was RAD, or Rapid Application Development, was the way to ensure that you really understood your requirements and could make a reasonable guess as to how long it would take to do a project. This was before the Agile development style had become well known, probably before it had been named, but RAD proposed as part of the requirements gathering step in what is now called the "waterfall" development methodology. I know a lot of people would like to stop reading at this point, but I still use the waterfall development methodology and I think you might also if you read this excellent article.
When you are given a task without fully formed requirements, all of the projects I have ever encountered in my career, it is essential to communicate with the stake holder, ie your boss, if what is being asked of you is reasonable or not. It is not possible to determine that before you understand what you will be doing, and I don't know how to do that without a little prototyping. Prototyping forces me to understand the goal well enough to create something similar to the goal. If I can't figure out how to prototype I need more information added to the requirements. It also gives me something to show the stake holders to ensure that what I am building is what they envisioned when the came up with the project. This has saved projects I have worked on from failure due to me building the thing I read instead of the one that was desired.
I write prototypes in a language that has 3 properties. First, it is extremely fast to develop in. I don't want formality to get in the way of expressing my ideas. Types are great for ensuring that my intent is followed in the final product, but in the prototyping phase they make me make decisions too early in the process. The prototype is to ensure I understand the problem, not to ensure that a specific language has the required infrastructure to address the problem.
Second, the prototyping language needs a large set of libraries to supply features that may come up. I don't want to be writing a network library to complete my prototype, it is there to ensure I understand the problem, not that I am capable of having the optimum solution to the problem in the language I am using. If the tool you are using has a wide array of features to help you get close enough to the problem domain then you can find the optimal solution for the project in the environment you select to solve the projects requirements.
Third, it needs to be easy to modify. I am looking for a language that I can modify while it is running and it is capable of still executing. It may seem like any interpreted language can do that, but languages like python have a compilation step, usually a JIT (Just In Time) compiler that does the work behind the scenes. If you modify the file while it is running it need to be recompiled and the previous execution killed to move to the new version. Having this functionality means that while someone is donating their time to comment on my understanding of the requirements, we can work in real time to modify what that understand without having to worry about intermediate steps which frequently get missed when working under the pressure of someone else time, and under their watchful eye.
My personal prototyping language is Tcl/TK. Tcl (pronounced /ˈtik(ə)l/) is a dynamic language that was released in 1988. It fits all the requirements I have for a prototyping language, and others agree according to their website.
My original premise is that the correct tool for prototyping is not the correct tool for production code. When was really new to my profession I would write my prototypes in the language I planned to use for the final project. The conclusion to this paragraph is blatantly obvious, I no longer do this. I originally thought writing the prototype in the chosen language of the project would allow me to reuse my code, thus saving me money. I was correct about half of this thought, I did reuse my code, the code that was generated when I did not have a full understanding of what the requirements were, the code that had been revised multiple times without much thought about what the consequences would be, the code that limited or no testing associated with it, the code that had documentation in the revisions of the requirements, but no internal documentation, the code that I had generated so fast I don't remember which generation I settled on. In other words I reused the worst code I could possibly generate and tried to turn it into something I, or even worse someone else would have to support for decades into the future. The prototype has immense value, but that value ends when its purpose ends. By trying to give the code additional value I cost myself and my project far more than restarting with a fully fledged plan and creating the project with the best code possible from the beginning.
Every project I have worked on has asked me how long it would take to get my prototype ready to deliver. By using a targeted tool that is not viable for the production system I have saved the project and myself from stumbling into this quagmire and ensured that I am able to be confident in the deliverables I supply, so give it a try and see if you discover like I did that the wrong tool is sometimes the right tool.