Thursday, August 26, 2010

An adventure in real world programming with 5 languages


I wanted to build a tool which I can use on my mobile (Android, HTC Desire); not finding a path to compile Haskell to anything executable on the mobile, I decided to follow advice from Building iPhone Apps with HTML, CSS, and JavaScript to build a web application using Haskell to construct the web server with Yesod .

What I did not expect was the number of un-coordinated and slightly different languages I had to learn. The project included a total of 5 different computer languages:
- Haskell, for programming the application,
- CouchDB (fortunately accessible from Haskell),
- javascript, to code the building of the index in couchDB,
- HTML, to describe the structure of the output,
- CSS, to describe the appearance of the web page.
Modern computer languages are quite similar, but differ in small ways: how do they deal with white space and what is white space? how to insert a comment? how to 'escape' a character, which has a particular meaning?

In the process I was reading documentation, and could not, for example, find an advanced, well structured description how to use HTML and CSS; the specification is readable, but does not indicate how the various features, which seemingly are producing the same effects, are best used, to avoid their quirks. Not only had I to learn the languages, but also to find specialized editors and tools for debugging (e.g. a Firefox extension to see what HTML and CSS arrived at the browser) - each tool with its own set of 'small differences'.

I succeeded, but two questions remain, one existential, one social:
- is it possible, to build a web application in a single language (specifically: in Haskell)?
- why do the 'real programmers' accept this sorry state of the world?

The first question leads to a testable hypothesis, which I hope to report about soon; the second reminds me of an observation of a social science researcher (I do not remember who it was), who pointed out that social institutions oscillate to a middle ground of complexity. If they are so simple that everybody can understand them, ingenuous people make them more complex; if they are so complex that nobody can use them any more, efforts to simplify are made. I guess, social systems need complexity to differentiate between amateurs and experts; complexity assures income to experts. This seems not only to apply to the legal system, with layers and tax advisers, but also to programmers?

Thursday, August 12, 2010

Semantic Engineering - What is the Common Ground?


There are a number of people trying to make ontologies a practical tool for designers of information systems; many are engineers and use the term "semantic engineering", e.g. the title from a paper by Werner Kuhn to which he recently refered but I find other other papers with the same title. There is even a conference ICOSE 2011 - International Conference on Ontological and Semantic Engineering . I assume that not everybody uses the term in the same sense, but perhaps there is more agreement between the Semantic Web community and the GIScience ontology community in the use of the phrase.

Reading the paper by Kuhn triggered by his comments on my blog entry "Ontologies for what?" identified much commonality in his treatment and my thinking. Presentations by Helen Couclelis at GIScience 2008 (Ontology, Epistemology, Teleology: Triangulating Geographic Information Science) and recently in Las Navas identified some common grounds as well. Even reading the slides of a presentation by Pierre Levy in Banff 2007 I find similarities to Kuhn's paper.

I am wondering, how much we agree? Disagreement may result from fundamentally different philosophical positions, but more often, it is a difference in the use of terms. For example, Kuhn uses 'concept' to describe the triad 'symbol, thought, referent' and I used it in the blog to describe 'thought' only. Would it be possible, to start a wiki in which a small group of semantic engineers tries to establish a rational, agreed base for acceptable and necessary assumptions (ontological commitments) and terminology. I hope there is more commonality hidden behind confused terminology.


For a very different use of the term "Semantic Engineering" read "American Thinker" on the "war on words" !

Sunday, August 8, 2010

Applications on a mobile device


In my effort to study the ontology of space, time and persons in my life and how to organize it in a better Personal Information Manager, I want to build a system I can use to test the ontology to gradually improve it. I believe that only ontologies which are actually used can teach us anything about ontology design.

Therefore, I need a method to build applications on the mobile design in a high level language such that I can derive the code from a formally described ontology, preferably Haskell, which reveals structure of the program and does not force programming in particular ways. Simply: I need a Haskell compiler producing code executable on the mobile, because only if it is executing on the mobile and the data are synced, the application is available even if not connected to the Internet.

There are project to compile Haskell to JavaScript, which can be executed in most browsers on the mobile and small server programs running in a mobile exists. Unfortunately, neither of the JavaScript project is currently usable. They are often based on the York Haskell Compiler (yhc), which seems abandoned. Other projects are 'proof of concept' and to make them usable is beyond what I am prepared to do. It will take some time, before I can compile Haskell and run it on the mobile.

