And I thought I was ambitious, trying to write a programming language!

My friend Oli has decided to reinvent programming as we know it. Details are still trickling out via his web-site : Semantic Programming. And I'm in frenzied skype conversation with him, trying to figure out what it's all about.

In outline, it starts from some intuitions behind the Semantic Web : that there should be a massively parallel, distributed graph-shaped database of facts (relational assertions) represented on different machines across the world. But it then layers programming on top of that. Instead of a passive data-structure crawled by scutters, SemProg agents (roughly, the servers which manage different data-nodes) are active. There is message passing between the facts themselves, and agents may have hardwired interpretation to act on some facts (what Oli is calling "axiomatic" understanding), or a "deductive" understanding (I guess rather like Prolog inference), and even a "behavioural" understanding via (I guess again) learning from observing other agents.

I'll keep following this here on Smart Disorganized. Very interesting if it works out.

Would GeekWeaver support Semantic Programming? It seems like Oli is thinking of multiple editors for different types of information, all of which compile down to the same underlying graph-structured format so that the data can be combined. (Rather like Language Oriented Programming.) It seems quite possible that GeekWeaver could output something like his graph-format. I'll certainly be experimenting.

I'm also trying to persuade Oli to look at Erlang as a potential implementation language for the distributed virtual machine. I'm increasingly impressed by Erlang. Finding it very powerful and concise.

Towards End-User Programming with Wikis

Paul Graham's Arc Challenge . Examples in Lisp, Smalltalk Seaside, Ruby, Perl and Python (using generators instead of continuations)

And an Erlang response.

@adrianh suggests looking more at Parrot Compiler Toolkit ... which is very cool.

I'm finding that language design is hard. Not just the implementation part (although that's hard too) ... but just figuring out how to make a syntax that allows all the things you'd expect to be done in an elegant way.

I'm starting to appreciate how clever certain common design patterns are in language design, and how hard it is to deviate from them. More on this soon ...

Ian Bicking on what PHP deployment gets right.

I'm playing with pipelining in Python over on Composing.

Here's an interesting question (after reading this).

Why does anyone want to write "large" programs? Everyone knows large programs are difficult to build and maintain. Want we want is *small* programs that happen to be powerful (do a lot) and scale over large numbers of users. Is there any reason to think that "large" program correlates with either of these things?

Supplimentary question. Are 10 programs of 1000 lines each, which have to nevertheless interact (via pipes or XML-RPC calls etc.) actually any easier than one 10000 line program?

Update : Folknology has been making a pretty decent case for Erlang as a language optimized for writing software as a swarm of small programs.

Discipulus, patterns for programmers.

LOLCODE IZ IN UR COMPUTR RUNNG THINGZ

Python on Silverlight?

I'm intrigued despite myself.

E.E.Kim on tools

Looking at some slides about Perl 6(pdf) ... some cute features.

Quick note : Blahsploitation is no more ... long live "Composing"

The impotance of being earnest :-)

Update : which reminds me of a discussion I'm having with Sig

Update 2 : Seems like a lot of ongoing discussion around the place. Joel Spolsky explains.

Update : for people wondering how the whole new-SdiDesk-in-Adobe-Flex? thing is going. I solved something I thought was a problem yesterday.

I now have a (very fragile) Flex front end which can pass plain-text GeekWeaver programs to a web-server with GeekWeaver embedded, and get a compiled chunk of GeekWeaver out.

That's very cool ... unfortunately it also revealed yet more problems with the GeekWeaver compiler which need fixing before I can release the next version.

Still, it looks promising. The signs are better and better that something interesting is coming out in the next 3 months. :-)

Restless Mind Syndrome (propaganda for the ultra-cool looking LiveScribe)

He he! Perhaps NooRanch is NooVictorian ....

(I know, bad, bad pun)

What's this?

• 1
• 2
  • 21
    • 211
  • 22
• 3
• 4
  • 41
  • 42
  • 43
    • 431
      • 4311
• 5

An HTML list that came out of GeekWeaver, when I called this recursive function :

::rec
  .<ul>
    :for x,, #__
      .<li>
        ${x/=}
        :hasChild x
          :rec ++ #x__

on a chunk of OPML.

That's pretty much how it's going to look, folks.

::rec defines the recursive block (or function)

.<ul> creates the UL tag

:for x,, #__

is creating a loop through all the anonymous (unlabelled) children of the tree which is being passed to the call. (This list is represented by the symbol __)

Note that I'm trying to keep GeekWeaver as functional as possible so there's no real "assignment". x is scoped so that it only exists inside the block of the for-loop, it's bound once before the block is evaluated, but can't be updated after that.

${x/=}

This is the new way of accessing variables. x is actually bound to a sub-tree (Almost everything in GeekWeaver is a sub-tree, except a couple of weird cases like __ which is a list.)

Although a simple $x still works if you want the whole of a tree flattened into a string, ${} expressions give you a way to pull data from a single path in the tree. In this case we're just getting the text content of the root node of x.

But it's also possible to write stuff like this : ${company/employees/__3/name} which means from the symbol "company" get the labelled child "employees" from which get the non-labelled 3rd child, from which get the child labelled "name".

:hasChild, like :for, is a build-in function. If the tree in x has any children, it evaluates the body of the :hasChild tree. If not, it returns nothing. This tests for our "base-case" when we've hit a leaf of the tree we're recursing through.

The final line :

:rec ++ #x__

is the one which I've been struggling with for the last three months, ever since I started trying to figure out how to support recursion. I'm still not 100% happy with the solution I've come up with, but it's getting there.

:rec is calling the recursive block again. And obviously I need to pass the children of x as arguments. However the way the function is written, it is working on the anonymous children (inside the default variable __)

How am I going to get the children of x into the __ variable inside the next call of :rec? That's what ++ does. Not sure what I'm going to call this, I may call it a "pivot" although that may confuse as much as help. It captures something of the idea that I need to swing the anonymous children of x (#x__) around so that they can go into the next call of :rec as though they were children of the calling node

Like I say, don't know if I like this name or the ++ symbol being used for it. So consider both as provisional for now.

OK, I'm too tired to make the build with this stuff working tonight. I'll try to get a build together in the next couple of days, but meanwhile, if this looks interesting to you and you can't contain yourself, send me an email (interstarATgmail.com), say hello and I'll see what I can do.

Wasabi part 3

And some of Martin Fowler's book on DSLs is online.

Hey! I like NeoVictorianism.

There's a movement I can sign-up for :

Built for people

Built by people

Crafted in workshops

Embracing irregularity

Inspired