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.
I had a colleague who was hostile to any language other than common lisp. Except python, which I assume is just because this page exists. What if norvig woke up that day and decided to write about Ruby instead?
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.
What's Python's story for repl driven development ?
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.
I had a colleague who was hostile to any language other than common lisp. Except python, which I assume is just because this page exists. What if norvig woke up that day and decided to write about Ruby instead?
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.
Python community -- meet Schrödinger's cat
Without s-exprs nor macros? Without reader? With its stupid statement/expression divide?
...Right.
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.
a lambda that forces you to define a function elsewhere if you want to do anything nontrivial in it defeats the purpose