Nim on Roads Less Taken

Spry Error Handling

Wed, 21 Apr 2021 00:00:00 +0000

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.

In fact, I wrote this article last year but forgot to get it done and published!

Error handling is an interesting topic, earlier it wasn’t really much controversy around it but the advent of new techniques (Optionals etc) in combination with languages making… “interesting” choices (I am looking at you Go) has made this subject fairly hot. So what do we want in Spry??

Revisiting Spry

Fri, 05 Jun 2020 00:00:00 +0000

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.

So I am now trying to “clean house” on where Spry stands today. This sweep through the old articles is a first step, then I will update the language manual to be 100% in sync with the implementation.

Let’s go through the articles from the beginning!

Writing Arduinobot in Nim

Thu, 26 Oct 2017 00:00:00 +0000

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.

To spice it up, for no specific reason at all, we are doing it all inside a Linux Container - a fast virtual environment to work in. It’s just a nice way to have a clean environment and to ensure that you as a reader see the same results as I do.

Nim crash course in LXC

Tue, 24 Oct 2017 00:00:00 +0000

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.

Benchmarking Spry vs Squeak

Fri, 26 Aug 2016 00:00:00 +0000

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.

Some background on the Spry implementation may be interesting. Spry is implemented in Nim as a direct AST interpreter, it’s not a JIT, in only about 2000 lines of code. It has a recursive classic “naive” design and uses a spaghetti stack of activation records, all allocated on the heap relying fully on Nim’s GC to do it’s work. It also relies on Nim’s method dynamic dispatch in the interpreter loop for dispatching on the different AST nodes. Blocks are true closures and control structures like timesRepeat: are implemented as primitives, normally not cheating. Suffice to say, there are LOTS of things we can do to make Spry run faster!

The philosophy of implementation is to keep Spry very small and “shallow” which means we rely as much as possible on the shoulders of others. In this case, primarily Nim and it’s superb features, performance and standard library.

Enough jibbering, let’s do some silly damn lies - ehrm, I mean silly tests!

Spry Performance

Tue, 24 May 2016 00:00:00 +0000

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!

In this article I do some silly experiments around interpreter startup time and fooling around with 40 million element arrays. As usual, I am fully aware that the languages (Pharo Smalltalk, NodeJS, Python) I compare with a) have lots of other ways to do things b) may not have been used exactly as someone else would have done it. A truck load of salt required. Now… let’s go!

Nim meets Arduino

Thu, 25 Feb 2016 00:00:00 +0000

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…

Guts of Ni

Tue, 22 Sep 2015 00:00:00 +0000

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 :)

Who says Ni?

Wed, 16 Sep 2015 00:00:00 +0000

Ni is my own little language heavily influenced by Smalltalk but also other sources like Rebol, Forth, Lisp, Self and Nim. Ni is a bit strange, but it’s not academic and really meant to become something useful.

So put on your helmet and let me take you to the shrubbery…

Nim and super

Wed, 06 May 2015 00:00:00 +0000

As I described in the earlier posts Nim didn’t support “super calls” when using methods instead of statically bound procs and generics. My article caused a little bit of discussion around this on IRC and Andreas decided to implement the mechanism he already had planned - but had not fully decided a good name for.

The other day Nim 0.11.2 was released and it includes this mechanism. Let’s have a look how it works in my sample code…

Nim

Thu, 26 Mar 2015 00:00:00 +0000

Having been a die hard Smalltalker since 1994 I have finally found a new language and community that I am investing myself in. All the Ruby, Python, various JVM languages, C# and Mono etc - none has managed to capture my interest. Ruby and Python always felt like pale shadows of Smalltalk and I really don’t want to be tied to the Java eco system, no matter what. And so on and on, lots of languages looking interesting but not being able to withstand my deeper look. As a Smalltalker I probably have acquired a particular taste.

Since a few months I am however deeply into Nim. I have written a slew of articles about Nim, and at our company we have decided to bet hard on it. So far I have written a little utility called blimp in Nim, and I have helped creating Urhonimo - the Nim wrapper of the Urho3D game engine.

With a deeper understanding of Nim, although I am far from good at it, what is it that makes me recommend you to try it?

Nim visits GTUG Stockholm

Thu, 26 Mar 2015 00:00:00 +0000

Yesterday I had the pleasure of presenting the programming language Nim at the Stockholm GTUG . This evening we were around 50 people, I would guess mainly developers, listening to three presentations:

