Been working quite a lot on Project ThoughtStorms, the new Python / Bottle based wiki engine behind ThoughtStorms in the last few days.

I can’t believe that I’ve spent 15 years building a wiki without creating my own software.

That error is going to be rectified from now on.

Sure, most of what I’m doing is adding the kind of functionality that most wikis already have : RecentChanges, Search, Sister Sites etc. But it’s pretty quick to write. And as I bring these functions back, ThoughtStorms becomes more subtle and alive.

The truth is that ThoughtStorms’ content is woefully outdated. There are a tonne of broken links, and news stories that were current in 2005, but equivalent stories between about 2008 and 2016 are no-where.

It needs a jolly good clean up / clean out / refactoring. But I’m starting to have some ideas about how to write some more innovative custom code to help with that.

It’s very much work in progress. And there’s still plenty that’s half-baked and unfinished.

But I’m starting to feel that ThoughtStorms is coming back to life.

Posted in Me.

A quick update (for me, as much as anyone else) of where I’m at and what I’m currently thinking about … March 2017:

ClojureScript and Reagent

I want to get up to speed on this as my standard way of writing browser based software. React seems to have conquered the world as browser based, reactive framework. And with React Native it’s also come to mobiles. It seems that the ClojureScript / React Native story is becoming compelling too.

So, yes, this is mainly how I want to do GUIs moving forward. I’m doing some experiments. Expect, eventually, Patterning and some of my other projects to move to this.

WebAudio

A friend of mine has sold me on the idea of going back to audio in the web-browser. Which is obviously a great way to make little musical apps that are easy to share with people. He’s not so keen on ClojureScript but does like Javascript in a functional style with Redux and Immutable.js so we’ll probably be using them on a collaboration. I’m considering porting versions of Gbloink! and Zewp! to it. Along with more of my current Processing based “ArtToys” Library.

Lisps on Android

It may be that ClojureScript + ReactNative is the right way to go. But I’m also looking at Clojure on Android. And Racket on Android.

Reading online it seems that Clojure on Android has been improving, but is maybe not as efficient as ClojureScript with ReactNative. And, also obliges you to deal more directly with the Android Java frameworks. Maybe something that’s useful for larger, more framework intense, applications.

I was originally tempted by LambdaNative, a Scheme for Android app. development. But it now looks like Racket’s Android story has improved considerably and is quite similar. Especially sharing the focus on using OpenGL for visuals. Racket on Android basically compiles to C and uses the NDK, which might be a faff to get working, but might also be more efficient. One to have in the arsenal.

Also, of course, Racket on Android would let me keep a common Racket code-base for both the command-line and an Android version of Mind Traffic Control.

Rosette

I’m kind of intrigued by Rosette and the idea of “solver aided” programming. And being a Racket DSL is a bonus. I want to get my head around this, this year.

Music Languages

Last year. I did a lot on Sonic-Pi. This year I thought I’d go back and take another look at Overtone. Which is, in many ways, the predecessor of Sonic-Pi done as a Clojure library.

It’s not quite as simple as Sonic Pi with its integrated development environment but Clojure is
more powerful than Ruby.

While I still think that Faust looks cool. I’ve also been tempted by the lower-level simplicity of CSOUND … wondering if it might make sense to write a CSOUND generator in Clojure. I’m slightly pulled backwards and forwards on this question. Plus, Overtone provides its own synth-design functions.

Project ThoughtStorms

So, I haven’t trumpeted it here. But last year I moved away from the Smallest Federated Wiki for ThoughtStorms. See ThoughtStorms:LeavingTheSFW for the full story.

Here I’ll just note … I’m very happy with the decision, and I have lots of ideas for how to develop my currently very minimal wiki engine to do more of the things I want to do. In many ways, this is like the MTC reboot of last year.

Small Boards

I’ve become a bit of a collector of small hobbyist / maker boards, from Arduino to last year’s CHIP. I’ve just got a couple of BBC Micro:Bits which are great fun. These are a really smart and original idea in what’s becoming a crowded and competitive market. The computing power is pretty minimal. But what gives them an edge is that they’re packed with sensors. And come with their own primitive display.

