Ob VB, performance wise, giving how 'fast' some C64 written in VB ran, I think it was on par of TCL/Tk, if not worse for some cases and better in a few obvious cases (Direct Draw/Direct X), but Unix people wrote the core in C and they put a Tk UI on top giving great speeds.<p>And, on people praising VBA integration under MS Office, that gave us security disasters with macros and millions of dollars lost because of Excel parsing genomics as dates.<p>It's better to decouple data and algorythms as <i>separate</i> files. Keep your raw data in a file, transform it and set the output in a separate process and file. You know, a proper pipeline. Something the Unix folks understood since the very beginning 50 years ago.<p>But "performance" fanboys don't care, until the shit hits the fan as it happened in Science with bioinformatics. Tons of studies, papers and research were just void because of shitty software.<p>Meanwhile, some Unix users with Slackware with discrete tools for every process (and not just a self-updating XLS file for everything) did it fine as they followed a basic reproducible chain.<p><a href="https://slackalaxy.com/2019/03/15/slackware-and-slackbuilds-org-cited-in-a-scientific-publication/" rel="nofollow">https://slackalaxy.com/2019/03/15/slackware-and-slackbuilds-...</a><p>Harder? Yes, OFC. But, can you bet that your initial data will be the same on <i>every</i> process? For sure.