I don't think mixing the two is good. I think the lack of implicit progn would be a Good Thing. The explicit progn makes non-functional code stand out, and it also makes the language a bit more uniform if no primitives have implicit progn. All other things being equal uniformity is good because it reduces surprises.
Unless there are a lot of people who feel like the implicit progn is an important part of "let" I'd prefer to not have it.
you can't for this specific problem, where functions are being called from an expanded macro and are shadowed by a local variable- look at the examples in the post.
This probably isn't the sort of thing that pg is talking about, but what I would like is a large and modern standard library.
I do most of my exploratory programing in python these days, not because I like it better than CL, but because I don't want to spend 6 hours tracking down a library that does X that is compatible with CL implementation Y I happen to be using. It seems like the only truely universal extension to CL since the ANSI spec was written is gray streams. The best case scenario is I find an asdf package, and it happens to work with the implementation I am using.
However, most of the time I'll install it on CLISP and it won't work, then try it on SBCL and it does (or vice-versa).
With Python, I just load up the module reference and spend 5 minutes finding the module that ships as part of the distribution that does what I need.
CL doesn't even have a standard way to connect to a UDP socket. That's a minor thing in and of itself, but I've never tried to prototype any significant program and not run into something like this.
I think the creators of Arc get this, since one of the things included is a webserver. Also, having a central clearinghouse for the language and having the implementation be the documentation both lend themselves well to allowing a large standard library to grow, so I am very hopeful.
After all, Python did not have any sort of impressive library in 1991 when Guido first publicly posted it (it did have a module system though hint-hint).
Seconding on the module system. It may not be the biggest concern of a young language, but it's a big part of the infrastructure that will let the language grow.
And don't forget good documentation, preferably built-in. Whenever I am exploring something I haven't done before, it's a great boon not having to read the sources, or even look it up on the web. Python's help() is wonderful.
I'm going to have to wait and see on this. I'm sure I'll get used to it. Right now, the bigger difference for me is the lack of #'s everywhere. I agree that doing away with the dual-namespace nature of common lisp is a good thing, but I had never realized how much it affects my reading of code.
I'm guessing in the long run, I won't miss #'zerop but it certainly does look strange at the moment.