I’m looking forward to playing with and giving these a good run for their money.

Interestingly they run MicroPython. Something I hadn’t really looked at before.

Python

All of which means, despite last year’s thinking, that I’m actually renewing my relationship with Python. I really thought I was deprecating it in favour of Javascript. This year, that seems fairly unlikely. Python just is nicer than Javascript in so many ways. It’s the back-end of my new wiki, which I’m planning to extend. It’s the language of the Microbit and potentially useful on other boards. It’s getting ported to the GoLang infrastructure and perhaps has a great future in front of it there. Meanwhile, even a tiny serverside JS program with node.js seems to install a million dependencies.

So Python is definitely here to stay in my near future.

QaSaC

A rather crazy art-project I dabbled with last year spawned an interesting toy / esolang : QaSaC. This is little experimental “concatenative” language like Forth and Joy cross-pollinated with a visual data-flow language like Pure Data.

I think there’s some potential here. And I’ve really enjoyed the concatenative / stack-based thinking and elegance of this kind of programming. So I am working (albeit slowly and interspersed with everything else) on getting an actual viable version of this out soon.

OK. I think that’s a pretty comprehensive list of my obsessions for 2017. Let’s see how much progress I make with them all. This year, I promise, I’ll be trying to release, and blog, more often about them.

Posted in Me.

Google are making a Python to Go cross compiler

The idea here is that Google have a lot of Python to run, but Python’s Virtual Machines (especially with the Global Interpreter Lock) aren’t all that good for high-performance parallelism.

OTOH built Go! and the Go target machine for this. So they want to make a drop-in replacement that lets them run existing Python code on this infrastructure.

This is good news for Python. I wonder how long it will take to become the GAE python-hosting infrastructure. Perhaps this is Python’s answer to Elixir.

Posted in Uncategorised.

A comment I made over on The End of Dynamic Languages

The problem with the static / dynamic debate is that the problems / costs appear in different places.

In static languages, the compiler is a gatekeeper. Code that gets past the gatekeeper is almost certainly less buggy than code that doesn’t get past the gatekeeper. So if you count bugs in production code, you’ll find fewer in statically typed languages.

But in static languages less code makes it past the compiler in the first place. Anecdotally, I’ve abandoned more “let’s just try this to see if its useful” experiments in Haskell where I fought the compiler and lost, than in Clojure, where the compiler is more lenient. (Which has the knock on effect of my trying fewer experiments in Haskell in the first place, and writing more Clojure overall.)

Static typing ensures that certain code runs correctly 100% of the time, or not at all.

But sometimes it’s acceptable for code to run 90% of the time, and to have a secondary system compensate for the 10% when it fails. There might even be cases where 90% failure and 10% success can still be useful. But only dynamic languages give you access to this space of “half-programs” that “work ok, most of the time”. Static languages lock you out of it entirely. They oblige you to deal correctly with all the edge cases.

Now that’s very good, you’ve dealt with the edge cases. But what if there’s an edge case that turns up extremely rarely, but costs three months of programmer time to fix. In a nuclear power station, that’s crucial. On a bog-standard commercial web-site, that’s something that can safely be put off until next year or the year after. But a static language won’t allow you that flexibility.

The costs of static and dynamic languages turn up in different places. Which is why empirical comparisons are still hard.

Posted in Uncategorised.

Ian Bicking’s post on Conway’s Corollary is a must-read thought on isomorphisms between the organization and product structures.

What, asks Bicking, if we don’t fight this, but embrace it. Organizational structures are allegedly for our benefit. Why not allow them to shape product? Or when this is inappropriate why not recognize that the two MUST be aligned and if product can’t follow organization, we should refactor organization to reflect and support product.

Posted in Uncategorised.

Im sure my answer / comment on What is Gradle in Android Studio? will get downvoted into oblivion with short-shrift fairly soon. (Maybe deservedly).

But I’ll make it here :

[quote]

At the risk of being discursive I think behind this is the question of why the Android Studio / Gradle experience is so bad.

