When on Windows I use the conTEXT editor for basic text editing and for small programming tasks (when loading a full IDE would be a tad excessive!). The conTEXT editor website lists syntax highlighters for all sorts of programming languages. However, when experimenting with the Go programming language today, I discovered there was no conTEXT highlighter for Go. So, I wrote my own.

Download

Download conTEXT highlighter for Go programming language (.chl)

This is based upon the Go programming language specification as of the 2011-02-15 release.

Installation

To install the highlighter, drop the Go.chl file into the Highlighters directory. By default this is:

C:\Program Files\ConTEXT\Highlighters

One of my worries about genetic programming is that we may just be shifting the problem of programming to the (equally difficult?) task of problem specification in the fitness function. This would be similar to the move made from assembly language to higher level languages such as Fortran in the 1950s. At the time this was seen as essentially solving the problem of programming, but that clearly isn’t the case, the problem was merely shifted to a different (albeit easier to understand) paradigm. In the 50s there were advantages such as easier to read and debug code, and shorter programs. Now, if we make the complete shift to formal specification for an evolving generator, what will the benefits be?

Initially it seemed to me that this would be a no-win situation. By requiring a formal definition of the problem, non-trivial programs are still going to require non-trivial specifications. Further, the skill of writing non-ambiguous and correct formal specifications is a challenging task requiring a reasonably in-depth knowledge of logic and the sort of mathematics that many shy away from.

What would be the ideal situation? Ideally any average non-programmer would be able to generate a program by doing no more than describing what it should do. That is still infeasible, but if we could automatically generate programs from an informal requirements document, then that would be a useful step! This has more practical potential than is immediately obvious. There has been a rather large amount of research, going back as far as the 1980s, into automatically generating formal specifications from informal, natural language definitions. Some of the results appear very impressive. So, if we are able to generate formal specifications from something close to natural language, and if we are able to automatically generate computer programs that satisfy those specifications, then it immediately becomes obvious that we can combine these two steps. We can generate programs from an informal description with very little expert interference. That is the theory at least.

This is not trivial in practice since there are difficulties in expressing formal specifications such that they provide a fitness function which rewards partial solutions and the generation of the specifications from natural language is farĀ  from perfect. However, these problems are certainly solvable and the solution would be a major step towards an admirable aim.

© 2012 TC33.org Suffusion theme by Sayontan Sinha