Make Your Own Programming Language

Nathan's University offers an online course.

I've signed up.

Project ThoughtStorms Goes Live

ThoughtStorms has been ported across to the Smallest Federated Wiki.

Of course, there are plenty of failures, missing pages, bits of markup that aren't handled correctly etc. But this is wiki, right? It's never perfect. It's always living and dying and composting. The problems will get flushed out, or worked-around, or become charming ruins over time.

That doesn't mean Project ThoughtStorms is over. It's barely even got started. There are more wikis to port. There's an SdiDesk converter to write. There's plenty of gardening that I am committing to doing.

And then there's the really exciting stuff ... ;-)

Project ThoughtStorms

As mentioned previously, I've been looking into Ward Cunningham's "Smallest Federated Wiki" concept. And I'm increasingly impressed.

So much so, that I've re-oriented a lot of my projects around it.

What do I mean? A decent follow-up to SdiDesk has been promised for an embarrassingly long time. Over the years I've struggled with exactly what it should be and how it should be implemented. Largely whether it should be a desktop application or something you access via the browser. The browser has always been the logical answer but, until recently, the network diagramming aspect of SdiDesk was not really an option in mainstream browsers. OTOH, desktop GUIs open a can of worms. Which OS? Which GUI framework? How do I write installers and distribute? (And, frankly, what is my, as a non-Mac owner / developer, attitude towards the iPad?)

In 2012 though, HTML5 and CoffeeScript have become extremely plausible options for the client. And the server can become a simple wrapper around a basic PageStore. That's an architecture I've been meaning to get down to write. But it's the architecture that already exists for the SFW.

So, great! By hooking onto that project, I get my basic server / PageStore / client architecture free.

Furthermore it's extensible via plugins. So I can embed special types of paragraph data and special renderers. That's exactly what I wanted to do with the new SdiDesk - instead of having *pages* that were network diagrams or grids, have these as individual components of pages. This is perfect. I can concentrate on what interests me - the special plugin types - and Ward's team can do the infrastructure. :-)

Not to mention, Ward and co. are doing amazing plugin wizardry already : hooking data-feeds from Arduinos, graphing it, bytebeats, calculators. It already has a lot of what looked nice about QEDWiki.

The multi-panel view surprised me initially, but it's really useful for refactoring. And that's going to help me considerably with wiki-composting.

Finally, the "federated" part of the Simplest Federated Wiki is the answer to a bunch of problems I didn't even know I had. Or, at least, didn't conceptualise well. How do I have a private wiki (like a local SdiDesk, where I like to draft things before they go public) AND a public wiki (like ThoughtStorms) and make it easy to move newly public stuff from one to the other? How do I balance the desire to have special project focused wikis (like the OPTIMAES one) with wanting to refer to that stuff from the main wiki? How do I balance contributing to my own wiki and contributing to other communities' wikis?

So, I'm sold. As Dave Winer likes to say, it's the second mover who makes the standard. And that's what I want to help with. There's enough overlap between the SFW and the things I've been wanting to do over the last few years that it makes sense for me to implement my ideas as plugins for the SFW, to port my wikis over to to it and to go around shouting about how wonderful it is. Because, actually, it is pretty damned wonderful.

So, Project ThoughtStorms is where I'm putting the code: so far, converters from the ThoughtStorms UseMod and the SdiDesk formatted pages, and plugins to render the markup. I'll be porting ThoughtStorms over to a SFW server soon. Then I'll be doing some serious refactoring and cleaning up the actual writing. Trashing a lot of the ephemeral junk and dead-links. TS has become a bit of a museum, which it shouldn't be. It should be a living, learning, and forgetting thing.

After that, I'll be sitting down to do some of the other things I've wanted to do in a wiki context but not had the platform to do justice to.  Now I think I have one.

Unicode

OK. I'm an idiot.

So here's today's BIG Unicode lesson; understand this and, maybe, half your troubles will evaporate.

Unicode is NOT a "code".

No. Unicode is a kind of platonic ideal of which everything else is an "encoding".

ASCII is an encoding. UTF-8 is an encoding. That weird character set you got with Portuguese accented letters is an encoding.

Hence the verb "encode" means to turn a Unicode string into a byte string.

And "decode" means to turn a byte string (say one imported from another application) back into the pure Unicode. 

I repeat. You DO NOT encode byte-strings into Unicode-strings. You decode them into Unicode. And then you re-encode them when you want to export them (as, say, XML or JSON).

read --> decode --> do stuff in your app --> encode --> write

Thanks ... that's all.

Updating node.js on Ubuntu

Node.js in the main Ubuntu repo is fairly out of date. Here's a useful page on installing the latest.

Thanks Yodi Aditya.

Smallest Federated Wiki

I can't believe I haven't looked more carefully at Ward Cunningham's Smallest Federated Wiki. I did glance at it before, but am now making my way through the videos. Lot's of absolutely perfectly pitched ideas working together.

