What is a good metric for guiding a switch from a prototyping language to a production language? [duplicate]

Question

This question already has answers here:

Why do dynamic languages make it more difficult to maintain large codebases? [duplicate] (6 answers)

Closed 5 years ago.

By "prototyping language", I mean one which was chosen by virtue of it's relative ease of quickly accomplishing the sort of design changes common to prototyping in a particular context. (such as data visualisation, for example)

By "production language", I mean one which, with a more solidified design, is likely to produce a more satisfactory, optimised, maintainable product. One might, for example, prototype a data visualisation in MatLAB or IDL, but switch to C++.

A really simplistic decider might be the subjective judgement that "I'm done prototyping now", but prototyping often "tapers off" rather than ending abruptly, and there is often a realisation that one should probably have swapped to the production language of choice at some point in the past. Maybe a good metric involves capturing some "velocity" information (agile-style) and watching for an inflection point as the velocity changes?

FYI, "Why do dynamic..." and "...scale of the project and the strictness...", while related, are not duplicated by the current question.

Answer 1

Since you mentioned Matlab (and IDL) vs C++ I'll address my answer to that scenario.

Short summary of indicators when switching from a prototyping to production language is necessary:

• When programming data structures , algorithms, or distributed processing architectures not well supported by the prototyping language, or better supported by the production language, become needed.

• When performance of the programming language becomes inferior to that of the production language due to data or algorithmic considerations.

• When the prototyping language's support for code reuse,
  modularization, and creation of libraries is inferior to the
  production language and this causes development velocity and team collaboration to suffer.

I'll talk a bit more about some of these aspects.

One clear indicator that it is time to migrate is often scale. By this, when the problem's complexity, or the complexity of the software development process, becomes large enough in scale that something like Matlab cannot handle it well, it becomes time for a switch to a more production-oriented language.

Problem complexity scale can include when the amount of data to be processed gets to the point where computing with an interpreted language is not sufficient for adequate throughput.

The choice between Matlab and a production language has become less clear cut with recent releases of Matlab. Matlab does now offer some support for multicore, GPU, and distributed computing. It's debatable how adequate that support is, both in development expressiveness and in performance, compared to native implementations. But it does make the inflection point less clear cut than it was when this support wasn't available.

So a careful evaluation needs to be done of whether the development of code in a production language offers clear cut advantages in performance , or suitability to a parallel or distributed computing architecture, over the prototyping language. A production language, especially one that can be natively compiled, inarguably can take greater advantage of compiler and processor specific optimizations than even a JIT-compiled interpreted language.

Another aspect of scale you alluded to in your question is in software development process. A production language offers significant advantages over Matlab in the ability to develop large scale software. Matlab's support of objected oriented programming, string processing, data structures other than matrices, is generally considered weaker than found in production languages, or even Python.

But it is in the ability to partition and reuse code by developing libraries and modules where a prototyping language like Matlab really falls short of production languages. It becomes time to switch when the code base becomes large enough that these deficiencies cause development times and team collaboration to suffer.