> But after trying aspects and coping with their complexity, I am not > so sure they are a good idea in Python, for the language is very > flexible and dynamic already.
That's my intuition as well. It's interesting that aspects uses the same terminology (weave and tangle) as Knuth's so-called literate programming (LP) system. I doubt that this is a coincidence. As you may know, Leo got its start as an LP tool, but the more I use Python, the less I use LP. My first impression is that aspect oriented programming (AOP) is pretty 'heroic'. It's ambitious, but not necessarily in a good way. But this is only my first impression. In any event, we can hardly require that every tool that we want to use uses AOP. That's why I am interested in wrapping already existing products like Emacs or Texmacs or IPython. BTW, the IPython folk are doing in a refactoring/repackaging of IPython called IPython1, so the notion of creating a python wrapper for a python program isn't an oxymoron. Let me throw out another idea here. The reverse of an 'heroic' solution would be a 'simplistic' approach. Sometimes simple guidelines can be surprisingly useful. I am thinking in particular of the best programming advice ever given to me: namely to make class methods or functions be as small as possible. At first, this sounds like simplistic (simple minded) advice, but my experience is that it is not. Following this advice has produced all kinds of unexpected and far-reaching happy consequences. For example, small functions are easy to write unit tests for, they are easy to combine in novel ways, and they are easy to understand and document. BTW, this advice came to me from Bernhard Mulder, one of Leo's most influential developers and users. The goal of all simplification programs is to arrive eventually at what I call a 'big collapse' of complexity. This has happened many times in Leo's development, and my intuition is that it could happen here. So I continue to wonder whether relatively simple principles, cleverly applied, might have significant consequences. As far as overall design goes, I have yet to encounter a better overall framework for design than the model-view-controller design pattern. It cuts across the questions of gui-first or whatever. All three kinds of classes are important in their own ways. In short, I think code reuse is possible, but it will take innovative thinking applied to the simplest possible building blocks. Edward P.S. I have been vague on purpose in this discussion because nothing is (or should be) clear in the early parts of creative exploration. Imo, the essential quality needed for creative thinking is the ability to tolerate ambiguity, confusion and uncertainly for extended periods of time. The confusion is itself a reliable indicator that good things are happening. The last thing I want to do at times like this is to remove the confusion too soon. The subconscious thrives on ambiguity. Let's enjoy it. EKR