HUD

Personally, I'm looking forward to the new Ubuntu interface : HUD. Looks to me a lot like Humanised Enso (which I was a big fan of when I used Windows regularly)

Three.js

Bloody hell! Three.js is cool. And CSG.

What can't you do in the browser these days?

Bret Victor's Code / Drawing IDE

Excellent video

I'll have more to say and think about this.

Wat

This is very funny.

A survey of bizarre behaviours of non-things in Javascript.

Rails Off The Rails

Seems like the same thing has happened with Ruby on Rails as happened with, say, Zope.

Giles does a pretty good analysis. The key point is that as frameworks mature they start supporting legacy users and applications who, in turn, have different requirements and values from those looking for a quick way to build new applications.

Permutations with Python Generators

Here's something neat.

I wanted to experiment creating different permutations of a collection of items. (In fact I'm working on some code for laying out shapes on a surface.)

Prototyping in Python to get my ideas straight I came up with this neat generator solution.

SpimeScript

These days, I'm thinking a lot about 3D printers, desktop manufacturing and software to create physical things.

Last year I did some art pieces using software to generate drawings for laser cutters and 3D printers, and I'm continuing along the same line. I want to move this stuff into the browser, and the combination of CoffeeScript and Raphael.js is turning out to be pretty good for this. (Did I mention I really, really like CoffeeScript?)

I also dabbled a bit with Prolog, wondering whether it can be used as a high-level description language for machines or other complex objects. The really interesting question is if you can use the built-in inference engine of Prolog to help with the design. (Aside, here's a silicon layout engine in Prolog) I haven't got very far with that yet, but I'm now considering how Prolog can be combined with or made to output OpenScad (or PyScad) code.

A couple of days ago Simon Wardley posted on his blog that he was searching for a SpimeScript :

So, I want to return to ... the formation of Spime Script. We're entering a phase where hardware will become increasingly as malleable as software which leads to a problem of choice - if I want to change the function of something, do I do this in software or hardware? The tendency today is obviously towards software because its more malleable but the future is never the past. However this creates a problem of skill - will I need to become proficient in both software and CAD / electronic design?

In reality both CAD and whatever software language you use, compile down to instruction sets and the function of the device is the interaction of these instruction sets - one which is substantiated physically and the other which is substantiated digitally.

Turning this on its head then why not write the function of what you want, the function of the device? Compilers can therefore undertake the complex decision trees (which is what they're good at) required to determine what element of that function is encoded as physical and what element is digital.

A future language is needed, something whereby the output is both physical and digital and I describe merely the function of what I'm after.

That's a really exciting vision.

Now, here's what I think is really important for a SpimeScript.

It should learn from HTML / CSS.

While HTML / CSS is a pain in many ways, there's a very interesting insight in it about design. That design comes in layers. It's partly about the separation of logical structure and visual style. It's partly about the cumulative effect of the Cascade in Cascading Style Sheets. It's partly about the fact that the browser has reasonable defaults for the geometric properties of logical structure. (Today, those defaults look rather out-of-date but there would be little to stop a browser manufacturer making their defaults look more like Readability or Twitter Bootstrap.)

So here's the main feature request for a SpimeScript. It should be possible to define the logical structure of, say, a machine and have some layout-engine give it plausible default geometric properties. But it should also be possible for designers to layer optional design hints on top of that layout in the form of extra constraints and have the engine deal with fitting them together.

As with the silicon design case, there must be some prior art here, but I'm not quite sure where it is. Electronic Design Automation maybe.

SqueekNOS

SqueekNOS is a project to create an operating-systemless Smalltalk. Ie. one where the Smalltalk machine replaces most of the operating system (apart from a small kernel I guess).

The nice thing about this : everything is inspectable / hackable. All the way down.

CoffeeScript

Just a note. I am really, really liking CoffeeScript now.

It's reminding me both of freedom that Python gave me when I first turned to it after Java. And bit of my experience with Erlang. ( If only it had Erlang's Actor model and pattern matching arguments ... )

The other good effect of this, CoffeeScript is making me more comfortable with investing my time writing serious logic on the browser-side. Which is where it should be, given the requirements of modern applications and that the browser is becoming the default GUI. 

Programming in Go

Very interesting video about how to program with Go language.

Horizontal Applications And Popular Data Structures

Joel Spolsky : "The great horizontal killer applications are actually just fancy data structures."

WaveFlavours

So, slight Christmas / New Year's diversion from my main projects - I've been writing a wave-table synth in the last few days. Code (C++ using Maximilian) is here.

The main thing I'm doing is to have two wave-tables for a voice, and then slowly swap sample points between them to get a long-term evolution of the sound. I want to get a rich and ever changing timbre cheaply ie. without having to use filters or expensive FFT.

Chicago Boss

Very nice looking Erlang web-framework.

UI Stencils

Clever idea. Stencils for UI designers.

Guess you can make your own with a laser-cutter.