I'm sure Python has very good libraries, but I would find it constraining to program in a language without proper macros.
I do Common Lisp and C++ at my day job (ITA), and I do much of my personal hacking in Python. In Python and C++ I miss macros; in Lisp and Python I miss RAII and strong typing; in Lisp and C++ I miss dictionary literals.
And, in all of them, I miss algebraic datatypes.
Common Lisp does have strong typing. What it does not have is static typing.
I am at the SPLASH conference, and the Dynamic Language Symposium is happening right now. There is controversy over whether we can find a way to have the benefits of both static and dynamic typing in the same language. The great advances in type inference make me hopeful. The keynote speaker, Allan Wirfs-Brock, replied to my question about this with more pessimism. It is not a simple question; for one thing, not everybody even agree about which factors are "pro" or "con" for either static or dynamic. I am not doing programming languages these days (I'm doing databases) but I continue to be hopeful.
John Stracke. (I've been staying pseudonymous, but today I mentioned Adder, which is tied to my real identity.)
Common Lisp does have strong typing.
True. I need to remember to be more precise; "doesn't have strong typing" just means "doesn't have type feature Blub". Common Lisp has runtime type safety, and type hints for efficiency; what it does not have is the pervasive typing that I'm used to from C++, which has a separate set of benefits. The most obvious is that, in C++, I can change the interface to a class and be certain that the compiler will catch any caller that uses it incorrectly. (Although I suppose it may be possible to do something like that with CLOS. I haven't used much CLOS, since ITA avoids it.)
There is controversy over whether we can find a way to have the benefits of both static and dynamic typing in the same language.
I'd say that type inference already brings us nearly there: the convenience of dynamic typing, with the rigor of static typing.
I may be wrong, though; I've used ML and Haskell, but not enough to really feel where the pain points of type inference are.
That might be less precise, but more correct :-P.
"Common Lisp has runtime type safety, and type hints for efficiency; what it does not have is the pervasive typing that I'm used to from C++, which has a separate set of benefits. "
The type declarations aren't just for efficiency (although they are frequently (ab)used for it).
"The most obvious is that, in C++, I can change the interface to a class and be certain that the compiler will catch any caller that uses it incorrectly."
I'm not sure what common lisp version you use, but wouldn't this be fixed by simply declaring types of everything? You can declare the types of on the slots of a struct, you can declare the types of arguments to functions, results of functions, variables, slots of objects, contents of sequences... (having trouble thinking of something you can't declare types on, maybe a hashtable? Although you could wrap the accessors in a function).
Then SBCL (at least) yells at you when you go to recompile the project.
Yes, but I'm not so sure about the "simply". It's only marginally easier in C++; but at least you know that haven't forgotten to declare anything.
Interesting. Is it for performance reasons?
Python is strongly typed.
Also, just to jab at C/C++, pointers to void... really? It all but makes C/C++ a weakly typed language.
So roll your own. Or use mine:
Well yeah, just build the macro you need on top of unwind-protect, that's pretty standard common lisp fare.
(obj a 1 b 2 c 3)
(make :a 1 :b 2 :c 3)
There has to be another friendlier syntax for typing, no?
Here's a function that makes code harder to read:
This doesn't mean that functions are bad.
Now there is an argument that macros make code harder to read in that I've yet to see a really good macro system that isn't dependent on the code having very little syntax (e.g. S expressions), since the more different the code is from the AST, the harder it is to manipulate the code successfully.
Combined with the fact that more syntax can make code much easier to read, there is a conflict here.
However, I don't think that's the argument you are making.
This is also essentially the argument against global variables.
For hygienic macros, I don't know of a good argument that they are inherently more difficult to understand separately from their invocation than a function.
(I'm not personally arguing against macros - or global variables for that matter - just trying to state the argument).
Full macros (like in CL where they are just functions that don't evaluate their arguments) give the programmer same power as compiler writer or programming language designer.
ps. To really get benefit from Lisp macros, you would need to standardize code walker. Without code walker, macros can't reach their full potential.
I think we shouldn't be limiting our tools. We should instead limit their use. Global variables can be nasty, but it's nice to have them when your code is best expressed with global variables. Same for macros.
I also don't mean to imply that Lisp is lesser for using macros. I love Lisp and any implementation clearly requires macros. But Lisp is also, undeniably, harder to read for this and other reasons.
That is a point at which less abstraction makes the code harder to read, and more abstraction makes the code harder to read?
I will agree with this in specific cases (i.e. for any given solution, there is a point at which adding abstraction can't improve readability), but I'm not certain I agree in the general case (i.e. that using macros cannot improve readability).
I guess it also depends on what you mean by "really understand what's going on." I started out programming in C. Now in C, if you know your compiler well, you can predict fairly accurately what binary code will be generated when you compile with optimizations off. Moving to higher level-languages you lose this ability, and no longer "really understand what's going on."
For systems programming, I may still use C to get this advantage. For other problem domains, I sacrifice this knowledge because representing my problem more tersely in a higher level language makes the code more readable and easier to understand. Now I will never know exactly which instructions will be executed when I write in Python.
Similarly, with sufficiently fancy macros, I may not know what LISP code is generated, but if the macros do what they say they do, it can make my code less verbose, more understandable, and easier to maintain. There are times when really understanding what is going on trumps the terseness, and those times I don't use macros.
Also, I love Python. It embeds well in C (which is where my original background is), and it has very good portability, and a good set of libraries.
I also implied, but didn't say straight out that Python has a good reason for not having macros: Part of its design is to look like pseudo-code. See also Norvig's comment to the OP. Macros that operate on text rather than trees (C preprocessor, m4, etc) are far more error prone, and probably a Bad Idea. Therefore if you want your language to look like something other than a tree, you have to forsake macros that operate on code as it is written. I have seen for several languages (Python among them I believe) Lisp-like macros that operate on the AST of the language. They have not caught on. I have several theories why this is so, but right now my preferred one is that it feels too much like you're hacking the compiler, and Compilers Are Scary.
I think what you implied just before that is a stronger argument: it's way too distant from the base language, and this semantic distance is so costly that it's not worth the trouble.
There is a difference between abstraction and indirection. Just because you've added the latter doesn't mean you've gained any of the former.
"Sure, some macros are intuitive and easy to follow, but those are usually easily replicated with other things, especially in a dynamic language like Python."
How would you implement SETF in Python? Or how about compile-time link checking for a web application (http://carcaddar.blogspot.com/2008/11/compile-time-inter-app...)?
do this and that and that too
No branching nor decision trees as not to confuse common folk. Now programming is a socially acceptable activity!
There are a few libraries that help make it easier(so you do not need to manipulate the ast yourself). For example:
def macroname(arg1, arg2):
... macro contents ...
EDIT: Fixed layout