Hi Daniel,

guess I am a bit late to the thread - took a month of detox (internet usage...).
As your post is long, inline & part snipped

>The last time I worked python - moving a vfp Web app "à la foxapi", the python interpreter and python (2 and 3.0) were equivalent speed-wise. Of course python was already an impressive eco-system by the late 90s and fox had already a dwindling support despite its wonderful community support. Overall the two things were still roughly on par.

That feels a bit off, unless CPython got a heavy speed up.
When I tested, Python was always slowest,
vfp more than 2-3 times faster even on non table code,
early JITted Javascript often faster than vfp,
sometimes not much, sometimes an order of magnitude.

Using Cython I found I could speed up Python with more ease than dropping to C in vfp,
giving Python a good chance to eliminate glaring slow spots faster than in vfp.
Cython declaring variables in memory and function signature gives a heavy boost
AND stays closer to previous sources, so maintainance is not tasked.
(Uncertain on how stable their GIL-unlocked stuff is nowadays)

>Hence a thread on python and duckdb with a VFP-er perspective, you can potentially replace:
>1) the vfp interpreter by the python one, not a massive change, but of course the library support is just the largest and most pervasive one on our planet; whatever the domain it's a change of decade (one!),

see above... and for all "Internet" stuff there is mostly or only Rick on vfp side,
even IE via COM is now gone. Edge does allow integration, but the direct
access to DOM and Javascript is not there anymore (or messed up)

>2) vfp arrays by numpy ones; we are talking a change of decades (two at least!),

Yupp. Vfp arrays were "fast" only when compared to magnetic storage.
You can tweak on char / strings a bit when forcing fixed memory locations,
but matrix numeric work benefits more due to double wham of access and data typing.

>3) the rushmore engine by the duckdb engine; you could say three decades improvements,

Here my brain flashes "yellow alert" as I guess your tasks are more OLAP
than OLTP, confounding engine improvements with "best tool for the task" ;-)

>4) fll-optimized extensions with python equivalents and more such as numba extensions.

Yes, plus the high count of improvements a massive user base will bring

>Just now, not even having finished moving through this all information, the "mojo" project is just coming out in front of our eyes. Basically you work in an interpreter-like environment, yes python... But your code can possibly be faster in the end than C or C++:
>https://www.modular.com/mojo

I read the stuff - their table and description

Languages                  Time (S) *              Speedup vs Python
Python 3.10.9              1027 s                            1x
Pypy                         46.1 s                          22x
Scalar C++                    0.20 s                       5000x
Mojo 🔥                       0.03 s                      68000x

they specifically mention Scalar C++and run
* AlgorithmMandelbrotInstance on AWS h3-standard-88 Intel Xeon
which probably can throw oodles of cores at the task.

Cython should be in the same order of magnitude of Scalar C++ when holding
GIL in place, and if coding for multiple cores might also utilize many cores.
So you could say MoJo is Cython with halfautomatic parallel afterburner -
but the times cited are well in the realm of attainable -
although the 68000 is in error. Even runtime of 0.025 (rounded to 0.03)
would give only ~41000x speedup, never 68000x
For 68000x you need a runtime of ~0.0151s.
The last 4 numbers just flashed red alert on reading ;-))

>Well seeing is (not) believing, I will start tinkering the beast when it is available on Windows platform and open sourced. But the team behind the announcement of this beast, a language that includes both an interpreter (yep just python) and possibly the fastest "compiler du jour" (covering both cpu-s and gpu-s, including potentially exotic or complex ones) in a JIT way. You do not believe this is possible? Check Chris Lattner pedigree...

Supporting GPU / CUDA and similar stuff automatically is GREAT
(I stopped reading on that stuff 20y ago)
Doing things automatically / bottom up is probably better than to rely
on developers to optimize by themselves. I had hoped for some linter-style
tips or automatic output for typed function headers and var declarations,,
but this never happened. The division between runtime and code even created
ludicrous setups like Typescript, where you "transpile" typed code to run in
interpreted Javascript only to at least part-type again in JIT.
Unclear how Mojo sits on the interpreter/compiler/transpiler vector.

>
>What can you expect? Code in a fox-like environment, with a vfp-like syntax and produce code that runs fiffy times faster than an interpreter à la fox or python. This "mojo" will possibly be a killer of python C-based extensions, or compilers à la numba, lpython, pythran and others. Still an alpha project but already very promising:

Good for your use cases, but for me the "fox sauce" of
local buffered cursors either from local or remote data source,
tableupdate(), getnextmodified and a few other runtime functions
Cursoradapter properties and hook methods

are missing for the sort of apps vfp was miles ahead of other systems.
Having (at least a copy / function) of local data store in components is
going against my preferred "single source of truth"
>
>https://www.youtube.com/watch?v=g8Hz0LSSojM&ab_channel=LeetCoder
>
>I said "fifty times faster"... Well it can be way, way faster while working in a decent environment à la fox. As a developer, I'd be so glad to below 30 years of age to-day. But well, although you may not run as fast when approaching 34 years of age, you can still possibly code:-)

Well, back then we fought against memory, HD, network creating bottlenecks,
sometimes dropping to C, caching data at various levels -
whenever that was not enough, either farm out to many computers,
later Threads or Processes. Doable, but often involving heavy chin-ups.
Mojo seems to integrate current hardware optimization into a single system.

>I wish I were just 34. Not twice as much -:)

You are not alone...

>PS: the only thing missing, building high-end desktop UI-s is still a mess, a QT-based or a chromium-based one. But a large one!

Yupp, one of the reasons I looked at Javascript more in the last years than Python.
Anything running well on tablets / mobile nowadays in Python ?
I guess the "personal coding" or automation could be done in Python as well,
and the SQL "look around stuff" could be done everywhere with sane SQL integration,
although skipping through a cursor with several tables in relation is for me
still a great way to give hints to own grey matter...

regards
thomas

g8Hz0LSSojM