Tuesday, April 26, 2005
Friday, April 15, 2005
MVC: Cargo Cult
"a lot of the related literature seems to use MVC as the canonicalAgree with it or not, it's interesting reading.
example of a design pattern"
MVC is the canonical example of the "Cargo Cult" design pattern of
blindly aping Smalltalk without understanding it or considering if there
are any more appropriate design patterns.
http://en.wikipedia.org/wiki/Cargo_cult
I've never heard a good explanation of what a "controller" is really
supposed to do (other than entangle brittle dependencies between the
view and the model, and allow programmers to bill for more hours
maintaining the code). But people always throw in that extra
"controller" class and its requisite complexity, just because Smalltalk
uses them, and it doesn't feel right imitating Smalltalk without the
whole MVC trifecta.
Just because MVC is a commonly used and cited "pattern" doesn't mean
it's the best one to use in all cases. It's better to have a "purpose"
than a "pattern".
http://osteele.com/archives/2003/08/rethinking-mvc
Sunday, April 10, 2005
Open Source: Humor
Saturday, April 09, 2005
Open Source: Apple
Friday, April 08, 2005
Hyperthreaded Micro Threads for Aspect Oriented Programming
I recently discovered a series of articles written by Jon "Hannibal" Stokes on arstechnica.com. Usually, I stick to learning weird, exotic languages, but I'm really fascinated by his descriptions of modern processors. I'm especially fascinated by the idea of tuning modern day processors and programming techniques so that they take advantage of one another. For instance, C++'s use of automatic variables results in so many function calls, that if these function calls are not inlined, they can play hell on the pipeline, unless branch prediction works well.
Having read Hannibal's articles on hyperthreading, SMT, and the Itanium-64, IA-64, I became intriqued by the performance aspects of SMT on aspect oriented programming, AOP. AOP is currently confined mostly to the Java world, so it doesn't have a direct effect on the processor, per se, but I wondered if a natively compiled AOP compiler could better take advantage of an IA-64 processor. It would do this via explicitly parallel instruction computing, EPIC, and what I call micro threading.Specifically, AOP permits a separation of concerns. Hence, a function that looks like this:
void do_f() {
log();
authenticate();
do_stuff();
log();
}can be torn apart into something like:
void do_f() {
do_stuff();
}
// Blatant pseudo code.
match function do_* {
before { log(); authenticate(); }
after { log(); }
}I propose that the above AOP could possibly be extended to:
match function do_* {
before { thread_fork log(); inline authenticate(); }
after { thread_fork log(); }
}
Hence, in the above example, for every function do_*, there would be a "micro" thread to take are of logging at the start of the function and another micro thread to take care of logging at the end of the function, but the authentication would be inlined. Thanks to EPIC, the compiler could give a hint to the processor and the OS that it would be best to run these micro threads at the same time as the main function. Paraphrasing the words of Intel, I'm creating code-level parallelism in places where there was none before. AOP was designed to make the programmer's life easier, but with the addition of hyperthreaded micro threads, it can possibly result in substantial performance increases as well.
Well, I hope the above made some sense. I most definitely welcome your comments. Hopefully, someone more intelligent than me can make it happen ;)

