contenteditable="wow!"

In the last month, I've been catching up with where HTML5/CSS/JavaScript have gotten to, and wow, how did I miss the introduction of contenteditable="true" !!

I was reluctantly re-looking at the web as the provider of the graphical front-end after realising that it really did best fit my three main criteria for the UI: 1) independently threaded client side rendering; 2) wide adoption across many client devices; and 3) general expressiveness of possible UIs.

However, I was doing this reluctantly as there are many aspects of the original 'post-back' model of web interactions that I have grown to detest and have generally felt that the JavaScript 'solutions' to fix this were like a sticky tape and string hack on-top of an out of date model for UI construction.

But most of all I dreaded the imagined process of building a credible WYSIWYG editing experience. 

Somehow I assumed that all of the tools that achieve this on the web today (Google Docs etc) were doing some kind of complex, proprietary rendering and overlays approach using JavaScript to create the impression of dynamically editing a document. I had imagined all sorts of horrors like JavaScript timers drawing the caret and removing it to give the impression of it blinking, etc.

Not for a moment did it occur to me that 'they' might have built WYSIWYG editing into the web! I started looking at all sorts of WYSIWYG plugins and libraries and unpicked the code in each trying to learn the complex magic that underpinned all this imagined wizardry until I realised that all the (recent!) such editors are relatively simple and rest on contenteditable="true"! 

And, most importantly, this feature has been widely adopted and supported and so it really is a credible route to go for building an online content editor. So, now, despite the web's other imperfections, my attitude has switched 180 degrees and I am really enjoying building a prototype web based Semprola editor!

Indeed, I now cannot imagine the horror of building the UI any other way!

Making reference to semiotics

For various professional and personal reasons progress on Semprola has been rather slow this year. But I have had quite a productive spurt of work in the last month as I have been noticing the connections between my work so far and some of the ideas in semiotics. This came about as I was looking for a replacement for the term 'reference' that I had been using to refer to a key type of data-structure that refers to other data-structure(s) in a possibly non-trivial way. My use of the term 'reference' is at odds with the way that philosophers use it (e.g. the sense/reference distinction) and I was increasingly unhappy with the way that I was using it. In comparison the semiotic term 'signifier' gives a much better indication of what these data-structures are for and how they are being used.

In particular I had been looking at the issues that arise as various different audiences use these signifiers (e.g. the author of the program, the computer agent running the program and then the user using the program). Semiotics seems to have an appropriate lexicon with which to talk about the way that the same signifying data-structure can have different meanings in different contexts and potentially change meaning over time.

I'm in the process of reading two books on semiotics at the moment the first of which is a general introductory book on “Semiotics: The Basics“ and the second is a PhD thesis where someone has already looked at the "Semotics of Programming". Once I've completed this reading I hope to finally finalise the terminology that I'm using and get back to completing the syntax of Semprola.

And, while to some this may seem like a classically unnecessary detour into something interesting but not essential to the project, for me this choice of core terminology is absolutely crucial as it will inform how I develop some of the context-aware features of Semprola (one of the last major conceptual things on my to-do list) and it will also colour everything I write about Semprola (although I know that most users will not be [initially] interested in this link with semiotics so it will certainly not be in the foreground!). 

A more minor interest in getting the terminology right (and finalised) is that I already have some re-organising of the underlying VM code that I need to do and when I do this I want to strip out the pervasive use of the term 'reference' and replace it with the 'right' term that I am more confident I will stick with. And I'm now fairly certain that 'signifier' is the right term. 

A look back to the future

Anyone interested in the future of programming should watch this great talk: http://vimeo.com/71278954

Phil sent me the link and has also commented on the talk here: http://smartdisorganized.blogspot.com.br/2013/07/the-future-of-programming.html

I agree with some of Phil's comments about why we've ended up where we are, but I also think Bret's point was meant to be less specific and more inspirational. It was more of a wake up call to try something new and it certainly encourages me to keep going with this project.

