[short_sells_poo]

When you are trying to solve a complex optimal payoff problem, you really don't want to get bogged down with lifetimes. That's a completely orthogonal concern to what you are trying to establish. You are not writing production code, you are doing research. It's the core reason why languages with easy REPL and immediate feedback (like matlab, R, python, julia, etc...) are used for research, because you get immediate and interactive feedback. The keyword is interactive.

Once you have to think of types and lifetimes, a lot of the productivity goes down the drain.

99% of the stuff you do in research ends up being consigned to the cutting floor because it doesn't work. The 1% that ends up being useful is the only part worth productionizing.

[hajile]

Most of my day-to-day coding is in Typescript and I often find myself wondering if more than a few jobs wouldn't be easier and faster with plain JS and no need to feed the type checker. Many of the same thoughts about you vs the language tracking things applies here too.

In my case, I'd say that yes, I have to track the types myself, but the tradeoff is at least sometimes worth the extra mental overhead in my opinion. I'd say that the same can be true for lifetimes as well.

In your case, you will definitely be tracking lifetimes on some level and to say otherwise is going to be false (even GC'd languages must track lifetimes to ensure garbage is eliminated). The question is about the mental tradeoff vs the time taken. I'd guess that you are correct in your assessment. My only real point is that there is a cost that should be considered.

[short_sells_poo]

You are correct, lifetimes are being tracked in some form at all times. So let me rephrase: lifetimes are irrelevant to the primary work of a quant during research. The objective is to establish whether an idea works. In 99% of the cases, it doesn't and the code and the project are a dead end. Under these circumstances you need to reduce the amount of cognitive overhead that goes into program structure to a minimum.

Research is fundamentally different from the usual programming exercise. Research is like prospecting. You want to try as many different locations as possible. You don't want to build nuclear shelter grade construction at every potential site because 99 out of a 100 is a dud. You'd never find anything.

You want a tool that allows you to get quick results to confirm if a site has potential and then you want to be able to scale your tools for proper mining.