I’ve had a string of thoughts that require deeper consideration. The thoughts start with:

There is a god, her name is Hope.

And eventually reach:

If computer intelligence doesn’t get religion then the Singularity cannot occur.

There’s a heck of a lot between those two points, I’m not sure I’ll ever be able to translate it from strings of thoughts to strings of words.

Answer: an epiphytic marketing industry.

More specifically: a plethora of meaningless awards and certifications and the companies and organisations responsible for them.

Go to the wine section in your supermarket and you’ll see dozens of bottles with little silver, gold, or bronze “medals.” Read the labels and find out what awards they’ve won. Often it’ll be “best” of some ridiculous niche category like “best merolt-shiraz blend from the west side of Dead Man’s Hill.” Seriously, many of them are about that precise, covering all of 3 or 4 wines. That’s if they explain anything about the award at all, in other cases it may just have a year and the name of some unheard-of wine show, or grand-sounding “challenge.”

In my years of drinking wine I’ve come to the conclusion that there is very little relationship between awards and my enjoyment of the wine. However there is some relationship between the awards and the price of the wine. As far as I see it you’re better off going for cheaper wines with no awards. It’s hard to remember this sometimes, we grow up instilled with such a strong sense that everything must be ranked that this “medal” technique hammers right into our subconscious bypassing rational thought.

The technology sphere has a similar system, whereby a plethora of publications, organisations, and dodgy websites give out awards like they’re going out of fashion (I wish.) Many of the awards will have dozens of categories that really only contain 3 or 4 competing products. Sometimes even less since some of these schemes require you to pay up to be considered (and I expect many wine awards are the same.) These rankings are usually of little technical merit, even often judged by non-experts based on marketing material rather than any practical results. Techies may dismiss them yet, disturbingly, they can be an important part of selling a product. The inexpert are easily swayed by these seeming ticks-of-approval, as with wine it can be exactly this sort of meaningless ranking that gets you short-listed in the mind of your customers (most products are not sold to experts.)

Certifications are similar. Take IGT/DOC/DOCG in Italian wine for example, a set of rules that define how you must make your wine if you want to market it in certain ways. It seems as if you’re claiming some guarantee that your wine attains a minimum standard of quality. In reality the only real meaning is that the wine complies by a set of rules that grant it the acronym and, like the awards, enjoyability bears little relationship to the certification. The fact is that mere Vino Da Tavola wines (“table wine,” the term for uncertified wine) seem to be as good a bet if you just want to enjoy a glass. Further, most people don’t know what all the classifications mean anyway! Quality is rarely certified, typically the most you can read into it is location, grape blend, and process – in the hope that prescribed bounds increases the chances you’ll enjoy your wine.

In technology systems exist that are much the same. (Also for people, but that’s another issue.) Some are tick-box standards or rule systems, like the currently hyped SOx and PCI. The problem with these is that compliance really only means that you’ve “gone through the motions,” there’s no guarantee that you actually care or are pro-active about the problems the systems supposedly address. Another form of certification is “product X achieved Y with system Z” – any tech person I know looks at these things and shrugs, sometimes muttering an expletive. It’s a funny old situation where successful companies are created around products that give certifications that the entire base of technical experts in the relevant field dismiss as not being a whole lot of use! But the fact is that, while they’re rarely a useful assessment of the practical effectiveness of a product, they’re often an important cog in the marketing machine. People want benchmarks, people want ratings – how else can they judge the quality. The underlying problem is that there are few experts but many buyers.

Where the whole thing goes most horribly wrong, in the tech industry at least, is when this system starts feeding back into itself. Regulations are created that spawn whole technologies, such as SOx and PCI. We get technology specified by the regulations rather than focused on solving the problems the regulations were invented to address. Defacto-standard rankings are created that measure a quantity that isn’t actually a useful part of a technology’s function. We expend vast engineering effort tuning technologies to do well in the rankings rather than addressing real problems. Successful companies are born from the precise specification and measurement of the wrong things!

It is a little reassuring that no number of unreliable or misleading guarantees makes a crap product a good one and that’ll be the stumbling block for many solutions riding a wave of medals. Alas, it is much harder for the inexpert to know the technology they’ve bought is crap than it is for the inexpert to know the wine they’re drinking tastes like copper coins. (This doesn’t matter so much for wine, there are many buyers and you can get by just fine if you never sell a second bottle to the same person. You typically have much more restricted markets with technology and rely on people coming back for more.)

