IKANGAI Solutions. e.u.

I took a small dive into the language design pond, after I stumbled over a paper by Linda McIver and Damian Conway that discusses Seven Deadly Sins of Introductory Programming Language Design. After years programming, I almost forgot how difficult it is to learn a programming language; let alone designing one .

In his blog post Andrej Bauer also explains a few (bad) programming language design decisions that have survived from the ancient past, i.e., the Seventies:

If this were the year 1972 we would talk about efficiency first and forget about the programmers, because 37 years ago hardware and processing time were the scarcest resources. Today we live in different times when the most expensive resource is development time. In 1972 it was a good design decision to implement arrays in C so that they did not carry with them information about their lengths (save a couple of bytes on each array), it was a good decision not to check for out-of-bounds errors in array indexing (save a couple of CPU cycles), and it was a good decision not to have garbage collection (it didn’t work well anyhow).

In my struggle to come up with a human understandable (and therefore human readable) syntax for Tweetflows, I noticed a few things that I tried and that are probably not a good design decision as well. All are based on decisions that come from taking the language environment a little too much into account. With Tweetflows, I intend to create a minimalistic syntax with as little as possible language elements. The reason for this is threefold:

• Tweetflows should be used on mobile devices with a small screen and limited typing capabilities
• Tweetflows should work over different media (Tweets, text messages, Push Notifications)
• Tweetflows, Tweetflow commands respectively, should resemble natural language as close as possible

In Tweetflow commands, I’m using command state modifiers (e.g., SR, SF), the address operator @, the dot . and verb modifiers like did. I noticed – when I tested the language with Amazon Mechanical Turk Workers – that the state modifier is difficult to understand for people. The rationale behind this modifier was inspired by the use of RT to denote a Re-Tweet on Twitter. Re-Tweets inform the reader that the corresponding Tweet originated elsewhere and was simply repeated. Thus, RT includes meta information about the Tweet. In the case of Tweetflows, I need meta information for being able to scan for Tweetflow commands in the timeline of the Twitter user. Apparently, this adds some confusion, because some Tweetflow command modifiers add meta information twice. For example, the syntax

SF @ikangai didProofread.Blogentry http://www.ikangai.com//blog

contains SF AND did to denote that the Tweetflow command has been executed. A more intuitive solution is as follows:

@ikangai didProofread.Blogentry http://www.ikangai.com/blog

However, this adds complexity for the Tweetflow parser and creates a new language construct without the state modifier. A potential direction is to look into a new direction and attach the state modifier directly to the verb of the command syntax:

@martin do.Proofread.Blogentry http://www.ikangai.com/blog

The corresponding answer is then:

@ikangai did.Proofread.Blogentry http://www.ikangai.com/blog

Notice that natural language is not free of ambiguities concerning the verb DO. DO can denote the general ability to do something (I do this) or an inquiry to do something (Can you do this?). In natural language the difference is made clear by the structure of the sentence in which DO occurs. With Tweetflows it is a bit different, because the structure remains constant and the semantic difference may not be that obvious.

The bottom line is that I will have to make additional experiments with Tweetflows and learn how people react to the syntax. Based on my experience so far, I’m thinking that I’ll have to remove the command state modifier from the syntax (as shown in the example below):

proofread.Blogentry http://www.ikangai.com/blog
@ikangai can.proofread.Blogentry http://www.ikangai.com/blog
@martin do.proofread.Blogentry http://www.ikangai.com/blog
@ikangai did.proofread.Blogentry http://www.ikangai.com/blog

If you understand the Tweetflow, feel free to post your interpretation in the comments.

your ikangai science team

We’ve been working on the Tweetflow notation for a while now and after we’ve integrated Tweetflows into Push Notfications, we came up with the idea to represent Tweetflows (more specifically: the Tweetflow service requests) in the JSON format. Each command is a triple and consists of the command (the verb), the object and the data where the object comes from. The latter is typically represented by an URL that points to the actual object (we call this COD notation – Command Object Data). This approach lets us easily encode sequences of Tweetflow commands in JSON. The example below shows a generic download and install description for an app:

{“tweetflow”:
[
{"command": "download",
"object": "app",
"data": "url"}
,
{"command": "install",
"object": "app"},
"data": null}
]
}

An alternative (maybe even better) way to represent Tweetflows is YAML. We will also look into this direction.

Your ikangai science team