quote:Original post by bishop_pass
But does this help or hinder you? Part of the idea of Lisp is to get it to modify components of its own program at runtime, which means it needs to be able to pick it apart at runtime.
quote:Original post by vtwin
Personally I''ve never needed to employ something of that nature, so Lisp''s ability to do so has no bearing on me. Like I said, I have little experience with Lisp so my opinion is purely based on my history.
What''s being talked about is
introspection , which Python can do aswell. Only, it''s a lot more difficult with Python since, like all Algol-derivatives, it has a two-level syntax (or three-level, but we''re not interested in the bytecode representation). Once you have an environment which puts a layer of arbitrary syntax between you and the abstract representation of your program, anything that you want to do to manipulate the abstract representation immediately becomes an order of magnitude harder.
For example, imagine you wanted to create a class on-the-fly. In Python, internal representation of objects consists of trees built with recursive dictionaries, which is exactly synonymous with Lisp cons cell structures (a cons cell is a two-item pair, and so is a dictionary entry). So to create a class, you would have to construct the class dictionary, and instantiate the class from some metaclass. To illustrate:
def standard_initialiser(inst, x): inst.x = xdef foo(inst): print inst.x def make_class(name, methods=[]): classdict = {} # add methods for method in methods: classdict[method.func_name] = method # add constructor classdict[''__init__''] = standard_initialiser # "type" is the metaclass... return type.__new__(type, name, (), classdict)C = make_class(''C'', [foo])c = C(10)c.foo() # prints ''10''
So, it is easy to see that the Python syntax is far removed from the internal syntax of recursive dictionaries. In Lisp, you could achieve the same thing by building an s-expression and submitting it to DEFCLASS, where the s-expression *is* the abstract representation. i.e. you build the class the same whether you do it at runtime or compile-time.
It is easy to say that the ability to do such things has no bearing on you when your language makes it hard for you to think about them. I doubt that these abilities aren''t useful to you, just that the syntactic barriers in Python makes it harder to conceptualise how they might be useful.
quote:Original post by Dauntless
What surprised me was how slow Python was...I mean...it''s..slower.....than............java(sorry 
). Conversely, I was surprised at how fast Lisp was. Also, it mentions that basically Python is a dialect of Lisp with one crucial feature missing....macros.
There''s more features missing, but whether they are crucial depends on your point of view. For example, program compilation is not a standard feature of Python. Neither are declarations, which are useful for providing information to the compiler for optimisations. There''s also something extra that Python has which takes something away, and this is the extra layer of syntax I described above. Lisp''s syntax looks "funny" for a reason. To seamlessly add macros into Python, it would have to adopt a Lisp-style syntax, otherwise there would always be a syntactic barrier to building recursive dictionary structures. Since macros are about manipulating code as if it were data, you need the same representation for code and data.
quote:
I''m thinking of tackling Python next because I hear it''s good as a scripting language for game usage. Python supposedly has good hooks into C++, and it''s also very extensible through its modules. Does Lisp offer the same features?
Yes.