Typical Clojure experience :

* download project with dependencies listed in project.clj.
* Leiningen gets the dependencies thanks to Clojars and Maven.
* Project compiles.

Typical Android Studio / Gradle experience :

* “Import my Eclipse project”.
* OK project imported.
* Gradle is doing it’s thang … wait … wait … wait … Gradle has finished.
* Compile … can’t compile because I don’t know what an X is / can’t find Y library.

I’m not sure this is Gradle’s fault exactly. But the “import from Eclipse project” seems pretty flaky. For all of Gradle’s alleged sophistication and the virtues of a build-system, Android Studio just doesn’t seem to import the build dependencies or build-process from Eclipse very well.

It doesn’t tell you when it’s failed to import a complete dependency graph. The Android Studio gives no useful help or tips as to how to solve the problem. It doesn’t tell you where you can manually look in the Eclipse folders. It doesn’t tell you which library seems to be missing. Or help you search Maven etc. for them.

In 2016 things like Leiningen / Clojars, or node’s npm, or Python’s pip, or the Debian apkg (and I’m sure many similar package managers for other languages and systems) all work beautifully … missing dependencies are thing of the past.

Except with Android. Android Studio is now the only place where I still seem to experience missing-dependency hell.

I’m inclined to say this is Google’s fault. They broke the Android ecosystem (and thousands of existing Android projects / online tutorials) when they cavalierly decided to shift from Eclipse to Android Studio / Gradle without producing a robust conversion process. People whose projects work in Eclipse aren’t adapting them to AS (presumably because it’s a pain for them). And people trying to use those projects in AS are hitting the same issues.

And anyway, if Gradle is this super-powerful build system, why am I still managing a whole lot of other dependencies in the sdk manager? Why can’t a project that needs, say, the ndk specify this in its Gradle file so that it gets automatically installed and built-against when needed? Why is NDK special? Similarly for target platforms? Why am I installing them explicitly in the IDE rather than just checking my project against them and having this all sorted for me behind the scenes?

[/quote]

Posted in Uncategorised.

qzhuyan responds to me tweeting Emacs on PocketCHIP.

Which is, er, very true. And wonderful.

But this haunts me continuously, as I explore the Mind Traffic Geometry of tools that support me tracking tasks and outlining ideas.

Will I one day end up simply falling into Emacs Org Mode? Isn’t that basically everything I really want?

Am I wasting my time with quixotic effort of writing my own software for this stuff when I could be writing something newer and more important?

Another thing that’s pushing me to think about this : this week I’ve been playing with Faust. A wonderful language for writing signal processing networks (ie. synthesizers, audio FX etc.) that compiles to multiple back-ends … including PureData, Supercollider, VST plugins and stand-alone programs.

It’s basically where I imagined Gates of Dawn eventually going.

But rather than a Python library, its a very nice “little-language”, with great operators for describing composition of data-flow blocks. It’s well developed and supported. I’m trying it out for writing small synths / FX units I can run on small boards like CHIP and Raspberry Pi.

I can see myself doing a lot with this. But it’s basically going to kill Gates of Dawn. Maybe there’s room for a Python library for those who don’t want to learn Faust. But for me, Faust is looking extremely viable.

So … another wasted project?

Perhaps I need to look at this positively. I’m not old. But I’m not as young as I used to be. I don’t have so many projects left ahead that I can afford to squander them. Perhaps its time to pivot. Time for a cull. A “spring-clean”. To remove some more cruft projects that occupy too much of my mind, but are actually just weak “me-too” versions of existing things that I would use perfectly happily if I made the effort to learn them. Enough with the Not Invented Here syndrome.

I’m not saying that OWL or MTC are going anywhere yet. I use them, and they work for me. And they are DIFFERENT from OrgMode, or todo.txt or any similar thing out there. They are what I want.

But I need to embrace this change. There are so many exciting NEW opportunities, there’s no point getting hung up on the old stuff.

Dawn is over. For me it’s 2PM. And there’s plenty of work to be done.

Posted in Uncategorised.