Caffeine Talk

I am writing this post during the lunch break for the 22nd CREST Open Workshop. We had a few talks in the morning already. What particularly struck me during Eric Fraga’s great introduction into the uses of optimisation in chemical engineering is how miles ahead it was compared to what we, who are advocating for the Search Based Software Engineering, are doing. Whatever “advanced” applications of optimisation algorithms we as a community discussed within the last few years - interactive optimisation, gaining insights, visual workspace - were already in full swing in Eric’s talk, which discussed designs of chemical plants and heat dissipation modelling of energy efficient houses. Impressive.

Of course, there is the “underlying framework” issue: software systems are highly specified, arbitrary nets of logic that does not have any continuous algebraic laws that act as a kind of a safety net. Faults are one mere step taken outside of specified behaviours, and it is very hard to get a mathematical model that can be precisely optimised.

I’m still hopeful and there were indeed things I’ve learned from half a day of this workshop. Well, being aware of the problem is the first step to the solution.

All the whining about Siri and the recent “mapocalypse” aside, I wonder whether certain services can only exist in beta forms, because there is no way one can implement them and get done with it with a big period. Apple’s “it just works” mantra made sense when a manufacturer/developer could implement something and put the stamp of approval before shipping it out. Neither Siri nor maps seem to belong to such a category of services.

Google, the perpetual beta machine, only functions because it is continuously self updating by being used. That is, by learning from the users and their usages. Call it beta-testing if you want, but this may be the only way of maintaining such services to a certain level of quality. Recognising speech from a random person or providing up-to-date geo-information (remember A to Z maps? Were they always correct?) can probably be done only by learning as you go. Well, that or you spend an infinite amount of money.

Will the necessity of self-adaptivity spread to other areas of computation? We are so accustomed to using “the” version of software at any given time that it may be a bit hard to imagine, but why not? Other tools adapt to your use - even if the “adaptation” is simply a tool’s handle wearing out to your particular grip. Why not software indeed?

After years of using laptop HDD (including the ones in iMacs) and SSDs, I now have a proper (probably overkill) desktop machine with a real(?) hard drive. And it is astonishingly loud! How did we ever live with this before? It will take some time to get used to this.

The Google neural net which learned to recognise cats received a lot of media attention recently. Most articles focus on how the AI learned to see cats even though it was not told what to look for. This is somewhat misleading.

“Not told what to look for” is, of course, shorthand(?) for unsupervised learning: humans do not train the neural net by telling, after each training set datapoint, whether it is indeed  a cat or not. However, it does not mean that the neural net decided to learn what cats look like on its own. The training set was a mixture of cats and other distractors, compiled by human. So, in an indirect way, the neural net was still told what to look for.

The related technical paper about this NN implementation can be found here. 

Jeff Atwood posted Please don’t learn to code today.

After some deliberation, I concluded that I disagree. Should one only learn what can help one’s day job? And who says learning to code will NOT help any day job? Surely we do not expect any politician to improve his political proficiency by automating some of his daily job using perl scripts. What we can reasonably expect is, perhaps, for the politician to get a (slightly) better understanding of how things work around him.

I recently got involved with a Korean online science webzine, to write a column about software engineering/computer science. Existing columns covered a wide range of disciplines including evolutionary biology, cognitive science, and socio-physics: I think the science journalist, who acts as the desk, did a fine job of balancing technicality and accessibility for the general public. However, as soon as I experienced the gate-keeping first hand, I realised it is very difficult to explain what I do in laymen’s terms. I do admit that it is partly my own fault of doing a poor job as a public science writer, but it led me thinking how littler people understand about software/program compared to other basic science disciplines such as biology or classical physics. I mean, people do not think about kitchen appliances in terms of currents and voltages, but we still learn about them in school. Can’t we - shouldn’t we - do the same about software, considering how much we rely on them?

About the argument on “essential life skills like reading, writing, and math”: I do not intend to have the final word on this pedagogical debate, and maybe I am biased by the far east Asian philosophy about education (which in general says you should be as much all-rounded as possible), but education - even when we confine our discussion to the compulsory part of it - is more than what is essential for everyday life… no?