I love this coding style, but I think you have a valid point. Python decorators are a nice compromise in that they allow you to have cleanly factored 'around' advice (which is strictly more powerful then 'before' and 'after') with the implementation defined elsewhere, but still requiring a visible marker at the location the advice is used.
What would be ideal is a system that allowed you to define advice by monkey-patching but indicated what advice was applied to a method at the site of it's definition. As mentioned in this comment http://news.ycombinator.com/item?id=3246215, I think we are bumping into a limitation of what can be easily managed in "unstructured" (I would say "dead") text files.
I think we are bumping into a limitation of what can be easily managed in "unstructured" (I would say "dead") text files
Yes, I think so too. There are many kinds of relations between entities that we cannot specify just because "dead" text files make them hard to express. Also, it makes that language "wars" focus on shallow concerns such as syntax, instead of semantics.
It would be great to be able to put constraints and relations at the abstract syntax tree level, or abstract semantic graph level (cross references and such that are automatically updated if entities are moved/renamed).
IDEs sort-of work around this by parsing the code and trying to bolt on features, by handing the "dead" text files intelligently. But all this work is lost as soon as you close the editor, so it does not allow the programmer to retain changes at this level.
But I'd love to work on a project that examines different, new ways to represent source code. Which could aid static/dynamic code validation, documentation, code comprehension, refactoring, cross-cutting concerns, and would allow for rendering the source code in any style and syntax that the developer wants.
Of course, this also would present challenges in the area of scm systems, because those are really focused on 'dead' text files. One idea I've had is to represent code as a graph, for example, in a graph database.
I've been playing prototyping a completely unrelated project using graph databases, but that really gets me thinking... drop me an e-mail if you'd be interested on collaborating on something like this.
I think more having the modified AST feed back into the source code, or more accurately, the human-readable view of the actual source code. Like the comment example - imagine having the monkeypatch still in the comments module, but when you open the WallPost class, you can see the "has_many :comments" and a tag that takes you to the comments functionality.
Alternately, you can do the the reverse - someone writes the change in the more traditional manner, but you can view - and edit - the change-set as if it were a module of monkey-patches isolating the relevant concerns. Or any particular view of the program someone can think of that's useful.
I'd like to program like that.
ETA - Sorry for the accidental downvote; found a couple of your other comments to upvote.
Yes, like any modern high-level language it would use some concepts "borrowed" from LISP. Credit where credit due...
On the other hand I don't want to go completely bananas with the 'structureless' LISP. In my opinion at least it would aid comprehension to be mirror modern high-level languages. But you'll be able to choose Ruby or Python syntax-mode at will (or maybe even LISP-mode :-).
What would be ideal is a system that allowed you to define advice by monkey-patching but indicated what advice was applied to a method at the site of it's definition. As mentioned in this comment http://news.ycombinator.com/item?id=3246215, I think we are bumping into a limitation of what can be easily managed in "unstructured" (I would say "dead") text files.