Talk at Salon des Refusés 2018

On Monday I gave a talk at the Salon des Refusés workshop about Semiotic Programming that seemed to be received well. The best comment was along the lines of, "it's surprising that no-one else has suggested this idea in the last 50 years!"

The abstract and pre-print version of the paper can be read on the conference website here: https://2018.programming-conference.org/event/refuses-2018-papers-semprola-a-semiotic-programming-language

Semiotic Programming

After little bits of deliberation over quite a few months (and discussions with a few people) I have decided to change the name of this project from 'Semantic Programming' to 'Semiotic Programming'. I've also changed the name of this blog to be primarily focus on Semprola, the Semiotic Programming Language that I'm writing.

The main reason for the change to the blog name is because Semprola is going to be the 'face' of this project that most people are likely (one day I hope!) to encounter and engage with. The theoretical underpinnings of the language (the ideas of Semiotic Programming) will only be of interest to a much smaller group of people.

The change of name for the underlying theoretical project to 'Semiotic' from 'Semantic' is for a number of reasons:

• The project is actually best understood as a way to program with computational 'signs' and so 'Semiotic' is an even more accurate description than 'Semantic'
• There was always the danger that the use of 'Semantic Programming' would be confused with 'Semantic Web' and indeed people sometimes use the term 'Semantic Web Programming'.
• In contrast I have not seen (so far!) another similar reference to Semiotic Programming and so there is less chance that someone looking at the project can presume that they know what this project is about from some other similar sounding programming project.
• And, it is worth noting that while a few people do talk and write about the 'Semiotics of Programming Languages', this is no more of a clash than existed previously with the study of the 'Semantics of Programming Languages' 

In what way is this 'semiotic' programming

Roughly speaking, 'semiotics' is the study of the ways that signs have meaning and are used in communication. As with most projects that appropriate the name of a philosophical domain with a long and complex history, Semiotic Programming (SP) takes a few ideas from semiotics (in particular using terminology from the Saussurean semiology tradition, but not exclusively) in order to describe what is happening when a machine is executing an SP program. 

Again, very roughly, semiotics talks about a sign, such as the word 'tree' in the sentence, "look at that tree" as being composed of three things:

• The signifier - in this case the actual text of the word:  tree  
• The signified - in this case the concept of the tree being referred to
• The referent - the actual tree in the world being referred to

Often within semiotics the referent is left out (the theorist 'brackets the referent') because it is considered so philosophically hard to reason about the connection with the 'real' things being referred to. However, within Semiotic Programming the tendency will be to 'bracket the signified' as it is so hard to talk about the conceptual realm of a computational machine. 

However, I do not think that this diminishes the value of using semiotic terminology to discuss what is going on, precisely because these computation machines will be using signifiers to communicate with humans who we know will understand these signifiers through the concepts signified to the receiving human.

So, I think it is entirely valid, and indeed extremely important, to understand the ongoing 'sign processes' between groups of humans and machines in semiotic terms. 

However, as I've mentioned at the start of this blog post, if Semprola is ever used widely, then the theoretical underpinnings of Semprola will only be of interest to a small subset of its users and therefore (in general) I intend to focus this blog increasingly on the end users' experience of programming in Semprola.

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.