
Brian Braatz wrote:
What is cool is THIS PAGE:
What stood out about it was THIS ONE PAGE would have saved me many many hours had it been in the original Lambda docs. Because it describes for me, how to "think" about the currying.
Unfortunately this page confuses currying with partial function application as I explain here: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52549 and also in this thread: http://tinyurl.com/4tgez
My advice to you is to find a way, in your presentation of the boost internals, to make sure that you thread it such that the people watching "can think about it".
I always try.
If you establish this early on, you will have an excited audience and you will (hopefully) get more people to use boost.
Detailed Suggestions: * the pics in the above link are conceptually excellent for describing how to think about currying.
Err, partial application.
If you can accomplish something along the same lines with the techniques you are going to show, then you will really knock em dead.
* Boost internals is an excellent subject matter, I think if you first hit common concepts- and THEN delve into those concepts and how the internals of the library(ies) use that concept you will give people something they can use.
I've noticed that many of the bigger-named speakers seem to dwell on the weird corners of C++ rather than making it understandable. People are left thinking "C++ is weird" rather than understanding its logic and feeling powerful using it. Audiences seem to eat it up, though. Or at least they keep going back for more punishment ;-). Most of my talks try to eschew curiosities and details and instead concentrate on the conceptual and fundamental. This one, however, is explicitly intended to look at details. That said, I will of course be putting things in context. I just feel compelled that way ;-)
* in a previous mail I made the suggestion, which I will make again. Try to think of the most important techniques the boost libraries depend on, get them in peoples heads, and then delve into the internals.
??? Hm. Those techniques _are_ the internals.
* a technique I have seen used in the mags, is to decompose the templates, I.e. show what the code looks like after the compiler has gone through the generation steps.
* hopefully my suggestions, though not exactly what you asked for, will be of some use to you.
I'll keep that in mind. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com