Humble

The Humble programming language? System? Whatever it is, it's a table-based way of defining algorithms. Very cool.

SYMADE

An example of semantic-oriented programming. Interesting.

Wikis and the Lexicon

The Lexicon is the semantic unit database for a given system. Its keys are the unit names (more or less words), and its records are the sloppy, messy definitions of those concepts.

A Wiki is also a way of mapping from terms onto definition-like text. So is writing a Wiki sort of cognate with defining a domain for semantic programming?

Kind of. I'll bet a Wiki structure would be a fantastic way of annotating a Lexicon; this is the approach I'm going to attempt at the quant-semantics Wiki. A Lexicon entry is going to be much, much more fine-grained than a sensible Wiki structure would comfortably support, but if we think of a Wiki page as a microdomain where concepts are grouped together for ease of presentation, this might be quite useful.

Then we would just scrape the Wiki to compile the program. How cool is that? For this to work, the Wiki is going to have to support code (which Wikispaces does), and the compiler will have to know how to tell smoo code from syntactic structures.

I think this might work! Then the semantic programming Wiki could end up being the general library for inclusion.

What a pretty concept!

Design patterns

Design patterns encode certain approaches or "semantic chunks", if you will, of a finished system. Sort of a high-level macro. Semantic programming will probably end up using a ramified and very detailed set of something like design patterns to build everything, so again: good start.

Probably I should set up some kind of Wiki backing for this blog.

UML

UML (Unified Modeling Language) provides a set of tools to specify the context and basic concepts of a software system. Again: good start.

Methodologies

Methodologies also approach what I'm getting at, without going the whole way. A methodology expresses the processes used by a team to achieve project goals, not necessarily specifically to software. As such, the methodology talks about how to find out domain knowledge (well, this is one way of looking at it) and provides some hints or clues about what knowledge must be found.

Boy, this is a shallow post.

Literate programming

I spent a few years working with literate programming tools, even writing my own XML-based markup language for the purpose. If you're not familiar with the notion of literate programming, it was invented by Donald Knuth while writing TeX, and formats source code (using TeX) as a readable book. The TeX source code is, in fact, a pretty readable and entertaining book.

Knuth's insight was that the order of presentation that makes understandable reading is not the same as the order of presentation that makes parsable code - he was using Pascal, so all the variable declarations had to be at the outset of a given function, but he wanted to introduce them where they were used, for instance.

His system also generated an index of identifiers and did some other nice presentation-oriented stuff.

So I wrote my own literate programming system and used it for several years, and it really did help me organize my code. But it doesn't go far enough; there's still no semantic information that's machine-usable.