[drcode]

I think most people switching from Lisp to Python do so for practical reasons. I suspect Peter Norvig probably wouldn't use as much Python if he didn't have to adapt to the Google culture.

I think Python is a surprisingly nice language in many ways. It falls into the category of being an "acceptable Lisp". But I think most Lispers still prefer the real thing and only use Python when they need to be pragmatic.

[poet]

I don't know of any Lisp programmer who thinks Python in an acceptable Lisp. In fact, there are some things about Python that are completely unacceptable as far as a Lisp goes: (1) crippled lambda, (2) no easy way to pass chunks of code around, etc.... Obviously not having macros is a given in anything but Lisp. Ruby (because of blocks) is far more of an acceptable Lisp.

[drcode]

Yeah, the lambda issue in Python is definitely not very Lispy.

But I think even though Ruby offers a bit more for Lispers, I just don't like the design of the language as much in general as Python. If I don't code Python for a year and have to delve into it again it takes only a few seconds to get back to speed again. In Ruby, on the other hand, I always forget how the blocks & variables behave and am thrown by the strange predicate syntax, making this far more unpleasant.

[ngvrnd]

I agree, I like Ruby better both for the syntax, the cleaner oo integration, and so on -- but a year and a half away from each, I can pick up the Python again a lot quicker. And python is friendly to scripting, low-level and embedded applications, which Ruby (Matz) is not interested in.

[DanWeinreb]

I agree. But if you find yourself with an employer who requires that everything be written one of a few languages, and Lisp isn't on the menu, I'd take Python over C++ in a heartbeat.

[bad_user]

> Obviously not having macros is a given in anything but Lisp

At least these languages (that I know of) have macros:

    http://boo.codehaus.org
    http://nemerle.org
    http://www.perl6.org

[drcode]

True, but the syntax for all three of these is pretty hairy.

Lisps might not be the only languages with macros, but they're the only ones with elegant and easy to use macro systems.

You could argue of course this is a moot point, since even Lispers only write macros infrequently. So who cares if it's hard to write one on the rare occasion you need to?

[middayc]

I am amazed that people say Lisp is about macros. I think it's about being homoiconic. You can make some ugly form of macros in ANY language. Homoiconic-ness is what makes you want to make macros with Lisp. But it is much more than just about macros. Language REBOL is for example fully homoiconic.

  >> a: [ 300 3 ]
  >> insert a 'add
  >> probe a
  [ add 1 2 ]
  >> print first a
  add
  >> do first a 100 1
  == 101
  >> do a
  == 303
  >> f: func [] a
  >> f
  == 3
  >> change second :f 'subtract
  >> f
  == 297

all code is data (blocks of words and values).

From * Io * example below I would say it's a little different. It's more like it has a runtime api to change/generate it's runtime. I think SmallTalk has something similar to this.

