Disclaimer: I miss Lisp too, and have noticed myself wishing I could define new syntactic constructs in Python.
That being said, there is something of a difference between hating Perl and saying that Lisp loses because it's too good and you have to be too smart to understand it. In short, Perl fundamentally sucks in ways that impact your life in big ways on a day-to-day basis. Python does have its problems, and it sucks in some respects, but I would claim that it doesn't reach nearly the level of fundamental suckage on an absolute scale that Perl does.
And, moreover, while Lisp fails to suck in certain ways that Python sucks, it ruins your life in other ways that Python doesn't. For example, I use lots of numpy/scipy/matlab/what-have-you style code. I also use lots of Cairo/GTK. In Python, all the stupid crap to take care of doing that in a Python-idiomatic way has been done already; it's known as pygtk and pycairo, and it's available in every package manager I care about.
In Lisp, all that stupid crap has not been done, or if someone has tried, they have not achieved remotely the level of polish of the Python version. So if I want to use Lisp, I have to spend a pretty big quantity of time becoming the maintainer of the equivalents of pygtk, pycairo, etc., and at least last I checked, the amount of crap and slowdown involved there was much greater than the amount of crap and slowdown that resulted from Python's various sucky bits (slowness, lack of threading, lack of macros, shitty lambdas).
And, moreover, Lisp's lack of syntax is a big win in some kinds of code, but in other kinds of code, it's pretty horrible; for example, with Numpy, I can say
and that's going to be several times more succinct than writing my own slicing code and then having to say 'aref' or equivalent for each node in the syntax tree where there's some array indexing going on. In other words, syntax makes the common case fast for some very key common cases.
So saying that a key part of why Lisp fails is because it's too good and people have to be too smart to understand it is mischaracterizing people who decide to use Python because they don't want to deal with the library problems and lack of common-case syntactic convenience.
(I'm not wedded to being one of the latter people, but I do think that there are some strong points in that direction.)
That being said, there is something of a difference between hating Perl and saying that Lisp loses because it's too good and you have to be too smart to understand it. In short, Perl fundamentally sucks in ways that impact your life in big ways on a day-to-day basis. Python does have its problems, and it sucks in some respects, but I would claim that it doesn't reach nearly the level of fundamental suckage on an absolute scale that Perl does.
And, moreover, while Lisp fails to suck in certain ways that Python sucks, it ruins your life in other ways that Python doesn't. For example, I use lots of numpy/scipy/matlab/what-have-you style code. I also use lots of Cairo/GTK. In Python, all the stupid crap to take care of doing that in a Python-idiomatic way has been done already; it's known as pygtk and pycairo, and it's available in every package manager I care about.
In Lisp, all that stupid crap has not been done, or if someone has tried, they have not achieved remotely the level of polish of the Python version. So if I want to use Lisp, I have to spend a pretty big quantity of time becoming the maintainer of the equivalents of pygtk, pycairo, etc., and at least last I checked, the amount of crap and slowdown involved there was much greater than the amount of crap and slowdown that resulted from Python's various sucky bits (slowness, lack of threading, lack of macros, shitty lambdas).
And, moreover, Lisp's lack of syntax is a big win in some kinds of code, but in other kinds of code, it's pretty horrible; for example, with Numpy, I can say
myarray[where(other_array > 0)] = foo(bar(5))
or
myarray[:, baz(bum(4)):baz(bum(5))][bum(baz(6)):, :]
and that's going to be several times more succinct than writing my own slicing code and then having to say 'aref' or equivalent for each node in the syntax tree where there's some array indexing going on. In other words, syntax makes the common case fast for some very key common cases.
So saying that a key part of why Lisp fails is because it's too good and people have to be too smart to understand it is mischaracterizing people who decide to use Python because they don't want to deal with the library problems and lack of common-case syntactic convenience.
(I'm not wedded to being one of the latter people, but I do think that there are some strong points in that direction.)