Simple multi-platform build

Over the last couple of weeks I've finally been able to get back into the code that I had developed over two years ago.

One of the first tasks has been to connect the rudimentary SSP Agent code to some kind of cross platform UI toolkit so that I can start building a UI to help test the on-going development. In the end I've picked wxWidgets as it seems to have the basic features I require without making the build process too complex. The other obvious contender was of course Qt which is very tempting, but involves a more complex build process. Later down the line, when I get to the stage of building the UI engine for Semprola itself, then maybe I will need to revisit this decision, but for now wxWidgets is totally adequate.

I have also extended my Eclipse based build setup so that I can compile for Linux (Ubuntu 12) as well as for Win32 and Mac OS X from the same codebase. Just today I have successfully completed a very basic build of the SSPAgent as a static library linked into extremely simple wxWidgets application on all three platforms.

So, now I'm finally ready to start some new development of the actual codebase!

It's been two years!

Wow, I've just seen that it was exactly two years ago that I last posted anything to this blog. This year my focus will be shifting back to this research project. Main main goal for 2013 is to release an early beta of Semprola that other researchers could play with. I'll post more about my plans as they develop.

The SP Graph is not for humans

I was contacted recently by Yuriy Guskov who has written a critique of semantic web and semantic programming.

Obviously there are many details that Yuriy raises that it would be interesting to discuss, such as about the nature of references and their context and how SP intends to define contexts, some of which will become clearer when I put together an updated version of the 2008 paper and publish more details about how I am actually implementing SP.

However, there is one general comment that I would like to make just to be sure that a key aspect of SP is sufficiently clear. There is no expectation that humans will ever 'read' the SP Graph directly. The SP Graph is intended to represent semantic relationships and information as accurately as possible for the SP Agents, not for humans. That is why the SP Graph is constructed out of unique IDs, not out of words or text.

In the same way that humans use OpenOffice to read .odt files (viewing the data as a WYSIWYG formatted text file, not a large block of XML), so too humans will need to use SP Agents to read and interact with the SP Graph. Language is a very useful way for humans to interact with each other and with recorded information, but human languages are often very ambiguous with a large amount of unspoken context. Computers (internally) require a much higher degree of semantic precision in how their data is organised so that their deterministic syntactical manipulations of that data is semantically correct.

In many ways, therefore, SP can be seen as a step away from many of the current approaches to artificial intelligence, indeed it is not an attempt to create artificial intelligence. Rather, SP is an attempt to improve the way that humans directly program computers.

Time for flex and bison

A couple of weeks ago Phil lent me a book in which the creators of various programming languages are interviewed (Masterminds of Programming). I've only read a few of the interviews so far, but these have included the creators of C++, BASIC, Python and Forth. On the whole it's been fascinating reading and very relevant to this research project.

Fortunately, one theme that seems to be repeated is the idea that in general it's a 'good thing' for people to experiment with creating new programming languages. This of course is very encouraging for me to read, especially coming from these particular people.

As well as being full of discussion about generic issues that are useful for creating, disseminating, evolving and standardising a programming language, there have also been a few very specific bits of advice that I will try to follow, one of which is to use flex and bison when building your compiler.

Flex and bison are tools that help generate fast and correct C code for the first two steps of any text compilation process, namely: lexical analysis and grammar parsing. To date I've been hand crafting the C code for these two steps of my Textual Semprola compiler. I've known about flex and bison for a while, but always thought the cost of the learning curve and the code re-write were not quite worth it.

However, I'm about to go through a phase where I considerably extend and tinker with the syntax for Textual Semprola and so now I need to re-write this part of the code anyway. As I'm also reading more people sing the praises of flex and bison I've decided that this time I should push through the learning curve and start using these powerful little tools. The great thing is that once I've made the switch it should be easier to experiment with the syntax in the future.

One other thing to mention is that I've recently started some more client work. While this will no doubt delay the progress of this research project it does also help fund it!