As discussed in the previous article I want Spry to have a trivially accessible persistence mechanism enabling something similar to the Smalltalk image model, but based on a database. The memory organisation in Spry is basically nested Maps. After dwelling a bit on the inevitable hard question about modules and namespaces I have decided on a design that I hope will turn out simple and reasonably powerful!

Smalltalk has a Dictionary holding all the globals forming “the roots” of the object memory. In Smalltalk this Dictionary is also itself a global variable accessible as Smalltalk, in other words Smalltalk == (Smalltalk at: #Smalltalk). The primary use of Smalltalk is to hold all classes by name, so they are all reachable as globals. Obviously Smalltalk can also hold any kind of object (not just classes) as a global.

Spry also has such a top level Dictionary, but in Spry we call a Dictionary a Map to be a little bit more aligned in terminology with other languages (and it’s shorter). This top level Map is the root Map and it is accessible via the word root. In Spry the root word is actually bound to a primitive function returning this Map, so in Spry we also have root == (root at: 'root).

Ok, so Spry has a Map of globals and one way of using Spry is simply by populating root with words bound to functions making these functions globally accessible, it’s how I have done it so far. Yeah, yeah, I know, but for smaller systems it probably works just fine!

But…

In developing Spry - renamed from Ni - I am getting closer to the Really Fun Stuff.

As a Smalltalker I dream “bigger” than just managing source code as text in files…

Smalltalk uses the “image model” in which the system is alive and running all the time, the full development environment is also live together with your application, and we are in fact modifying object structures when we develop Smalltalk programs. We can also snapshot that object memory onto disk and fire it up somewhere else. Several Lisp implementations have used a similar approach I think.

The image model has tons of really cool benefits, I don’t have time repeating all of them, but a modern implementation of the idea should take a few things into account that was not considered in the 1970s:

• The “image” in Spry will be buildable from source
• You should be able to use Spry without the image mechanism (you can already)
• Spry code will have a readable text format and file structure
• The image model does not have to be all or nothing, it can be partial
• The image mechanism will be a module for the Spry VM, so you can skip it entirely

Some argue that the image model has downsides - like being an “ivory tower” incapable of interacting with the outside world. The Smalltalk environments have indeed historically suffered a bit in varying degree, but we can easily find ways around those issues while still reaping the awesomeness of a fully live programming environment, especially if we give the above items proper thought from the start.

With Spry I think I have a beginning to a novel approach… as well as taking the above into account.

When I started out implementing my own language in Nim I named it “Ni” without that much thought actually. It was a pun on “smaller than Nim” (obviously one letter shorter!) and of course with a reference to Monty Python.

But… really, the name “Ni” sucks. It’s hard to say in general and since it’s often mentioned together with Nim the confusion is obvious. And it also turned out to be less than optimal to google for.

Sprylang.org

So from now on the language is called Spry and there are two domains registered for it pointing to the same place - sprylang.org and spry-lang.net. The main site is sprylang.org, I first registered the .net domain but later realized that sprylang is just as reasonable as spry-lang, and there the .org was not taken.

Why spry?

Well, to be honest I was just surfing for synonyms to various “nice words” and I stumbled over it. I was leaning towards “fleck” but a native english speaking friend talked me out of it. :) Spry jumped up from some thesarus site and… it just feels nice. And the meaning of spry is also very fitting IMHO:

Spry: full of life and energy

One of the primary goals of Spry is to be a fully 100% live programming language and environment.

Spry: Moving or performing quickly, lightly, and easily

…and yeah, the agility and nimbleness is also a big part. Given the influence from “older” languages like Smalltalk, Rebol, Lisp and Forth - I can also see some sense in the typical use of the adjective spry - namely as pertaining to someone elderly! That’s fine with me.

And hey, it’s triple creamed too…

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”.

I am of course partial here - but the tool is really easy to use, doesn’t force you into any specific framework or editor, enables a very quick development cycle and has tons of examples, tutorials, docs and some special IoT focused libraries like for example around BLE (Bluetooth Low Energy). You can have your code running on your phone literally within 1-2 minutes and you don’t need to install XCode or the Android tools, you can even run it just fine from your trusty Linux laptop! Just go for it. Ok, enough of the sales talk…

Since we are specializing in the IoT space we have our office filled to the brink with toys… eh, I mean IoT devices of all kinds from all different vendors. Two IoT communication standards are particularly important in this space, and that’s BLE and MQTT. I have already written three blog posts around MQTT using Evothings. Now I am instead focusing on BLE and particularly the embedded device side of the story.

This led me to round up a bunch of devices at the office that are fairly technically capable and have BLE support. The one I selected was the LinkIt ONE development board from MediaTek & Seeed Studio. It’s an insanely feature packed little board (GSM/GPRS, GPS, Wifi, BLE, sound output, SD card) with decent computing power (ARM7 EJ-S, 16Mb flash, 4Mb RAM) while still remaining in the “medium” embedded space I would say, still ruling out plain Linux and regular tools. I consider the Raspberri Pi or C.H.I.P and similar machines to be in the “large” embedded space, they are real computers and you can basically use whatever you like to develop on those.

The medium and small devices can be programmed using for example Espruino or Micropython (two very interesting projects) but in many cases, for more demanding applications, C/C++ is still king simply because of size and performance advantages. And also the fact that hardware vendor SDKs are typically in C/C++. But could there be an alternative language out there?

• A language that is just as fast and small that easily can use all these C/C++ SDKs?
• A language with a syntax similar to Python made to be easy to write and read?
• A language with soft realtime GC and a sane advanced type system with generics?
• A language with a good standard library and friendlier than C++?
• A language with compile time hygienic AST based macros written in the language itself?
• A language offering an imperative style and not forcing OO if you don’t want to?

Yep! Read on to find out…

I have just started working at Evothings!

It’s a fun gang making slick development tools and libraries for building mobile IoT apps. Evothings is pushing the envelope on really easy mobile development focused on all the new nifty IoT-devices flooding us over the next few years.

In my last article I predicted Elixir to become big and now that I am learning the Evothings tools I wanted to make an Evothings example that uses Phoenix, the Elixir web server framework, as a backend, using its channels mechanism for websocket communication.

Coinciding with the release today of Evothings Studio 2.0 beta 2 (yay!) I will show step-by-step how to:

1. Install Evothings Studio locally. It’s just unpacking a zip :)
2. Make sure we can run the “BLE Scan” example app and modify it.
3. Get a Phoenix server up on a Debian/Ubuntu server on the internet.
4. Modify the app and server to use Phoenix channels for publish/subscribe of scan data.
5. Verify it all works!

Since not everyone has a Linux server up on the internet you can skip step 3 and just use my public server :)

Let’s go!