I started typing this up with the intention of jotting down just a couple of paragraphs comparing wine medals to technology awards. Now it’s >1000 words later and I’ve left many loose ends flapping around in my mind. Someone who knew enough about the industry, marketing, and human psychology could probably write a decent paper (or book) on this. “Technology Defined by Marketing” or, more scathingly, “Selling Widgets to Idiots.” I expect it’d probably be boring and wouldn’t change anything anyway.

Since my earlier post (content here should mostly make sense independent of the post) I’ve taken some time to explore the C++ lambda proposal further, specifically document N2550 [pdf] that fully defines the proposal.

The first note is that the “In a nutshell” example used to illustrate the use of the method is not reassuring. First they introduce the functor:

class between {
  double low, high;
  public:
    between(double l, double u) : low(l), high(u) { }
    bool operator()(const employee& e) {
      return e.salary() >= low && e.salary() < high;
    }
}
....
double min salary;
....
std::find if(employees.begin(), employees.end(),
                between(min salary, 1.1 * min_salary));

Then they provide the lambda equivalent:

double min salary = ....
double u limit = 1.1 * min_salary;
std::find if(employees.begin(), employees.end(),
                [&](const employee& e) { return e.salary() >= min salary && e.salary() < u limit; });

This seems to be the same example that the Beautiful Code blog picked up on.

I have to admit however, this is growing on me just a little. Maybe like mould growing on damp bread.

To dissect:

The [&] introduces the lambda expression, in this case the inclusion of a lone & indicates that the closure created will have reference access to all names in the creating (calling) scope. This is why the code can use min_salary, if the lambda was introduced with only [] the code would be erroneous. You can, and possibly should in most cases, specify exactly what the closure can access and in this case that would be done using [&min_closure]. The normal meaning of & is retained here, the variables the closure accesses are references to those in the enclosing scope — for better safety in this case it is maybe better to use [min_closure], this will ensure the closure will not modify the original value (consider is passed to the closure by value.)

I see a pitfall here, the non-& capture means the closure can access values by the enclosing name and modify them but the modifications will not propagate to the enclosure. It wouldn’t surprise me if, for clarity and readability, the & form (pass by reference) becomes standard and the default form (pass by value) becomes “not done.” I feel it may be preferable for the “pass by value” to actually be “pass by const reference.”

The (const employee& e) gives the “parameter declaration” of the lambda. Essentially we’re declaring a function, or functor, that takes a single const reference to an employee as an argument. Note that this mirrors the operator() of the between functor. There’s more to the declaration than is given here, it can also sport an optional exception-specification (um?) and a return type. Let’s skip the exception specification since I don’t feel up to the task of trying to explain that one. (I suspect it is because the result of a lambda is under the hood a functor and it isn’t insensible to export this part of the definition to the user rather than enforcing no specification.) The return parameter is likely to be more regularly interesting, in this case it is not given but is actually -> bool – why? Because of paragraph 6 of 5.1.1, which essentially says that the return type is defined by the type of the argument to the return statement in the lambda.

The lambda expression itself, or code of the closure if you prefer, is between the { and }. That part is clear enough I expect.

The return type is defined by the top-level expression of the return statement in the expression. This is &&, clearly enough the return type is a bool.

Read the document [pdf], it’s worth the time – it’s a short document.

So?

Um, still not sure, but seeing all that is specified by the document does open up the possibilities much further. I said earlier that I think this lambda syntax has the potential to make code clearer where the function-object (or binder) code replaced achieves a simply expressed end. On further consideration I think this is especially the case where the expression is not easily described with a reasonable functor name (i.e. the functor approach for “greater_than” is fine and possibly better than the lambda equivalent.) The question, for maintainability, becomes: is:

    between(min salary, 1.1 * min_salary))

better than:

    [&](const employee& e) { return e.salary() >= min salary && e.salary() < u limit; });

Personally I still don’t see enough of a win to the latter syntax to justify the extension. Saving the code that defines the functor doesn’t look like a big win and the latter code, while more explicit at place-of-use, doesn’t seem so stupendously more clear to justify the extension either.

What if…

