I usually do REPL driven development in Python via emacs but you can tell it's not the natural way to do things, esp. if you start doing stuff with async. But I still feel that it makes me way more productive than I would otherwise be

It has a Tk based REPL and debugger in the box, and I guess nowadays Jupiter notebooks is the closest to a Lisp Machines/Interlisp-D kind of development.

There are the IDE integrations as well.

Pity is the lack of (compile ...) and (decompile ....), or similar.

Which by the way is available in Julia.

Which incidentely has a much better history with JIT adoption than Python, where the community has largely ignored PyPy.

Meanwhile Ruby has had MacRuby from Apple, later canceled, but the main developers went out creating RubyMotion.

Sun toyed with JRuby, it was even officially supported on Netbeans, then Red-Hat supported the project for a while. It was also one of the first dynamic languages on GraalVM, with TruffleRuby. GraalPy effort only came a couple of years later, and is still on baby steps.

As of 2025, the refernce implementation counts with YJIT, MJIT, TenderJIT, and MRuby 4 brings ZJIT to the party.

Exchanging Lisp for Python we went backwards in regards to performance in dynamic languages, in a distopian world where C, C++, Fortran libraries are "Python" libraries.

Nope they are bindings, and any language with FFI can have bindings to those same libraries, e.g. PyTorch can also be used in straight C++, or from Java.

There is a good compromise with reflection, attributes, metaclasses, one line lambdas, comprehensions

Now the lack of machine code generation for something Lisp was doing in the 1960's, Smalltalk in the 1980's, SELF in 1990's, and having to fall back on C, C++ and Fortran is bonkers.

Thankfully this is finally becoming a priority for those willing to sponsor the effort, and kudos to those making it happen.

I would rather use Common Lisp, in something like Allegro, but I will hardly find such a job, thus only arguing about language features doesn't take us that far.