Topic: Nim

I started making Niffler a while back (the old repo is still up at gokr/niffler.old) and I wrote it purely in Nim as a more classic monolithic TUI coding harness. It was a first attempt and it never reached maturity or a UX sophisticated enough to be “nice to use”.

A while back I wanted to explore game development, classic 2D games because I can’t waste too much of my life in the rabbit hole of 3D. Me and a friend were avid C64 hackers back in the 80s and I haven’t tried to make any games ever since. First I looked at available paths using Dart, like Flame for example. But I wanted to target low end very cheap hardware, be highly performant with good physics and be able to handle lots of players. Flame might have managed that, but it was too unproven.

Work on Spry continues… in small spurts. :) One thing that I have pushed ahead of me for far too long is error handling. People interested in Spry have been asking about it and yes, I decided to start getting a handle on it.

After a period of slower progress I got reignited regarding Spry. So far I have written a lot of articles about Spry, and during this time things have evolved and changed.

In the eCraft2Learn project which Evothings is participating in we were looking at various ways Nim is an awesome programming language and this article is a whirlwind-copy-paste-into-your-terminal-as-you-read-thing to show how you install Nim, write a small program, compile it and package it in a very short time.

Nim is an awesome programming language and this article is a whirlwind-copy-paste-into-your-terminal-as-you-read-thing to show how you install Nim, write a small program, compile it and package it in a very short time.

Spry is evolving quite nicely during my night hours. Focusing on performance is however still premature, but I do want to verify that I am not barking up the wrong tree, like … in the wrong forest even. So I make trivial benchmarks from time to time, just to see and learn.

When writing Spry I am so far mainly ignoring performance. The general execution of Spry code will be a regular interpreter (although stackless I hope) and not a JIT. But that doesn’t prevent us from playing around and learning something!

I now work as the Team Lead at Evothings and our open source product is a Workbench for creating mobile HTML5 applications focused on IoT, by editing and running them live on the mobile device inside our spiced up Cordova based “Evothings Viewer”.

This article describes some core parts of the current implementation of the Ni (now known as Spry) language. It’s not a tutorial, introduction or manual. It’s in fact kinda incoherent - but so is Ni :)