Second best:

Use another language, e.g. JavaScript, lua or python which execute on an Android mobile. I fear this will detract from identify the ontology, ontological issues obfuscated by the particulars of the language. I briefly looked at OCaml, a functional language close to Haskell, but the code read as text was quite misleading ("ignore" all over the place - my brain follows the advice and ignores the rest of the line...).

Restrict the application development to make it usable only when connected to the Internet; then I can write in Haskell and hopefully drive the code from the ontology - as much as possible from a formal description of the ontology deriving the code automatically. Later, the code can be hand-translated to a language executable on the mobile (today, I would probably use Lua) and run there.

I want a better Personal Information Manager!


I have a mobile phone and it could be used for keeping track of the phone numbers and addresses of my contacts, my appointments and the things I have to do. Unfortunately, it is not quite as usable as the good old calender I used 15 years ago; the companies that produce paper organizers are still in business and perhaps I should get one again!

What are the issues?

Contacts: Initially, on my first Nokia phone, only phone numbers with a short name were stored. On the iPhone i managed to have two (or more) different lists on the phone and in my different mail accounts. They are all stored in my gmail account and sync works; on my Android phone it is really fully automatic; all my contacts were available, minutes after I switched the phone on for the first time! Open issues are:
- the mobile phone interface is not suitable to select among a large number of contacts; HTC Sense uses a T9 input system which works quite well, as long as I know a word in the contact.
- there is only one type of contact: what is the first name of a company? how to register a person in a company for whom i do not know the first name? obviously several types of contacts should be offered.

Notes: My electronic notes are as disparately distributed over many systems as my paper notes on my desks. Tomboy, using couchDB, syncs nicely all notes on my computers, but not on my mobile phone! Notes should link to other parts of my life.

Calender: The reason for having an electronic PIM is mostly that others, especially my secretary, has access to my calender and can enter appointments for me. I am not fond of the Google calender interface, but it syncs with my phone and produces alarms on midnight for 'all day events'...

Tasks: The task manager GTask, which I use on the Android, has a usable interface and syncs with the tasks in my Google calender, where the interface is barely usable. Not connected to anything else.

In brief:
- synchronization is an issue, especially if I am not connected to the Internet, which is the case whenever I am outside of Austria (data roaming is a financial risk in Europe!)

- user interface

- linkages between the items and other items i have to collect: expenses, photos, mail, folders related to the tasks I work on; there are weak links between the parts, but much more exists.

- persons and time are organizing principles, but location is equally dominating my life: I am always at one place and interact with people.

In one sentences: the ontology of the information that should go into the Personal Information Manager is not properly designed; it is a "bad" ontology, because it does not fit my reality!

Tuesday, August 3, 2010

Bloat or "as simple as possible, but not simpler"


Most software tools grow over time, only a small number stays the same. These are not increase in functionality, because they have already all what is needed; they are perfect. What is the receipt to achieve that?

In my own work I see the following pattern which leads to bloat: underestimating complexity and building something too simple. The pattern, once recognized, may lead to improved designs, such that software bloat can be avoided. Here two examples:

I tried to build a tool to automate the construction of graphical user interfaces from ontology and I included facilities for conversion between the screen representation and the representation in the application program. Different applications had different requirements for this conversion and the functionality grew ...
What was wrong? the complexity of the conversion requires a full programming language and I was, step by step and functionality by functionality inventing my own. Bad move!
What can be done? have the part which converts between GUI and application written in an ordinary programming language (in my case, Haskell) and remove all functionality which can be provided in the conversion functions written in the general programming language. - Progress: the tool becomes smaller and simpler!

I found the same approach in couchDB: parts, where complexity of the application comes in, are programmed in a programming language (e.g. views - compare with the complexity of special languages for report generation of old). CouchDB just manages the code (in javascript - a nice functional programming language!).

Bloat occurs slowly if we try to build something that is too simple, and then realize that a bit of functionality here and a bit of functionality there must be added and before we see it, we have BLOAT. It is a sign of not factoring out complexity in parts where it can be handled with the ordinary programming language and can be avoided in many cases.