What if the extension allowed for creation of closures more in keeping with their much-hyped use in other languages? Would I, monkey boy, be convinced then? Quite possibly. Scroll down to Chapter 20 in the document and peruse “Class template reference_closure“.

Looking interesting. As I see it the reference_closure definition will permit the creation of instances-of-lambdas (closures.) These can be returned from a class as “closures” giving very specific restricted write access to the internals of a class. Vague shadows of how this could make the design of code I’ve worked on in the past more straightforward are beginning to form. That’s far from an indication of usefulness however, the shadows aren’t any better than “deformed rabbit” right now. I’m still a bit confused as to the lifetime of variables local to the scope of the enclosing function, as opposed to member variables, in relation to an exported “closure.” Especially since the closure template defined seems to restricted to reference-only closures.

I don’t have time to explore deeper at the moment, but it’s certainly food for thought and brings this C++ lambda/closure extension more in line with the hype around it in other languages. (Kat’s work has recently jumped on the closure bandwagon (best thing since Agile?) and it seems that their picture of closures in Perl very much mirrors what would be achieved by this reference_closure. At the same time… it is also achievable with everyday functors, but maybe the new specification makes it all easier and more accessible? Perhaps that is the question.)

The point of all this text is: RTFM [pdf]. Herb Sutter’s post is a quick-n-dirty illustration of simple things that can be achieved using the specification — he refers to the specification itself for your further investigation. I’m envious that he had an implementation that will compile his lambda examples, presumably VC++.

[[I use “closure” and “lambda” almost interchangeably here, however I’m far from confident in my use of this language. Reading up on this online does not help much as there’s a gap between the CS definitions of the terms and many commonly blogged use-cases. In practise it seems a lambda is an in-place definition of function code, what we often refer to as an “anonymous (unnamed) function”, that can be passed down to called functions (and is most often seen defined in the place of a parameter interchangeable with a function reference.) Practice again seems to define a closure as inline function code that can access and modify values in the scope where it was defined but can be returned to and invoked by calling code, this matches fairly well with the wikipedia definition of the term. YMMV.]]

I just read Herb Sutter’s C++0x lambda/closure teaser post. It’s intriguing, although I cringe at the new syntax. I’ll be mulling over this somewhat and waiting to see what else is said about it by the Internet’s hoard of people more qualified than I… though, of course, Herb Sutter may be the most qualified out there! No doubt I’ll eventually be convinced the new features are wonderful. For now I’m going to hope the technical brilliance of the ISO C++ committee has given birth to something beautiful – and in this instance Herb Sutter hasn’t done a good job of marketing it to numpties like me. (Then again, exception specifications got into the standard as well and it seems that even the people responsible for them would like to disown them now.)

In the “Write collection to console” example I have trouble seeing how the lambda version is obviously better. I look at the three examples and think to myself “huh, what’s the point?” The fact is that the for loop is clear, the for_each lambda version just makes it a little more terse. How about:

    #include <boost/foreach.hpp>
    ...
    BOOST_FOREACH(const Widget & widget, w) {
        cout << widget << " ";
    }

More readable than all Herb’s examples? Possibly. Herb Sutter makes a note that the final lambda-using example is the only one he typed up correctly before doing a complier-run. Maybe this could be related to the fact he’s probably been steeped in the specification of the lambda features lately?

The “Find element with Weight() > 100” example is a better one, aside from the grotesqueness of the lambda syntax. This []( has a face that only a mother could love:

    find_if( w.begin(), w.end(),
        []( const Widget& w ) -> bool { w.Weight() > 100; } ); 

Herb dares us to have a go with binders, here’s what I knock up for boost::bind:

    std::find_if(w.begin(), w.end(), boost::bind(std::greater(), boost::bind(&Widget::Weight, _1), 100));

This is a typical “bind class member return value to function (functor) argument” usage, I see (and use) it a lot. Though for the “>” case there’s an even more terse solution:

    std::find_if(w.begin(), w.end(), boost::bind(&Widget::Weight, _1) > 100);

I don’t particularly think one syntax is more readable or obvious than the other, but I’m used to reading uses of bind. Truth be told however, Herb’s functor example is easily the clearest at point-of-use. Is the clarity not worth the small clutter of having the GreaterThan functor implementation lying around somewhere (and entirely re-usable.) Herb has perhaps not chosen the best example here. Something just a little more complex could make the lambda version seem a lot better than the bind version, though such complexity would just make the overhead of writing the functor less of a concern (and the non-reusable lambda code seem more of a bad idea.)

[[Note: Since I wrote the above, on Saturday, a lively discussion has popped up in the comments on Herb Sutter’s post. In there he explains two strong disadvantages of the binder approach: 1) recognisable function syntax is lost with binders, 2) errors in binders generate some of the most horrible C++ template-spew error messages you can get out of compliers. That latter part is certainly a pain, it takes a few weeks of working with, and making mistakes with, binders before you can weed useful information out of those errors. Though they’re usually down to just a couple of syntax mistakes and you can check for them first and correct without needing to decipher the errors in 80%, or more, of cases. The other common problem I find with boost::bind is passing object arguments and forgetting boost::ref, an error you’d be much less likely to make with the function-declaration style of the lambda syntax.]]