Rust , by Johan Burell, EVRY
Nim , by Göran Krampe, 3DICC
Go , by Marcus Olsson, Citerus

Now, that’s a pretty fitting trio of languages! :) This article is a little followup because I failed to mention so much stuff…

Nim seq

Wed, 03 Dec 2014 00:00:00 +0000

One of the most important aspects in a language is how powerful and easy it is to use its collection/container types. At least that is my feeling coming from Smalltalk where the Collection classes and their rather rich protocols are used extensively and also cover String and Array and much more. If you peek into the current leading open source Smalltalk - Pharo - you can see Collection allSubclasses size evaluate to 78. Of course, lots of those are special subclasses and not for general use, but fact remains that a strong language needs a strong library of good collections.

In Smalltalk I can for example run this:

#(1 2 3 4 5) select: [:x | x isOdd ] thenCollect: [:x | x * 3 ]

This is actually a single method call taking two closures, one to perform a “filtering”, and one to perform a “map”. This is not a standard message in “good old” Smaltalk-80, but it has eventually been added since the usage pattern is so common. To me personally a modern language needs similar power or I would go nuts. :)

Nim and OO, Part IV

Sun, 30 Nov 2014 00:00:00 +0000

The other day this mechanism entered the devel branch which means it will be official in the next release of Nim, which I suspect will be out before the end of 2014. It should be noted that devel is mainly undergoing bug fixing, so unless you are paranoid it’s pretty usable. Now… of course I had to try out super calls in my sample code…

Squeak to Nim, come in Nim...

Mon, 03 Nov 2014 00:00:00 +0000

In my exploration of Nim the turn has come to see how we can use Nim together with Squeak .

Squeak (and Pharo) has two basic mechanisms of interfacing with the C world:

Squeak VM plugins . That pdf is old, but still fairly accurate I guess.
Squeak FFI , Foreign Function Interface.

The VM plugins are basically a controlled way to introduce new “named” primitives in Smalltalk that can be invoked from Smalltalk. A plugin can be built either linked into the VM binary (statically) or as a dynamically loaded library (dll, so, dylib etc). When “all else fails” a plugin is the way to go, but they are a bit awkward to work with.

Then we have the FFI which is a generic way to dynamically call dynamically loaded libraries. In other words, no compilation step needed - just type the correct Smalltalk line and the library will load and the calls work. Now… sure, the FFI mechanism is a bit slower, since it needs to look at arguments and make the proper type conversions for the call. But the FFI is heavily used in the commercial Terf system, in fact, all the OpenGL calls are done through it. So its quite proven, and not that slow.

NOTE: There are in fact several FFIs today, the old one, the one called Alien and Pharo is brewing a new one called UFFI.

Let’s see if we can use the good old FFI with Nim.

Nim and OO, Part II

Fri, 31 Oct 2014 00:00:00 +0000

In the previous article when I explored OO mechanisms in Nim I felt I dropped the ball a bit in my Fruit example. This is a followup.

In that article we first implemented some Fruit “classes” mixing methods and procs. Then I presented a cleaned up version using methods only, and a teeny template in order to reuse a base method. This template was needed since Nim currently doesn’t have a “call-next-method-matching” for multimethods like Dylan or CLOS have. This is being discussed and I think all agree that there needs to be some mechanism so that you can call a “next lesser match” of all matching multimethods.

But I also wrote that the example can be written perfectly well using generics and procs only, thus ensuring static binding and maximum speed. But the “super call” problem also existed for procs, and the template hack was just a hack. After more experimentation I now think I found the proper Nim way to do this so let’s take a look…

Nim and OO, Part III

Fri, 31 Oct 2014 00:00:00 +0000

So previously in Nim and OO Part II we saw how we could solve the “super call” issue using only procs and generics in Nim . This means that all code is statically bound.

But if you have read all these article you know I also tried the more appropriate mechanism for OO - so called methods. In Nim a proc is a regular statically bound function, simple and fast. A method on the other hand uses dynamic multimethod dispatch on the runtime types of all object parameters. The easy way to do objects in Nim (with inheritance of behavior) is using methods - but of course, this means dynamic lookup that has a runtime cost, but quite small as we will see.

Time for benchmarking!

Nim and OO

Wed, 29 Oct 2014 00:00:00 +0000

Nim is presented as an imperative language. And yes, it has some of its roots in the Pascal line of languages, but it also has a set of powerful abstraction mechanisms making it very suitable for object oriented programming. And when I write “object oriented” I am referring to a broader flexible sense of OO in which objects can be formulated with attached behavior, polymorphism between different objects, some kind of reuse model of code (inheritance etc) and some type of dynamic dispatch.

