A few years back I tried Franz Common Lisp and it was the best tool I have ever used for developing a GUI (you can make changes to the app while it is running, find an error, fix it and try again (and this includes the GUI), the only problem is the cost, I couldn't afford it, even if I managed to convince my employer to use a Language which almost no-one (who isn't a programmer) has ever heard off, they could afford it either.
When I found Python it was really the next best thing (in the interim I had messed about with Haskell and Prolog). Now I'm not the only Lisper who has ended up in Python, the lambda expression was only ever included because so many ex Lisp programmers where asking for it. Strangle I've never really used it (lambda's work great in Lisp but they just don't seem to fit in python, its an element which doesn't fit).
The other good points in my opinion:
- Interfaces are implicit. Nothing annoyed me more in java that exceptions based on the compiler telling me this is the wrong type of object. I don't care if it implements a next() method I will not call it. With dynamic typing the system will happily call my next method.
- meaningfully whitespace. Using a return to denote lines of code is an excellent idea for so many reasons:
- Lines of Code can have a definite meaning, there is no point in arguing about this, what constitutes one logical line of Python code is defined in the Language reference.
- How many times has the average programmer forgotten to press return at the end of a line? How many times has the same programmer forgotten a semicolon ? Most C text books will have a paragraph which goes something like this, because semicolons delimit statements it is possible to put more than one statement on the same line ... But this can make your code harder to read and is considered bad style. These days when I write JavaScript I don't put the semicolons either.
takes this a step further be implicitly creating properties based on the existence of _get_ and -set_ methods this is a very pythonic approach.
what's missing:
There are also a couple of features I would like to see:
Delegation: this is a neat feature of Delphi (I will go out on a limb and say the only neat feature) claim to the world that you have implement interface X and then delegate it to a member variable. In essence this is a tool for avoiding typing which will generate a whole set of stubs for you such as
def method(self, *args, **kwargs):
return self.member.method(*args, **kwargs)
I have some Ideas about how to add something like this to SQLObject, which I'll be talking about in my next post.
Macros: Someone coming from C will have a long list of why macros are bad and dangerous. The problem is that the C macro pre-processor is not a true part of the language and is text based. Comings from Lisp I am familiar with an integrated macro expander which is part of the language and understands the language, hence it can solve all of the problems, associated with macros. And why would you want this... For speed optimization, and writing programs that write programs, if you can predict a head of time that a loop will execute exactly 20 times then why not unwrap it ... Because writhing the same
lines with minor variations is annoying and error prone (even with copy and past), so let the macro expander do it.
The first problem however is one of syntax? In Lisp macros fit, they look don't require any major contortions to express. I'm not the only one who has raised the idea of adding Lisp like macros to Python but so far no-one is come up with a model of what said macros should actually look like.
OK That will do for this post.
No comments:
Post a Comment