Maybe you don't want to use the old repl, there there is something else going on there and you don't want to mess it up. Maybe I want to show someone an example, or try something out quickly.
I use and spawn ipython windows all the time. Sometimes I have 4 open at the same time.
> Aggressive JIT languages are historically slow at startup.
Explaining the reason for the slow start-up doesn't make the slow startups faster.
No, but insisting that you want startups faster, when you've been explained the technical reasons why they are slow, doesn't make them faster either. To me it sounds like:
"This ball shouldn't fall to earth".
"It fell because of gravity".
"Explaining the reason it fell, doesn't make it go upwards".
Oh please. "We've explained the technical reasons to you" excuse. As a customer the response to that is "ok, good luck with that, I am not using your product".
> "This ball shouldn't fall to earth" / "It fell because of gravity" / "Explaining the reason it fell, doesn't make it go upwards".
No the answer to that is, screw this planet, I'll go fly into space and find another planet. Which is the response people have with software they don't like.
It is more like:
"Oh your database is slow" and getting the response of "Well of course it is,the locks at level 3 in our API have not been optimized because John is on vacation still. Geez how dare you not accept that as a valid answer?"
See you've equated software features hard laws of physics. So escaping from it is "ridiculous".
To be more serious, having an interpreter JIT a module only if you use, on-demand, or save the trace of it, across execution maybe he hard but doesn't require changing the fine structure constant.
Alpha did something similar, and a number of feedback-directed/profile-based optimizing compilers will perform similar optimizations, but they are less flexible unless repeated cycles are performed in the deployed environment.