Saturday, 31 March 2012


Digging through my photograph collection I came across these that I took last year in a science exhibition - I guess primarily aimed at children. Crap (I wanted to use a stronger word) like this has no place in either a science exhibition nor, for that matter, in any place being aimed at anything remotely human.

The photos are of a computer screen which was part of a quiz for children on food. They're in Finnish but I'll provide the translation. Here's the question:

Knowledge Quiz:

Compared to "normal food", "natural food" ...

  1. Contains less fat and sweeteners
  2. Contains no chemicals and genetic manipulations
  3. Is produced in the countryside
And the answer is....

Natural food chemicals.

The next question should be then what is it made of?  Pure energy? Some exotic matter? Maybe that's where all the dark matter in the Universe is....natural food.

The UK's Royal Society of Chemistry is offering a £1000000 (UK pounds) prize for anyone who creates a "chemical free" material. I guess no-one at that particular science museum has claimed the prize, which basically means they're either lying or stupid.

Here's a quote from the RSC:

Dr Neville Reed, a director of the RSC, said today: "I'd be happy to give a million pounds to the first member of the public who could place in my hands any material I consider 100% chemical free. 
"Should anyone do this, we will see thousands of years' worth of knowledge evaporate before our eyes. We would have to tear up the textbooks, burn the degree certificates and retrain the teachers."

One of the major constituents of any food-stuff is know that chemical H2O, sometimes known as dihydrogen monoxide...not to mention those other nasty chemicals such as sodium chloride, or L-ascorbic acid, or any of the myriad of carbon based chemicals...

Some might say that this only applies to "man-made" or "bad chemicals" what constitutes a "bad chemical" or even a "natural chemical"...well, plenty of interesting poisons exist in nature including cyanides and many, many radioactive materials too, so that can't be the definition.

Dihydrogen monoxide incidentally was the subject of many hoaxes based on a complete misunderstanding of what chemistry, chemicals and a basic knowledge of science.

I remember an advert on TV for some cosmetic product which contained only natural chemicals which must be "good"...natural chemicals such as I've already stated...such as cyanides naturally found in almonds and apple seeds.

So, anyone who states that something is "chemical free" is stupid, deranged and plain wrong. In fact, anyone who states such a thing in a science context should be...I'll let you decide on a suitable punishment...maybe something nasty such as not allowing them access to that most evil of bad chemicals: dihydrogen monoxide. This kind of crap has no place in a science exhibit, in childrens' education or in society in general  - only bad things will come of this if this kind of nonsense is let to continue.

ps: I did ask a member of staff at the science museum about this - she had no answer other than it must be true otherwise they wouldn't have had such an exhibit...oh dear...

Friday, 30 March 2012

More ballet and software engineering

Sometimes a quick search using some popular search engines reveals people with similar ideas, in this case about ballet and software engineering: on the IBM Developer Works site is an article dated from 2005 by someone called "gbooch"*:

Software architecture, software engineering, and Renaissance Jazz

which mentions the link between software architecture and dance:
"It seems to me that there's a curious relationship between dance and software architecture: in both disciplines, there are only a limited number of patterns available, each genre assembles those patterns in specific ways that define a particular genre, and furthermore, most knowledge is passed on through tribal memory, from one dancer or architect to another. In dance, by the way, some attempts have been made to define a graphical notation for describing dance movements, just as we have the UML for visualizing, specifying, constructing, and documenting software-intensive systems."


*I guess if the mysterious "gbooch" thinks this then I'm in good company.

Then there's another post on Techtalk: If Software Were Like Ballet which lists a number of points, the first of which is:
  • Little kids are encouraged to get used to the equipment and basic practices.  Even if they don't actually do these things they are told about build and release cycles, software qa, and algorithms.
Now I don't agree with some things said in that posting, but certainly the above at least in terms of encouraged to use the correct equipment, techniques and basic practices is apt.

Sunday, 18 March 2012

The Ballet-Software Engineering "Isomorphism"

