Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Replacing a Fox with a Mojo... That's a killer beast killer!
Message
From
15/09/2023 06:20:08
 
 
To
All
General information
Forum:
Visual FoxPro
Category:
Other
Title:
Replacing a Fox with a Mojo... That's a killer beast killer!
Miscellaneous
Thread ID:
01687063
Message ID:
01687063
Views:
130
Hi all of you,

I posted a message on python a couple of months ago, "Replacing a Fox with a Duck... Beware that's a killer beast!". As I re-discovered the python eco-system after twenties "off the grid", stuck on improving a good ol' VFP app, I was impressed by what I could achieve within python.

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.

Two years ago I discovered I could still use python, much in the way of my old two-wheeler after all these years :-) But I found as well that I got support for incredible horsepower. The one I was looking for to rewrite a very demanding visual application.

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!),
2) vfp arrays by numpy ones; we are talking a change of decades (two at least!),
3) the rushmore engine by the duckdb engine; you could say three decades improvements,
4) fll-optimized extensions with python equivalents and more such as numba extensions.

What can be achieved? Speed improvements that would move from an order of magnitude (yep 10 times as fast!) for data based storage and mangling (duckdb instead of rushmore or db engines) to two or more (yes to 100 times faster!) for sheer data crunching (numpy and numpy compilers à la numba.

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

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...

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:

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:-)

No need for fll code anymore. No need to learn C++ or C#. I'm stuck on C by the way! Tech-wise, great times to be a developer in 2023 and even as an ex-vfp die-hard. It has never been a greater time to work with those wonderful and cheap multi-core gpu-assisted machines we have literally at hand...

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

Daniel

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!

g8Hz0LSSojM
Next
Reply
Map
View

Click here to load this message in the networking platform