* Factor * has compile time macros. At runtime it has quotations, which are blocks of code (separate from it's other data strucures I think, but don't shoot me if I'm wrong) that can be modified and executed by your code with few specific words like curry and compose. This means you have a little less freedom than in rebol where block of code is in no way different than a block of data. What is awesome about factor is that it also compiles quotations at runtime.

Otherwise Factor is very very cool, and I envy some runtime features of Io a lot.

And Python has as little to do with lisp as Visual Basic. Python is the world's best dynamic Imperative lang IMHO :)

[draegtun]

From Io example below I would say it's a little different. It's more like it has a runtime api to change/generate it's runtime. I think SmallTalk has something similar to this.

In Io, all code is data. Below is an example of changing a functions behaviour (from addition to subtraction):

    Io> plus := block (a, b, a + b)
    ==> method(a, b, 
        a + b
    )
    Io> plus call (1, 2)
    ==> 3
    Io> plus message next setName ("-")
    ==> -(b)
    Io> plus
    ==> method(a, b, 
        a - b
    )
    Io> plus call (1, 2)
    ==> -1

ref: Io Has A Very Clean Mirror (WayBackMachine copy) - http://web.archive.org/web/20080212010904/http://hackety.org...

[middayc]

Very cool!

There are few properties about concurrency, coroutines, embed-ability, and I suppose nice process of making bindings that I value really a lot and Io HAS. Looking at your example, I will definitely look again at Io. Thanks!

[draegtun]

Io (http://www.iolanguage.com) is a bit of an exception then.

Its homoiconic but its not a Lisp. And it doesn't have macros yet its code is fully inspectable/modifiable at runtime in an very easy & elegant way.

For eg. if you wanted to have a line like this:

    list(1, 2, 3) each foo bar

which needs to be transformed into below at runtime:

    list(1, 2, 3) foreach(foo bar)

Then this can be done like so:

    List each := method(
	m := call message
	m setName("foreach") setArguments(list(m attached)) setAttached(nil)
	self doMessage(m)
    )

ref: http://www.iolanguage.com/blog/blog.cgi?do=item&id=86

[bad_user]

Does it have lazy evaluation?

[draegtun]

Yes. The List each above is acting lazily.

Here is a better example of how it works: http://news.ycombinator.com/item?id=1627777

[poet]

You could argue of course this is a moot point, since even Lispers only write macros infrequently.

This simply isn't true. In fact it's so far from the truth it hurts my brain. Well written Lisp applications are in large part (and sometimes mostly) macros. PG once mentioned that the ITA guys said over half of their codebase is (was?) macros.

[drcode]

Can you find the quote? I'd be surprised to learn that.

For my own code, it consists of maybe 10% macros. I would say the same is true for PG's code (for the hacker news app- The arc core libraries have more macros but are a special case.)

Unless, of course, if you mean _calling_ macros- I would agree that Lisp code often has 50% of its calls be macro calls instead of function calls.

[technomancy]

50% code by volume being macros sounds terrifying.

Macros are like 2nd-amendment rights. You hope you never have to use them, but when you do you'd be in a world of hurt without them.

[technomancy]

Factor supposedly has macros; from my cursory knowledge of the language I could see them being as convenient as Lisp.

[silentbicycle]

Forth and Prolog also have static metaprogramming via transformations on the parse tree, i.e., Lisp-style macros. They're not emphasized as much in Prolog, though.

[poet]

If your language doesn't have Lisp syntax (or more precisely, a lack of syntax entirely) writing macros will be very unpleasant. How are you going to logically think about manipulating the structure of a program that looks like C# or Perl? Macros are already difficult enough to get right as is, without introducing the problem of syntax. Those languages don't have macros any more than Python has a lambda.

[chromatic]

How are you going to logically think about manipulating the structure of a program that looks like C# or Perl?

In Perl 6, you extend the active grammar within a delimited scope.

[poet]

My point still holds, just replace manipulating the structure of a program with manipulating the structure of a grammar. In no way is that comparable to manipulating raw parse trees.

[bad_user]

But you are manipulating parse trees: surely you have to add new grammar rules to the parser, but then the macro itself does just that.

Furthermore, when adding syntax you are not limited to a Lisp-style grammar.

[cdavid]

At least P. Norvig things python is an acceptable language, if not LISP. I think the point about being optimized for small teams is a significant one. Also, because LISP appeals mostly to programmers, but it often "repeals" people with expert knowledge (e.g. scientists without a strong programming background). P. Norvig mentioned that when he converted his AI book from Lisp to python code examples, it seemed much more natural to most people,

[drunkpotato]

I think you meant "repels", unless you meant "refudiates", though perhaps your finger stumbled in the middle of "repls".

[_cbsz]

"refudiate" isn't a word (though it appears to be a Palin-ism -- http://www.urbandictionary.com/define.php?term=Refudiate). Perhaps you meant "repudiate?"

[cdavid]

I have at least the excuse of not being a native speaker, contrary to S. Palin :) Thanks for the correction.

[silentbicycle]

I think the phrase "acceptable Lisp" itself needs to go away. It's caused quite a bit more heat than light.

Python is a great language, sure, but it's not a Lisp, and it's best appreciated on its own terms. Both because Lisp and Python really aren't very similar, and because people coming to Python with transliterated Lisp idioms are going to be disappointed.