4 ms·

As a committedly multilingual prgrammer, I'm not sure what you mean by saying I think in Blub (and yes, I'm familiar with that article). Is it because I failed

by avdi 19y ago

As a committedly multilingual prgrammer, I'm not sure what you mean by saying I think in Blub (and yes, I'm familiar with that article). Is it because I failed to note that Lisp is in many ways far more powerful than Ruby? I don't think it makes a particularly good case for AOP myself. AOP is just another, slightly more structured, form of the same thing - a structured COME FROM (see INTERCAL), if you will. The ability to globally append to or modify arbitrary functions in existing code is no substitute for a) limited extension within the scope where the extension is actually used and b) actually coding classes with well-documented extension points, whether Emacs-style "hooks" or some other mechanism.

xirium 19y ago
I was joking about Blub. In the context, it would have been extremely unreasonable to describe the merits of Ruby and Lisp in more detail. Regarding AOP, when I saw the video, I thought "OMG! Someone invented OO COME FROM by matching stackframes!". Indeed, a question in the video subsequently alluded to a stack implementation. Anyhow, although it is possible to write an entire application in aspects, it is likely that the worthwhile threshold for doing anything in AOP is larger than the threshold for doing anything in OO. In trivial cases of OO and AOP the execution overhead is minimal. Furthermore, there's opportunity to reduce overhead when you've got a bytecode implementation. I'll give an example using testing and asserts. If we had a bytecode implementation which supported aspects and we loaded a test harness, the test harness aspects could effectively add asserts throughtout the code. If you don't load the test harness then the asserts aren't formed. Languages like Ruby are ideal in this situation because the bytecode can be devised such that trivial and non-trivial cases can be easily added into already compiled bytecode. This means that you've got hooks everywhere without forethought and with minimal overhead. Planning ahead remains a better option but its nice to have a fall-through case which scales.
- xirium 19y ago
  I've read a lot of ELisp code, and I have very rarely seen the equivalent of Ruby-style monkey patching. Even the advice mechanism, an AOP-like feature which enables functions to be dynamically wrapped and chained, somewhat like Rails' alias_method_chain, is used sparingly. Instead, every mature Emacs extension exposes a plethora of "hooks", extension points that other packages can attach their own handlers to. Other packages add their handlers to these hooks, and to hooks that the core Emacs code provides, and thus they cooperate largely without collisions. -- http://gilesbowkett.blogspot.com/2008/02/never-complain-only-ever-code.html http://gilesbowkett.blogspot.com/2008/02/never-complain-only...

by avdi 19y ago

xirium 19y ago

I was joking about Blub. In the context, it would have been extremely unreasonable to describe the merits of Ruby and Lisp in more detail. Regarding AOP, when I saw the video, I thought "OMG! Someone invented OO COME FROM by matching stackframes!". Indeed, a question in the video subsequently alluded to a stack implementation. Anyhow, although it is possible to write an entire application in aspects, it is likely that the worthwhile threshold for doing anything in AOP is larger than the threshold for doing anything in OO. In trivial cases of OO and AOP the execution overhead is minimal. Furthermore, there's opportunity to reduce overhead when you've got a bytecode implementation. I'll give an example using testing and asserts. If we had a bytecode implementation which supported aspects and we loaded a test harness, the test harness aspects could effectively add asserts throughtout the code. If you don't load the test harness then the asserts aren't formed. Languages like Ruby are ideal in this situation because the bytecode can be devised such that trivial and non-trivial cases can be easily added into already compiled bytecode. This means that you've got hooks everywhere without forethought and with minimal overhead. Planning ahead remains a better option but its nice to have a fall-through case which scales.

xirium 19y ago
I've read a lot of ELisp code, and I have very rarely seen the equivalent of Ruby-style monkey patching. Even the advice mechanism, an AOP-like feature which enables functions to be dynamically wrapped and chained, somewhat like Rails' alias_method_chain, is used sparingly. Instead, every mature Emacs extension exposes a plethora of "hooks", extension points that other packages can attach their own handlers to. Other packages add their handlers to these hooks, and to hooks that the core Emacs code provides, and thus they cooperate largely without collisions. -- http://gilesbowkett.blogspot.com/2008/02/never-complain-only-ever-code.html http://gilesbowkett.blogspot.com/2008/02/never-complain-only...