Hi John,

Thanks for joining the thread.

>You see - speed what not the issue with FOX.

Sure Fox speed was certainly great.

Back in the years, the Rushmore engine is more than ok and both the array and sql engine connectivity brough at lot. When it comes to a recent kind of data massaging I was currently trying to implement in fox, vfp is just not up to it. And an interpreter such as python allows you code "à la fox", except for the UI part of course:-(

>The big deal with FOX was the data aware controls.

Sure, I'll miss them every day, much in the way I miss my years as a foxbase coder during the mid-80s :-) I also regret I did not fully tried to use dabo back when it started.

What I am trying to convey is that, from a commonplace python prompt "à la fox", I could :
- sql massage millions lines datasets in a rushmore-like engine (python duckdb in-memory) the way I am running in vfp, just a sheer order of magnitude faster!
- running "low level optimized multicore code" sans C++, sans cuda or worse... sans fll-s!

Of course the cpu runs hot on all cylinders (not gpu yet). That never occurred with fox of course.

I understand my current use cases are pretty specific. Let us call them highly specialized "data scientist" stuff. But I thought that making sure people catch that current top code performance is now the realm of JIT-ed code and that means "interpreters". Not interpreters à la fox. But neither the kind of AOT that C, C++ and other legacy compiler architectures still convey.

Recently listening to Chris Lattner "former Google and Tesla employee and co-founder of LLVM, Clang compiler, MLIR compiler infrastructure and the Swift programming language" was eye-opening. Reading through lpython-lfortran and numba creators prose as well by the way:-)

The Times They Are A-Changin' said Bob.