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.

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!

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…

A friend of mine is having a less optimal experience with Linux, and I realized I could jot down my experience for the last few years.

I have been using Linux on my desktop for a long time now, about 10 years I think. Early I played “distro jumping” and used Lunar Linux for quite some time on my older Zepto laptop.

But at some point I just decided that, nah, source distros are huge time sinks. Not necessarily because they have issues, but because they are fun to tinker with. I also felt it was “smarter” to know a mainstream Linux well, so I decided to go for “least friction”, and moved to Ubuntu. When Unity hit I did contemplate using something else, at least an alternative shell, but decided to just “hang in there”, and now I tend to like it. Recently I upgraded to Ubuntu 14.04 LTS, it was pretty eventless.

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.