The final “Most algorithms are loops” example is more compelling. But again, the example used doesn’t seem a great win over boost::bind. And both lambdas and binders seem a less maintainable route than functors. [[Note: See previous note for positive points of the lambda syntax over binders that also apply here.]]

It seems to me that the lambda syntax may offer a more robust and maintainable replacement for binders and, in extension, be a better way to “turn things into functors.” That is certainly a worthy achievement in itself. For simple cases the lambda syntax can provide an “it’s all in front of you” clarity to improve the readability of algorithms. For more complex cases I see it being used in lazy ways and giving the world some knotty code maintenance nightmares in the name of the quick hack. Stick to functors is my leaning at the moment, or use functions combined with the lambda syntax as a replacement for binders, if you must. It’s early days yet though, these are some first simple examples and the standard is still in progress. [[Note: insights from the “Beautiful Code” blog. Note that the non-standard solution to his .begin()/.end() pattern dislike is BOOST_FOREACH, it’d be nice to see something like that go into the standard.]

It’s great to see non-trivial new features going into C++, I look forward to reading what the experts have to say about it all! It’s worth noting that the items mentioned by Herb are just the most buzz-word friendly ones, an act of marketing no doubt. I suggest exploring the “Other approved features” that he links to, there’s some interesting ones in there. I’m most immediately intrigued by N2555, N2559, N2540, and N2535 – unfortunately I don’t have time to consider them in detail.

After a recent trip I seem to have left the charger for my mobile behind. I Googled for charger specifications but had no luck, so for the record: You can charge the Motofone F3 with 4.5v DC pin-positive. I have no idea if this is the actual output of the official charger, all I know is that it works. It’s easy to do if you have a multi-voltage power supply and a good collection of plugs for it! The supply I used was 500mA, which should be way above requirements in any case.

I was meaning to give a review of this phone model some time, but I doubt I’ll ever do it. In short: argh! That shouldn’t be surprising though, this is an ultra-simple phone. The only interesting feature is the E-Ink display, which is excellent – you can honestly read the display outdoors at night without turning on the backlight! That’s the only positive though, I though a dead-simple phone would be liberating but it really is just a pain in the backside. Keep in mind that I went from a fully-kitted out PDA phone (Motorola A1000) to the F3, about as huge a leap as you could make. (As far as I can see there are few PDA phones available even now that are compellingly better than the A1000, a phone from 2003 IIRC, in any feature other than battery life, and I’ve looked into this a fair bit as I’ve been trying to find an A1000 replacement – I await the release of Android handsets! I was almost tempted to get a Neo 1973 but no-3G was no-go for me.)

The main draw-back of the F3, aside from the lack of web and all those other modern features, is that it uses the SIM card for all data storage. This means the number of SMS messages it can store and the number of address records is tiny. The address records are also really simple, the usual for SIM storage. And, of course, there’s no computer interface (no USB, no blue-tooth, there’s a contact-pad that may be promising but that isn’t “out of the box.”)

The big plus of the F3 is that it is only 15 quid– I spend more than that a week on coffee. It’s the ideal travelling phone, robust and cheap. On the robustness front, I dropped a 30kg dumbbell on it (from only about 4 inches high, and by mistake!) and all it suffered was a minor dent near the screen.

I think that the potential of future models in this line is huge… but I’ll be going back to a feature-bloat model soon, I hope.