8 ms·

This question sounds like it's from 2005 rather than 2010. Lisp seems to have become fashionable again now, thanks to Clojure. I'm sure Python has very good l

• metageek 16y ago
  The problem with the Blub paradox is that there's no total ordering. 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.
  • pg 16y ago
    I did mention in the original essay that it was only a partial order, in footnote [4].
    • metageek 16y ago
      Sorry, I haven't read it in a while.
    • tome 16y ago
      Ah, but metageek's point is that it's not an order at all. It contains cycles.
  • jcromartie 16y ago
    I can't help you with strong typing, but I'm pretty sure a macro would go a long way towards implementing RAII in a Lisp.
    • metageek 16y ago
      That's true; we've already got special cases like WITH-OPEN-FILE.
      • masklinn 16y ago
        Actually, you already have something better than RAII in unwind-protect. Just create whatever macro you need on top of that (I'm pretty sure with-open-file is just a macro on top of unwind-protect, Siebel seems to agree in his chapter on files) and you're done.
    • masklinn 16y ago
      > I'm pretty sure a macro would go a long way towards implementing RAII in a Lisp. Well yeah, just build the macro you need on top of unwind-protect, that's pretty standard common lisp fare.
  • swannodette 16y ago
    What about Qi? What about Typed Racket?
    • djacobs 16y ago
      One question I've had about Typed Racket since I first saw it: why all the colons? Seems to mess with the elegance of Lisp, and especially Scheme. There has to be another friendlier syntax for typing, no?
      • manu3000 16y ago
        why not ? colons are used to denotes values type in ML
    • namekuseijin 16y ago
      Typed Racket combines all the inconvenience of type declarations with all the performance provided by a dynamic language.
  • DanWeinreb 16y ago
    Hello, my co-worker, whoever you are. Yes, Common Lisp should have dictionary literals. I don't know why there hasn't been a commonly-used reader macro for this. (Emacs Lisp mode and other tools would have to know about it, so it needs to be a widely-accepted convention.) 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.
    • metageek 16y ago
      Hello, my co-worker, whoever you are. 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.
      • chaitanya 16y ago
        > I haven't used much CLOS, since ITA avoids it. Interesting. Is it for performance reasons?
  • lisper 16y ago
    > in Lisp and C++ I miss dictionary literals So roll your own. Or use mine: http://flownet.com/ron/lisp/dictionary.lisp http://flownet.com/ron/lisp/dictionary.lisp
  • akkartik 16y ago
    Why do you miss dictionary literals? Syntax similar to arc's seems to do it for me: (obj a 1 b 2 c 3)
    • gruseom 16y ago
      We do the same thing: (make :a 1 :b 2 :c 3) which macroexpands into a plist in CL and {a:1, b:2, c:3} in JS. I've grown to like this idiom a lot. Yeah, you have to type OBJ or MAKE or whatever but in return you get something that integrates completely smoothly with the rest of the language.
    • metageek 16y ago
      Y'know, I'm not sure. Next time I need to use a hash, I'll create something like that and see how it feels.
  • milesvp 16y ago
    Forgive me, but I think you mean in python you miss static typing. 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. http://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic%20language%20and%20also%20a%20strongly%20typed%20language http://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic%... http://www.artima.com/weblogs/viewpost.jsp?thread=7590 http://www.artima.com/weblogs/viewpost.jsp?thread=7590 http://en.wikipedia.org/wiki/Duck_typing http://en.wikipedia.org/wiki/Duck_typing http://articles.sitepoint.com/article/typing-versus-dynamic-typing http://articles.sitepoint.com/article/typing-versus-dynamic-...
• deadwisdom 16y ago
  The Python philosophy is that macros do more harm than good, making it harder for someone to read/understand your code in the long term. These and other "constraints" make the code more accessible to others and even yourself.
  • aidenn0 16y ago
    Macros are just another abstraction tool. If you poorly use an abstraction tool, it makes the code harder to read, if you properly use an abstraction tool, it makes the code easier to read. Here's a function that makes code harder to read: def sumAList(aList): return 7 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.
    • deadwisdom 16y ago
      Yes, but any given function is usually extremely easy to understand, because it's only, say one level of abstraction, then a macro is a few levels higher than that. And as you go up in your levels of abstraction, it gets harder and harder to really understand what's going on. 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. 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.
      • aidenn0 16y ago
        Hmmm. I think your argument is roughly that there is a "sweet-spot" for abstraction when it comes to readability? 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.
• illumen 16y ago
  Macros can be used in python. There are a few libraries that help make it easier(so you do not need to manipulate the ast yourself). For example: @macro def macroname(arg1, arg2): ... macro contents ... There's some current information for you old time lispers, so next time you don't sound so dated in your Battles with Trolls in the great never ending language war flames ;)
  • forensic 16y ago
    I like how you imply that you don't participate in the language wars. When you just did.
  • deleted 16y ago
    [deleted]
  • apgwoz 16y ago
    Link? The only "macro" library I've seen for python has been "MetaPython" (http://metapython.org/ http://metapython.org/), which is more of a let down than it is useful, unfortunately.
  • jpr 16y ago
    Even if that happened to work correctly (which I don't believe), you would still be missing a bunch of macro-related stuff that makes CL the programmable programming language it is, and Python isn't: -reader-macros -symbol-macros -compiler-macros -macrolet -symbol-macrolet EDIT: Fixed layout
    • lpsmith 16y ago
      Well, those kinds of claims are kind of par for the course for the Python community. I remember that it was commonly claimed that Python 1.5 had the "full power of the lambda calculus", when all it had was anonymous function definitions, and not true higher order functions.