A grand title for some thoughts. After watching a dance show involving various styles of dance etc a thought struck me on some interesting parallels I see between dance and the practice of software engineering. I guess this comes from reading things such as Baez and Stay's "Physics, Topology, Logic and Computation: A Rosetta Stone" - a paper describing the links between various scientific disciplines, ostensibly through category theory.

As I and many others have stated before the key to good software engineering (and thus great software) is an understanding and use of the core, formal theories of computer science - I consider software engineering to be a sub-discipline of computer science (and in turn mathematics). Why should this be so? Simply because of understanding how each of the parts of a piece of software interact and an appreciation of the complexity and need for elegance and simplicity in this.

So what has this got to do with ballet? Comparing modern dance with ballet and the dancers performing their routines I noticed the approach to the task was in most cases different - there is an interesting exception which I'll get to later. The difference was in the execution, fluidity and attitude to the performance: how accurate the moves were being performed individually and collectively as a group. An interesting point I thought was that you could recognise the really talented dancers by how they looked at each other and the audience.

Modern dance seems to be (or is) very free in terms of movement, style and composition - akin to agile methods in software engineering. In some ways, modern dance is easy ... anyone can just move, similarly to agile methods, anyone can hack a project together. But to get a consistent, fluid, elegant whole is extremely difficult in that the choreography of the individual dancers becomes very difficult to make consistent, unless the dancers are very experienced and instinctively understand how each is moving relative to oneself. I suspect the very good dancers here have or understand the fundamentals of movement to a very precise degree.

Ballet on the other hand is very strict with a limited set of movements which themselves are precisely defined. Wikipedia's (sorry, I know you shouldn't cite wikipedia!) article on ballet contains the statement:
"It is a poised style of dance that incorporates the foundational techniques for many other dance forms."
I need say no more regarding the basis of ballet for other forms of dance.

An in that respect we have our link with mathematics, computer science and software engineering. Formal methods are computer science's version of ballet: strict rules and technique and hard to master but forming the basis for the rest of the subject, especially software engineering.

When auditing, watching or even performing the "art" of software engineering - or at least - developing software (and systems); those who have an understanding (either explicitly or implicitly) a deep understanding of how the science works build the best software. The "moves" of the software engineer are deliberate, planned and executed with precision. This remains the same whether this is agile or formal development, though most agile development tends to be very ad hoc, messy, immature and poorly executed - like the modern dancer without discipline.

And indeed this is the core of what makes a good engineer - not whether they have the formal grounding, but they have an understanding of what makes the engineering work and the discipline to actually use those techniques properly.

Wednesday, 14 March 2012

Relative complexity

I'm told that software engineers don't understand taxonomies and ontologies, which confuses me a little - or actually a hell of a lot because I'm not sure what this statement actually means?

Are we saying that our software engineers are on one hand stupid but on the other hand build complex class hierarchies and relationships then navigate through the various mechanisms for building instances of those?

I currently have to construct an ontology/taxonomy for data/information with some real bizarre simplicity requirements which will ultimately reduce something inherently simple down to something unusable and without any real worth. Primarily because I am told that software engineers won't understand anything complex.

This troubles me.

Must go, off to another debate about syntax, or specifically the naming of things; or probably the colour of the picture in Powerpoint - wrong shade of pastel blue again....Wadler strikes again...

Wednesday, 7 March 2012

Tuesday, 6 March 2012

CFP: IEEE International Conference on Semantic Computing 2012

Industry Session Call for Papers

IEEE ICSC 2012: The Sixth IEEE International Conference on Semantic Computing 
September 19th- 21st, 2012 
Palermo, Italy
Program Goals and Format: 
The goals of the ICSC 2012 Industry Session are to foster exchanges between practitioners and the academics, to promote novel solutions to today's challenges in the area of Semantic Computing and applications, to provide practitioners in the field an early opportunity to evaluate leading-edge research, and to identify new issues and directions for future research and development efforts. Similar to regular papers, the papers in the industry session will undergo a review process and will appear in the conference proceedings. However, the selection criteria for industry papers are slightly different. In particular, papers should describe technologies, methodologies, applications, prototypes or experiences of clear industry relevance. A main goal of this session is to present research work that exposes the academic and research communities to challenges and issues important for the industry. Therefore, the papers in this session will be evaluated primarily by the novelty and applicability of the insights from its industrial solutions, instead of the originality of its algorithmic content. 

