Sunday 24 January 2016

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.