October 19, 2014

Eve

If the previous post piqued your interest, then there is now more to be found over at incidentalcomplexity.com. What was initially called Aurora has been renamed to Eve. Looking forward to playing with this one!

September 10, 2014

Projectional Editing

I have written on this blog before about my attempts at building a structural editor which turns the parsing equation upside down. Today I learned there is a name for what I have been trying to create: Projectional Editing. The top hit when googling that term comes from Martin Fowler; which is nice as I based some of my work on his articles on language workbenches.

I stumbled on this terminology through a presentation on InfoQ titled "The Art of Building Tools–A Language Engineering Perspective". It's showing examples of this technique in different contexts. Some pretty low-level programmer stuff, but also in the realm of requirements specification. Very cool.

A related presentation, also on InfoQ, is "Enhancing Notational Flexibility and Usability of Projectional Editors". This is showing off JetBrain's MPS, which is a language engineering workbench used as the backbone by the first presentation. I have stumbled on MPS before some years ago, but I think I may have to take a second look at it.

More interesting still is Aurora, a project being worked on by Chris Granger (of Light Table fame), which I'm desperate to take a closer look at. I'm not sure if Aurora is doing projectional editing, though it sure sounds like it. That and some other pretty crazy stuff (programming in a database !?).

I don't know about you guys and galls, but I'm looking forward to see where all this is going.

August 11, 2014

Hardened Quines are hard

I have mentioned Quines here before as pieces of code which bend the mind. Well, the following Quine bends it a bit further: this one is "radiation hardened".

To refresh everyone's memory, a Quine is a piece of code which, when evaluated, yields its own source code. Well, the linked Quine is one which still functions if you delete any one character!

Who does it better ?

April 28, 2014

core.logic-o