Topics of Interest: 
Topics of particular interest include but are not limited to those identified in the main conference call for papers, as well as those listed below:

1. Development of new semantic systems, architecture, and standards 
2. Employment of semantic computing tools and interfaces 
3. Employment of large scale semantic systems 
4. Benchmarking and performance evaluation of semantic systems 
5. Innovative solutions for performance optimization
6. Mobile semantic systems and services 
7. Multimedia semantic content analysis and retrieval systems
8. Modeling issues and case studies of semantic computing 
9. Game and entertainment applications 
10. e-Business and other applications 
11. Analysis of industry-specific trends and challenges 

Important Dates
Demo Submission: May 04th, 2012
Notification: June 28th, 2012
Conference: September 19th-21st, 2012

Industrial Paper Submission: 
Industrial papers should be submitted via the ICSC 2012 online paper submission system. Industry Session papers should be no longer than 8 pages with the same submission guidelines available on the ICSC 2012 web page. Only electronic submission will be accepted. All industrial papers will be peer-reviewed and published in the conference proceedings, which will be published by the IEEE Computer Society Press. Submissions must not be published or submitted for another conference. 

Industry Session Co-Chairs: 
Alexander Loui, Kodak Research Labs, USA
Vito Morreale, Engineering SpA, Italy
Ian Oliver, Nokia, Finland
Evelyne Viegas, Microsoft Research, USA

1. Every  paper accepted for publication in the Proceedings of ICSC 2012 MUST be presented during the conference.
2. Every  paper accepted for ICSC 2012 MUST have attached to it at least one registration at the full member/nonmember rate. Thus, for a paper for which all authors are students, one student author will be required to register at the full registration rate.

Sunday, 4 March 2012

Progams are models

Funny how some themes tend to recur through computer science and a post on "Enso Blog" turned up this gem: Why I don’t consider Programs to be Models:

My main point here, however, is that I prefer to not think of programming languages as modeling languages. The reason is that, for me, a modeling language must be about what behavior is desired, not how to implement that behavior.

I spent a huge amount of time working on this, especially in the context of the MDA and actually trying to convince people that a description in some language such as UML was just as valid and concrete as a description in some executable programming language - though it was ironic often that something in SDL was considered a program but something in UML was considered a model.

At the time there was parallel work on something called 'executable modelling' - though interestingly that particular group never wanted to discuss what they meant by either term 'executable' or 'model' the end turned out because of this failing to even attempt to address these terms that particular approach (if it was even a valid approach given its lack of semantics) failed.

The posting mentioned earlier refers to another blog entry on the subject by Zef Hemel in his post Models are Programs. I tend to agree wholly with the point made there and thus indirectly with his PhD thesis: Methods and Techniques for the Design and Implementation of Domain-Specific Languages though a little surprised that mention wasn't made to some of the work in this area on specifications, especially the classic Fuchs' Specifications Are (Preferably) Executable.

However I can see the discussion on specifications versus programs lurking there but whichever way you look at things, a little abstraction reveals these things are all the same anyway.

So, after setting this up, while I don't agree with the first point and agree with the second, I do think there is an interesting taxonomic or ontological question on what makes a model different from a specification from a program - not to mention what makes something "executable" or not.

But to specifically address the point that modelling languages are about desired behaviour and not implementation is flawed in the sense that all programming languages are an abstraction - just depends on how deep you want to go.

Anyway, its late and I'll need to dig out from the recesses of my brain some of the work I made in this area but always nice to see these things haven't been resolved and still stir controversy :-)

Johan Lilius , Ian Oliver (2007). Towards a Formal Definition of Model Driven Development (2007). Technical Report. Åbo Akademi.

Saturday, 3 March 2012

Are you logged in?

You can run it here:  Social Network Login Status Detector Demo

Never attribute to malice that which is adequately explained by stupidity.