Screen patterns

Web UI design using patterns. Interesting. A pattern language would be another good target, you see. I'm trying to scratch out a plan.

Lisp in C

A micro-manual for Lisp in C

How linkers work

Sometimes it seems like nothing gets posted here but stuff that came from HNN. How linkers work.

GraphLab machine learning framework

GraphLab. A new parallel framework for machine learning.

AppEngine makefile

AppMake is a Makefile framework for AppEngine.

WWW::Mechanize and HTML::TreeBuilder

So I just wrote a little 40-line script to hit my router's HTTP interface and find out the list of DHCP clients currently connected. (This is preliminary to checking each for an rsync server running, and doing a backup on those that do.) To write this script, I used WWW::Mechanize, HTML::TreeBuilder, and maybe an hour and a half of divided attention.

Here are a couple of thoughts that occur.

First, looking at HTML results, then getting HTML::Element's find functions to find the things you're actually looking for, is a painstaking process that ends up with pretty brittle results. The parsley selector language would probably be a far, far better way to look for things in the HTML tree, and has the benefit that it could probably be declarativized pretty easily.

Second, the lack of Javascript capability makes this a particularly error-prone process; my router's forms all use Javascript for preprocessing of form input (which is stupid, but prevalent). I'm not sure that providing an entire Javascript parser is a viable option, though. I guess that would depend on the state of Inline::Javascript, assuming there is one. (If there isn't, well, maybe there should be...)

Third, this script naturally broke down into the Mechanize part and the HTML part. That is, once the document is obtained is when it gets parsed - ... this seems obvious, and maybe I'm still too jetlagged to notice that I've lost my point somewhere.

Anyway, it would probably be most instructive to take some actual scripts like this one, translate them into likely-looking declarative structures, and then implement those.

Color::Declarative

Since colors and their names come up with astonishing regularity in graphics (PDF, SWF, Wx, etc.) I've decided I need a common set of semantics. Exactly what that means is still a little underspecified, but it's important.

Color::Library - support for all kinds of existing color libraries/naming schemes

Graphics::ColorNames - general support for color naming

Other things to do with colors, maybe: Color::Mix, tools for Color::Schemes, and ... well, a CPAN search on color would probably find others.

The semantics of color are pretty neat, although a lot of it is symbols without referents for me. It might be interesting to make this class the first that really starts to be a semantic class.

Microsoft Singularity (ahem): self-describing systems

Interesting article at ACM; while I'm not convinced type safety needs to be enforced at the operating system level (!) I'm interested by self-description. That sounds enticingly like semantics, there...

Data scraping

ScraperWiki (HNN post about it, that is). As usual, there are lots of very interesting related links in the thread that I should follow up on, particularly the selector semantics of parsley.

Target domain: Hofstadterian microworlds

Reading through your old tag posts can make you think of things you meant not to forget.

Lest I forget this, though: one of the motivating principles for this pseudocode stuff is that I wanted a reasonable way to express the Lexicon for Magnifi*. So, literally, while I was mentioning them metaphorically back in November, Hofstadterian microworlds really are a target domain. More precisely, I suppose, the Lexicon for expressing them is a target domain. Getting that to mean actual fluid concepts... that will be a big project.

Data journalism at the Grauniad

Interview.

Thoughts for the evening

So I tried "adapting" some of the examples for Flash into a pseudocode form, and as usual, everything I do points out the holes in my plan. Then I go walk the dog, and possible solutions occur. Today's harvest:

The sokoban example from the gazbming is rather oddly written; he defines some functions to create tiles and sprites, then creates 200 wall tiles, a bunch of package tiles, and so on. Then to build a map, he moves the tiles in Actionscript (and the maps are encoded in the Actionscript).

So fine. I can imagine writing a macro that expresses the map encodings as Actionscript, but really those 200 wall tiles are a map. I don't want to create them with Perl (though I could), because normally I'm not running Perl at define time, only building code snippets and running them after start. Maybe I could rethink that, but in this case, it seems more elegant to express the 200 wall tiles as a map from a sequence (from=1, to=200) through a template into a series of macro-inserted structures.

Now, this begs the question as to what, really, a map is. I've been going on the presumption that it's a nodal structure thing - but in this case, conceptually, I'm mapping from a sequence onto a series of nodes. I can imagine the same thing with a set of row data. Now, in the case of a sequence (which is immutable) this is a one-way trip. If I map to data, it's ... maybe not a one-way trip, but I probably have to define explicitly how the data should be updated if the nodal structure is changed, and certainly something like this is probably one-way.

But the point is, semantically, this is a map. Just because it's not my two-way nodal structure doesn't mean I shouldn't still call it a map.

Oy. You want to do something simple, define a new programming paradigm and a language to go with it, and revolutionize the world, and then it's just one thing and another.

UML

I always figured UML would be interesting to look at in more detail, and once I even bought a book. (UML has been around so long I still had the habit of buying a book to learn about it, back then.) But ultimately, every time I look hard, it seems to be Much Ado about Nothing - or at least a little too much ado about Java class definitions.

But here comes an interesting blog post Wiki page from a couple years back talking about some kind of wacky pseudocode UML description language that could compile into pictures or something - look at it! Significant indentation! Great minds, apparently.

The graphics tools he's talking about there are collectively UmlGraph, which I ran across Googling on the word "declarative". You find the most interesting things trawling on some keywords.

Anyway. I already mentioned UML back in the first days of this blog as one of those systems that is "kind of like, but not" what I want to do. Its semantics, though, are intriguing. UML as a set of semantics for sketching solutions is a good intuition.

A thought on code organization

Well, it's a pretty thin thought. Mostly this: These Actionscript examples I'm looking at tonight instead of doing the paying work are a freaking mess. They build stuff, and move stuff, and do all sorts of things in messy imperative ways. Now, obviously I can't write Declarative for Actionscript - but I could write a sort of front-end that would compile to Actionscript.

But if I do that, then, then, well then I've written a front-end that could compile to anything. A sort of Code::Declarative, if you will. And I'm not at all sure I truly understand what that would look like, although to a certain extent it's obviously what this entire venture is fumbling towards.

So maybe I should spend a little thought on just what it means to compile to a text file. I mean, structured text is not such an outré concept.

It's really a macro system again. I wish I could implement just one version of a macro system so I could see how many ways it fails.

haXe

Oooh, language design. The new haXe language compiles to SWF, Javascript, C++, NekoVM, or PHP. Now that there is cool. (And the successor to mtasc, actually.)

Of course, it manages to make everything thus look like Java, but ... there's potential there.

RobotWar. The battlefield of the future.

Ah, the future past.

Welcome to the battlefield of the future! It is the year 2002. Wars still rage, but finally, they have been officially declared hazardous to human health. Now, the only warriors are robots - built in secret and programmed to fight each other to the death!

The RobotWar game was written for the Apple II, it's so old. The idea is that you can program little robot tanks, then run them in tournaments. The programming language is extremely restricted, so honestly, it should be easy to write. Right?

So wouldn't it be cool to write a Flash front-end to display the simulated world, and a Perl back-end to run it, and a Web service to organize the tournaments? Wouldn't that be neat? Sure it would!

Note: an Actionscript example of XMLSocket, which is how Flash can talk to the server. Another.

SWF::Declarative

Yet another interesting target for a declarative approach: Flash by way of Ming by way of CPAN's SWF module by way of a declarative wrapper. There is a truly excellent set of tutorials (using the PHP wrapper, but who cares?) here. Note that there are two entire games there as tutorials. Perl tutorials here. A Flash tutorial blog.

Flash is cool, especially now that the open-source community is getting to the point that it can deal with it. I'm particularly intrigued by the notion of being able to generate SWF on the fly like this, and being able to take a user interface that's been designed in one GUI paradigm like Wx, and translating it into a Flash environment. There are basic design principles that transfer - those are arguably part of the basic semantics of any GUI, and should be treated as such.

Man. So much to look at, so little time.

Later note: mtasc is an Actionscript compiler for library code.

Layout in wxHaskell

First: wxHaskell. Wow. And still their wx configuration is less than declarative if you ask me. But they've got one pretty neat library that I don't think I've seen elsewhere: Layout. Since layout is currently one of the things bothering me, I think I'll need to spend some quality time with this documentation.

I'm currently leaning towards a really graphically-oriented layout style, like this:

field field1
button one
button two
button three
button four
layout
 field1 one
        two
 three- four

See what I'm doing? Argh, maybe you can't if Blogger swallows my indentation again, but I'm actually lining the names of fields up to indicate they should be aligned. Dashes can be used to extend the real estate of the names if the alignment should be on both left and right, and vertical bars would do the same thing vertically.

This is kind of like the XPM graphics format, that uses characters to represent pixels of different colors. It does require everything on the dialog/frame to have unique names, which is a pretty innocuous requirement, really.

Stanford NLP

Huh. The Stanford NLP Parser, a Java library, is also available online via a Javascript API. Interesting. Very interesting...

NUPOS, a new part-of-speech system. A couple of useful blogs. None of this is available in Perl, sadly.