Lua is a Lisp-lite, Ruby maybe a Lisp-lite, Python? No way, I'd go as far as say that Python is antithetical to the Lisp philosophy and yes, I know Norvig has claimed something similar in the past. It's still inaccurate and wrong. In an interview, Norvig pretty much admitted that popular appeal is more important to him than the inherent superiority [which he of course acknowledges] of the philosophy behind Lisp.
CLOS is metacircular, implemented in itself. Moreover, it decouples state (classes and instances) from protocol (generic functions and methods) and through the MOP allows you to reprogram every aspect of its behavior.
Python's object system suffers from the same ailments that Python itself does. It's an amalgamation of various hacks, some obviously inspired by Common Lisp [1], others made up on the spot in order to make everything "fit" together.
In order to best see this, browse CPython's source and find how metaclasses are implemented. Then imagine what you would have to do if you wanted to radically change Python's object system. Contrast with the Common Lisp MOP.
[1] Here is Guido talking about Python's metaobject protocol. Taking into account everything it lacks and how it's implemented, it's not really a metaobject protocol in the CLOS sense, but it's enlightening to read GvR's description of his "aha!" moments in the slides -- which he came upon when he read "The Art of the Metaobject Protocol" -- and then realize that he simply picked very few of the ideas from it whilst completely missing the essence:
So yes, Python has metaclasses but metaclasses are only ~5% of what makes CLOS (and AMOP) iconoclastic. For the rest, read "The Art of the Metaobject Protocol" [2]. This should convince you that Python is really nothing like Lisp and the philosophy of metaprogramming that Lisp espouses is dumbed down and made pretty much powerless (in a similar way, interactive programming) in Python.
CLOS (as well as a lot of other things in Common Lisp, like the error system) depends on CLOS being present. This is why writing a competent CLOS compiler that can bootstrap itself is very difficult. But it's so worth it.
The canonical implementation (PCL) was written in pre-ANSI CL without CLOS. There's a number of things that are difficult there, but can't put my finger on any related to bootstrapping.
Never meant to say python metaclasses were equal to CLOS MOP. But the spirit of programming at the OO metalevel is very much similar to what CLOS is about.
Besides Google, I find Wikipedia is often helpful when finding acronym definitions as well. In this particular case, probably adding "Lisp" to your Google search would have helped, but if you didn't know it was limited to that domain, it's understandable that you didn't include it.
CLOS is--IMHO--the most advanced object system ever invented. The freedom that comes from CLOS is mind-blowing. Learning what CLOS can do will make you hate every other object-oriented programming system.
Very true. And the most mind blowing thing? CLOS is implemented in Lisp itself using macros. So as a Lisp user, you are able to extend the language to include the best implementation of any particular paradigm that exists.
The original first CLOS implementation called PCL (Portable CommonLoops) was written in 100% Common Lisp with very little implementation specific CL code. PCL was a library which ran on at least 15 different Common Lisp implementations.
What really is a myth that it's (only) macros. That CLOS implementation is a complex library written as data types, functions, macros, ... and which was bootstrapped to be partly written in itself using classes, method, generic functions, ...
I wish there was a way to compare Google searches of today with Google searches of years ago, I feel like they've been declining in quality and relevance even as I'm sure they've improved their algorithms and even with me letting them know more about me via remaining signed in when I search. Using the "date range" tool to set a maximum date on search results (in this case I just randomly picked "2006", which Google interprets as the end of that year) I get two CLOS results as the first two items and a third one a bit further down, so that method helps me sometimes, but it's not the exact comparison I want...
You can write lisp-y python quite easily. It's not good, pythonic or maintainable, but for learning purposes it is acceptable, especially on the 2.x series. Just start with list comprehensions.
Lua and Ruby I fail to see how they are in any way lisp-y.
Ruby: Almost everything is an expression unlike Python, has symbols unlike Python, closures and anonymous functions are not crippled or second-class unlike Python, has full continuations unlike Python.
Lua: Simple, minimal syntax which is consistent (unlike Python), multiparadigm, designed around one core datastructure, metatables/metamethods, metaprogramming is encouraged, has environments.
If by lispy you mean data oriented code with functions instead of classes and composition, I'd argue that it's not only pythonic, but import this compliant.
I got the impression that Hy is stagnating. They removed 'let' in the recent releases (it's hard to imagine Lisp without 'let'). Also there is no support for async, which is pretty important for modern Python IMO.
hy 0.11.1 using CPython(default) 3.5.3 on Linux
=> (cons 1 '(2 3))
(1 2 3)
hy 0.15.0 using CPython(default) 2.7.13 on Linux
=> (cons 1 '(2 3))
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/hy/importer.py", line 199, in hy_eval
return eval(ast_compile(expr, "<eval>", "eval"), namespace)
File "<eval>", line 1, in <module>
NameError: name 'cons' is not defined
Lua is a Lisp-lite, Ruby maybe a Lisp-lite, Python? No way, I'd go as far as say that Python is antithetical to the Lisp philosophy and yes, I know Norvig has claimed something similar in the past. It's still inaccurate and wrong. In an interview, Norvig pretty much admitted that popular appeal is more important to him than the inherent superiority [which he of course acknowledges] of the philosophy behind Lisp.