On the weekend just past, I attended the annual Kingdom Code Build event/hackathon.

As part of the event, I brought a project idea and invited others to contribute. Thanks to Jon, Matin, and Emily for your contributions.

The idea was to create an IDE extension that would support a new DSL (Domain Specific Language) (based on the “Let there be…” statements in Genesis 1) and could generate code to integrate within a code base.
I came knowing how to build this with/for C# in Visual Studio and was open to expanding to other languages and IDEs based on the participation of others.

The idea was that you could type statements in a file with a new extension, and this would generate code in a separate file.

So, for example, you could type let there be light and it would generate a new class called light.

There were a few goals of this project:

  1. Have fun building a cool code generator. (Yes, this is my idea of fun.)
  2. See if this could be useful. (You never know!)
  3. See how it changes thoughts and attitudes towards code and/or scripture when used. (This is a longer-term goal and is dependent upon the integration being created.)

The first evening was initially spent explaining the idea in a bit more detail to interested people. Then we set about defining what the “language” could look like.

By the time we stopped for the evening, we had eight statements that would be the basic structure of the language and a plan to implement it the next day.

Once we’d called it a day in the venue, I went back to my hotel room, typed up the notes we had, and added examples of input and the C# that should produce.
I also added some tests, with only enough supporting code, to verify when we’d enabled what was specified in the grammar doc.

When a hackathon is running over a short period of time, it can be tempting to start coding as quickly as possible, but past experience has taught me the importance of planning and preparation.
This is what the first day was all about.

The second day started early. I was keen to get those tests turning from red to green.

By mid-morning, fast progress was being made, and we started to look at expansion goals.
As one of the team didn’t know C# but did know Python, we looked at adding support for this.

Adding support for another language started with determining the appropriate output for the different supported inputs of our DSL.
This was done in parallel with the implementation of C# support.

When we stopped for lunch, the C# implementation was done. Hooray, for structured working practices, TDD, and automated build checks.

After lunch, we started looking at Python integration with Visual Studio and hit a bit of a blocker. The functionality we used for the C# integration isn’t supported within Python projects. :(

This was a bit of a downer, so time was spent finalizing the Python output for the grammar while we considered other options.

The extension was published to the Visual Studio Marketplace so that others can try it out and see the progress.

Around this time, Tim and Peter came by to see how we were getting on. When we showed them what we had done, they wondered what AI could do with this.
As a way to try it out, they passed our grammar / language definition file to GPT3 to see what it would make of it.

After processing a version of the document, they gave it some input:

> let there be an Egg
> the Egg must have a Yolk
> let the Egg Hatch into a Bird
> let the Bird Fly

and it produced the following:

partial class Egg
{
    public Egg(string yolk)
    {
        Yolk = yolk;
    }

    public string Yolk { get; init; }

    partial void Hatch(Bird bird) {
        Console.WriteLine("Hatching a " + bird);
    }
}

partial class Bird
{
    partial void Fly() {
        Console.WriteLine("Flying");
    }
}

This is surprisingly close to what the extension we’d written would create.

After this fun distraction, and with about 2 hours to go, we lamented that if we’d known about the Python limitation initially, we could have created a website to demonstrate how the input could be used to produce code in any supported language.

While some of the team saw this as an insurmountable problem, I thought it was worth exploring anyway.

An hour later, I’d written my first Blazor (client-side) web app and had a dev-ops pipe-line set up that deployed it to a public website.

Then, just to prove we can, I started to add colorization to the new file within Visual Studio. We only got as far as a very basic proof of support, but there was something there for the demo.

We also looked at colorizing the output on the website, but time (and a lack of appropriate experience) meant this will have to be left for another day.

Our demo to the room at the end of the day was poorly planned. (We should have spent more time preparing for this.) We were able to show off the technical side of what we’d done but ran out of time to focus on the most important part.
The most important part of the whole project was to explore how seeing code and scripture (or something a bit like it) in new and overlapping ways changes how we think about either/both. My personal experience with using this was a feeling of awe at the complexity and wonder of creation when the extension started producing output. I’d used words (text) to produce some code in a file. How much more was God able to do with a similar number of words at the creation of the universe.

But what now?

As a technical project, it still needs a bit of tidying to make it easily usable.
Hopefully, I’ll have time to document and implement those issues over the next few weeks.

Once some more features and functionality have been ironed out, more people will be able to try it out and give feedback.

It will be exciting to hear how and if it does change any thoughts, feelings, attitudes, or opinions to either code or scripture.
Even if no one else ever tries it out, I’m excited to add it to some of my projects and use it there. What impact will it have on my thoughts, etc.?

What did I learn as a project lead for a hackathon?

While I’ve attended and participated in many hackathons in the past, I’ve never done so as the team lead. Doing so allowed me to identify a few things I’d do differently next time.

  • Conceptually this was a challenging project to explain. I didn’t want to start with something that was all my idea and so prevented other people from contributing to the concept. In practice, it would have been easier to have something (even if a trivial mockup) to help explain the concept. It would also probably have been better to have written up my initial ideas for what the DSL might look like and discussed possible changes and improvements rather than starting from scratch.
  • Setting up machines can be a tricky thing. Much time was lost by people wishing to contribute to setting up an appropriate version of Visual Studio for development. If we could have started with a way for more people to contribute without such strict software requirements it would have allowed more people to contribute more easily.
  • The website turned out to be a great way of allowing more people to see and try out what we’d done. Having this as an idea from the start would have allowed other to contribute. It might also have allowed a designer to get involved and make it look (& work?) better.

Role on next year. I’m already starting to formulate ideas for possible projects…

Reference in Church Times.