While exploring Clojure's core.logic a bit, I stumbled on a set of just amazing videos. Clojure's core.logic is based on an implementation of miniKanren. If you don't know what that is, don't worry, I did not either. But it is really simple: MiniKanren is a DSL for logic programming based on three logical operators (==, fresh and conde) and one inference operator (run). If you take that you can do some really cool stuff. What exactly ? Well, that's where these videos come in:
I'm purposefully not saying what exactly is being shown. Just pick any one and you'll probably catch the bug. (Or maybe that's just me. :-))

April 10, 2014

Minimalist Parser Combinators

Now over at my github account: a minimalist implementation of parser combinators. Parser combinators provide an easy yet powerful way of implementing parsers, without the need of understanding compiler theory or formal grammars (though it can't hurt, of course). They also form the basis for my Koopa project, precisely because you can easily extend this technique to fit your needs.

This minimalist implementation may be slightly too minimalist, though. It only tells you whether something can be parsed or not. There is no way to extract anything useful while doing so —yet.

April 01, 2014

Minimalist Entity/Component System

I just uploaded a new addition to the minimalist code series. This time it's a minimalist version of an Entity/Component System. An ECS is a bit of a specialized architecture for modeling complex systems of dynamic objects. The origins for such systems come from the gaming world, but it has made its way into very different kinds of applications (the LightTable IDE is a great example here). If you're interested, the Entity Systems Wiki is a great resource for going deeper.

Javascript makes it really easy to set up such a system. In fact, the example I added is way more complex and took much longer to write than the actual engine itself. I was debating with myself whether or not to go for a more fluent API than what I provided now, but I was somewhat worried that I would be explaining the fluent part more than the actual ECS principles. If anyone is still interested in a more fluent version, though, let me know and I'll spend some time on that.

March 25, 2014

Make Install: Polycode

I somehow stumbled on Polycode, which is an interesting "free open-source framework for creating crossplatform games and interactive applications". It reminds me a bit of Processing, except that you use C++ or Lua for creating applications.

In addition to supporting 2D and 3D applications, it features a large selection of asset loaders (including Blender, of course) and has a Unity-like IDE. Runs on all major platforms, though there are no ready-to-download executables yet. You'll have to build everything from source to get started.

As an added bonus, there is a blog linked to the polycode. Always nice to see developers writing about their pet project.

March 15, 2014

Minimalist Dataflow Engine

I'm really enjoying these minimalist literate programming exercises, so here is another: a minimalist dataflow engine named "dfntly". It is very loosely inspired by the excellent Knockout library, but obviously has much fewer features. I would like to add some support for observable arrays, for example, and for asynchronous calculations where the dataflow engine only calculates further when the reply comes in. But that's something for another day.

In the meantime, if you feel like it, give it a go!

March 10, 2014

On "The Next 700 Asychronous Programming Models"

I was watching this talk by Philipp Haller on InfoQ on "how to make Rx programming more natural and intuitive by generalizing Scala's Async". The cliffnotes are this: unify the two by implementing async through observables. Clever.

Now, while the result was interersting I got a bit "stuck" thinking on this example from the presentation:

val futureDOY: Future[Response] =
  WS.url("http://api.day-of-year/today").get
val futureDaysLeft: Future[Response] =
  WS.url("http://api.days-left/today").get

val respFut = async {
  val dayOfYear = await(futureDOY).body
  val daysLeft  = await(futureDaysLeft).body
  Ok("" + dayOfYear + ": " + daysLeft + " days left!")
}

What it's trying to do is retrieve data from two remote services and compose the results in some way (don't worry about what it's really trying to achieve; it's one of those hypothetical examples which academics are really good at; I know, I used to be one). Now, as you may have noticed the services are consumed in an asynchronous way. That's where the need for futures and explicit waits for their results comes in.

Having been playing a bit with futures and their composition for the minimalist asynchronous process virtual machine I understand the mind bending it can take to get this right in more realistic examples. As a programmer you constantly have to be aware of what methods return results which are immediately available (i.e. are synchronous) and which ones are not. Because if you get it wrong the results will be unexpected and probably quite annoying to debug.

So here comes my question: rather than trying to come up with lots of creative ways of composing asynchronous behaviours and avoiding callback hell, why not stick to the principle of least surprise and make all asynchronous calls act as synchronous ones by default ? What is really stopping the above code from being as simple as:

val dayOfYear = WS.url("http://api.day-of-year/today").get.body
val daysLeft  = WS.url("http://api.days-left/today").body
val respFut = Ok("" + dayOfYear + ": " + daysLeft + " days left!")

A programmer's default mindset, I would argue, is that code is synchronous. By making that the default the obvious solution becomes a correct one.

Asynchronous execution, if wanted, can still be supported by explicitly requesting it. So another way to write the example could be:

val futureDOY: Future[Response] =
  async { WS.url("http://api.day-of-year/today").get }
val futureDaysLeft: Future[Response] =
  async { WS.url("http://api.days-left/today").get }

val respFut = async {
  val dayOfYear = futureDOY.body
  val daysLeft  = futureDaysLeft.body
  Ok("" + dayOfYear + ": " + daysLeft + " days left!")
}

While not as concise as the earlier rewrite at least it removes all doubt about which parts of the code don't want to wait for specific results.

Anyway, just wanted to get this off my mind. If you like, or think I'm just blowing smoke, let me know.

February 22, 2014

Minimalist Asynchronous PVM

So adding support for asynchronous tasks turned out not to be so difficult. With a little help of Q's promises and support for composing them all it took was a minor rewrite of the main tick function...

Anyway, this version of the minimalist PVM can be found here, together with an example which queries the OpenWeatherMap API.

Note that in the process of doing this I also added some minor tweaks to the basic version of the PVM; the most useful of which is the ability to define a starting runtime state for the process upon activation. I extended the examples there as well to showcase this.

February 18, 2014

Minimalist Literate Programming

As a quick follow-up to the minimalist PVM you can now find a very simple literate programming tool over at my github. It's a single Perl script which converts source code into a Markdown document. It does this by extracting the text from the comments in the source code, and wrapping the code itself in code blocks. Want an example of the output ? The README.md for the tool is exactly that. (Self-documenting code FTW!)

February 15, 2014

Minimalist Process Virtual Machine

Over at my github account (see, I do have one) I just added a minimalist implementation of a Process Virtual Machine (PVM).

Wait, what ?

Let's start with what a PVM is. You can find a thorough description of it here, but in brief it is an engine which can drive automated business processes and workflows. It actually forms the core of JBPM and Activiti. (If you really feel like geeking out on workflow engines you should definitely head over to Joram Barrez's blog, which has all sorts of Activiti craziness in it.)

I really wanted to figure out what makes such an engine tick, and while I can look at the source code for JBPM and Activiti they were never meant as an educational example. These engines have real work to do, and so come with usual amount of hardening and boilerplating. Rather than deep-diving through all that I wanted to see what a minimalist implementation could look like.

When it comes to minimalist implementations a lot depends on your choice of language. Ideally you want something which is really flexible without imposing a lot of structure. Prototype-based languages are a great fit and, as it so happens, Javascript is a popular example of one.

So that's where I went. I've got a minimalist PVM capable of running in a Node.js environment. As you'll see there's very little code to it; and I actually spent most of the time getting everything into the form of a literate program.

Because it is very minimalist there are certain features it does not (yet) have. The big ones are wait states (e.g. for human interaction), asynchronous tasks (e.g. for doing IO or REST calls), and persistence. In a future version I'll see if I can add those in a minimalist way as well, but for now this will do to satisfy my curiousity.

If you like, let me know; and feel free to experiment further.