Since I am a long time Smalltalker that is my main reference for “good OO” and not the … monstrous OO often seen in Java or C++. Its hard to explain the differences, but let me just say that OO in Smalltalk is elegant and natural, very much like in Ruby or Python - but ever so more streamlined. Smalltalk is a dynamically strongly typed reflective language with a heavily closure based style.

In this article I will try to make “sense” out of how to do OO in Nim.

Nim Socket Server

Sat, 25 Oct 2014 00:00:00 +0000

In learning Nim I decided to implement a trivial Socket server, very small, as an example. Its not a useful HTTP server (it just returns a hard coded HTTP response so we can benchmark it using HTTP tools), and its not async - there are other such examples in the Nim examples directory and in its stdlib. No, I wanted to write a more classical threaded socket server to see how easy that is - especially with the new APIs in Nim “bigbreak” - and see how it performs.

The new “bigbreak” branch that will become Nim 0.10.0 soon-ish has a bunch of new stuff in the networking area. Its replacing the single sockets module with a low level rawsockets module, and a higher level net module. And there is a new selectors module that abstracts over different modern IO polling mechanisms. This means that a single API will use epoll on Linux, kqueue on BSD/OSX, old select on the other Unices and IO Completion ports on Windows. At the moment epoll, select on “other Unices” and IO Completion ports works. kqueue is on the todo.

So without further ado…

I missed Nim

Mon, 20 Oct 2014 00:00:00 +0000

A year ago I wrote an article trying to round up new languages since year 2000 and what I think of them by just… glancing at them, or otherwise playing with them. I ended up sifting out the 4 most interesting in my not so humble opinion - Go , Rust , Dart and Julia . Now a year has passed and…

I discover that I missed Nim(Nimrod)!

Nim was born somewhere around 2006-ish and is clearly a very serious language to consider, but is going suspiciously under the radar. Having reviewed this language more closely (and still doing so) I can safely say that for me it actually easily tops this list.

I have already posted a few articles about Nim , but this one is meant as a followup to that article trying to make amends :).

NOTE: Technically Nim is still called “Nimrod” up to and including the 0.9.6-release that was done yesterday . But for the upcoming 0.10.0 and onward its Nim. Short and sweet.

Nim wrapping C

Thu, 16 Oct 2014 00:00:00 +0000

Nim has all the language mechanisms needed to smoothly interoperate with C and C++. The rather large collection of wrapped C libraries (and that’s only those in the standard libs) is also a testament to this fact. In this article I explain my personal findings testing out the waters of wrapping a simple C library.

The basic approach to wrapping a simple C library is:

Install Nim.
Install c2nim using Babel or manually clone c2nim from github and build it.
Use c2nim to translate the C header file(s) to a so called Nim wrapper.
Make a small test showing it works.
Write a so called “impure” intermediary library that uses the wrapper (next article)
Make a test green and declare Victory (next article)

Okidoki… (roll up sleeves)

Bootstrapping Nim(rod)

Wed, 15 Oct 2014 00:00:00 +0000

Technically Nim is still called Nimrod up to and including upcoming bugfix version 0.9.6. But then with the next version 0.10.0 it will be just Nim. Currently Nimrod is at 0.9.4 . And oh, the current development version is 0.9.5 which will become 0.9.6 when released - the “odd and even” versioning scheme.

Nim can be a bit funky to get started with, typically due to a slight lack of documentation in certain areas that may be obvious to Nimmers (or Nimsters? Knights who say Nim?). This article tries to fill a few mental holes in the first steps.

Also, Nimsters like to do it in Nim - and often the reasons for this are very good, like maintaining portability or minimizing dependencies. Just don’t expect the classic autoconf dance here. As a Smalltalker I am fully versed in the NIH syndrome - which of course doesn’t always have to be a bad thing. Thankfully Nimmers also seem to balance it with a strong tradition of standing on the shoulders of giants .

So building Nim isn’t hard, but it’s also not obvious what is going on. There are of course binary installers available too, but hey, we want to hack!

Here Comes Nim!

Mon, 13 Oct 2014 00:00:00 +0000

I just posted an article comparing some silly benchmarks between Cog Smalltalk and LuaJIT2. Now… let’s take a look at one of the latest “Cool Kids” on the language front, Nimrod - or as it has been renamed - Nim .