A burst of development energy in a number of directions recently.

And things are starting to self-organize towards the new ecosystem.

Today’s exciting news : OWL makes a very nice desktop app, thanks to Electron.

Here’s the github repo.

I’ll be doing more testing, compiling, packaging this shortly. So that even non-geeks can play with it. But it seems to work fine.

To be honest, the few times I’ve installed OWL on non-geek friends’ machines, the “run a server and look at OWL in the browser” part has confused / put people off. Now things are VERY much simpler.

This is also going to give me some momentum to add a couple of extra features / ideas I’ve been thinking about over the last couple of years.

In the short term … this desktop repo is likely to be where I develop the next round of functionality. Though I’ll be porting these new features back to the Android and web-based versions.

Main issues in my mind at the moment : I’ve dropped the Python based server for this. We’re now purely Coffee / Javascript. That feels cleaner and more convenient. Will I now try do the same for the web version. It makes sense. But straight node? Express? Meteor?

What’s simplest and leads to least repetition of code?

OK. Consider me won over.

Lisp is great to work with. The things that grabbed me about FP in Erlang and Haskell (pattern-matching arguments, partial application, lazy evaluation) are all here.

My code is as concise as Erlang and damned nearly as concise as Haskell (I think the line count is similar though the number of characters per line is about twice as high)

Although I respect Haskell’s type system, Clojure’s dynamic typing holds me up less. I *am*, admittedly, hitting more problems that a type system would have picked up. (Far more than I typically hit in Python) but I think as I get more used to the language this will go down.

I’m not being particularly demanding in terms of libraries. (Quil is almost all the libraries I need at the moment.) But I’m finding that there are all these handy things like spit which make me smile. (Remember what this was like in Java?)

Things that would still be a bit fiddly in Python / CoffeeScript continue to turn out to be easier than I imagined they would be when I implement them in Lisp. That’s partly because I default to approaching them as “how do I write a small lambda that can then map across this list” and mostly, by the time I wrote that function, all I have to do is … er … map it across the list.

Lisp is extra-ordinarily compressible. I keep finding ways to refactor and fold up things I did earlier to make them shorter and shorter. And the more functionality I add to my program the more compressed it seems to get.

I am grinning to myself at the thought that my code might be compilable to both Android and into Javascript. I haven’t tried either yet, but if I manage it then Clojure is now my new favourite language.

CoffeeScript isn’t at all bad, but if ClojureScript works out, then I’ll probably start to move aggressively to use it as my default in-browser language. (And yes, I guess that may mean rewriting OWL in it. OWL is still short enough that I think I could sprint it in a couple of days.)

Similarly, if I can compile Clojure libraries that can be called from Java projects then you’ll start to see me more productive on Android. (Beyond OWLdroid I have a couple of other bits and pieces of apps. written, but not taken them to completion. If Clojure slots painlessly into the workflow, it will be a lot more tempting to dive back in.)

So … yeah … Clojure rocks!

Question : Hey Phil, do you actually do any programming these days?

Answer : Yes. Quite a lot at the moment. Though it’s a bit all over the shop.

I’m dipping a toe into Android programming. (And, hmmm … Java …. I thought I’d got over my Java hangups by doing a lot of Processing, but it turns out that Processing just hides the crap and Android doesn’t. Why hasn’t Google picked up on Processing to turn it into a first-class Android art / game app. development environment?)

I’m mainly writing CoffeeScript. Some stuff related to my ongoing 3D modelling / desktop manufacturing projects. (Did I forget to mention those? I’m sure there’s a half-written blogpost somewhere.) Some work towards an SdiDesk-derived network diagramming plugin for Smallest Federated Wiki (held up by silly problems). Some other bits and pieces. I’ve recently been playing with Jison, which rocks. And I’m about to investigate angular.js which looks pretty good.

There’s a project for small stand-alone web-servers that I’ll talk about more if / when it takes off.

I’ve been trying to compile example VST instruments  (C++) for some of my work with the Brasilia Laptop Orchestra, but it’s driving me crazy. (I may go back to Pure Data which can be embedded in a VST.)

A bit of PHP, just simple small web-services.

I’m going to be teaching an Arduino course soon. So I’ll be writing a bit of C and I want to try Occam-.

I’m still writing Python too. Mainly for short file transformation scripts or to prototype algorithms that later get translated into CoffeeScript.

Some of this stuff is headed for GitHub soon.

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.

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. 

I’ve been working on a project based on some of my recent artistic works. I thought I’d do it using a Processing sketch embedded in a web-page. It’s not that I was particularly happy with Java applets (in 2011!) but I figured I’d make use of the Processing code I already had.

After a whole lot of faffing around trying to get the applet talking to my server, I’m realising that this is really NOT going to fly for a whole bunch of reasons. I wasn’t really seeing Java as my long-term future anyway, but I’ve realised that it isn’t even going to be the quick, dirty but workable prototype that I’d hoped. So, if I have to make a break, I might as well do it now and quickly. And look to the future rather than the past. So I’ve made a decision to rewrite with CoffeeScript and Raphael.js. (I’m generating SVG designs anyway, so Raphael is ideal.)

After a spending a couple of hours today, that’s feeling like good decision. There’s still the hassle of having to convert a lot of code, and it’s a bit of a fiddle going backwards and forwards between the editor, the command-line compiler and the browser. But CoffeeScript feels like a good language. Obviously meaningful whitespace indentation is comfortable for a Pythonista like me, and I’m getting used to the Rubyisms without too much pain.

Not much in the way of debugging information, which hasn’t bitten me yet, but might. Still, I’m positive.