You Ain't Seen Nothing Like the Mighty Nim

Not if you are used to class based oop. Instead, Nim is type based and uses multi-methods. This takes some getting used to. So after a couple of weeks, what are my impressions?

My last attempt at creating  a native game engine using Vala was disappointing - great language, slow run time. I actually considered Nim prior to trying Vala, but I was put off by the 'partial style insensitivity' - this means that 'setValue', 'set_value', and 'setvalue' all refer to the same identifier. I don't see any good reasons for that, just another way to get bugs. Between this and the original name Nimrod I was convinced that it was done to prevent wide spread acceptance and keep Nim as a hobby language.

But this isn't a rant. I can live with 'partial insensitivity', and the name was shortened. Nim has a pragmatic style. Nim doesn't have classes, so I don't end up with a complex class hierarchy - this is a good thing. I can use inheritance where it is needed, and composition is easy. With multi methods, I can define a 'class' in more than one file - this is handy if I want to extend an existing class like you can in CSharp. Compared to languages like Java which provide a 'place for everything, everything in it's place', Nim gives you a lot more freedom in organizing your code and files. And definitely requires less boilerplate. Of course, since there is not much structure, you'll need to provide your own.

After 2 weeks of coding, my proof of concept is running on both Linux and Windows7. Not only that, the performance is better than I anticipated, even exciting. I've done no performance tuning. My entity object uses an array for components, but all other arrays are just sequences, tables and queues - all plain Nim dynamic structures. When I play my test demo, ShmupWarz, I can shoot bullets continuously for minutes, blasting enemy ships, and only once did I notice my frame rate drop below 60 fps.

I'm sold. I'm continuing on with my project, using Nim

Six Weeks with Vala

Update: https://blog.darkoverlordofdata.com/2016/12/vala-revisited.html

One concept discussed in functional progamming is 'Reasonablness', which focuses alot on how side effects make it hard to predict what your code is actually doing. In case you're not familiar, here is a great post on the topic http://fsharpforfunandprofit.com/posts/is-your-language-unreasonable/

One thing I like about that post is that the author points out that by their nature, we cannot expect much of this 'reasonableness' from your typical oop language. But I think Vala fares worse on than most.

Part of it is the ecosystem - it's hard to reasom without information. Documentation is sparse, conflicting, or just missing. Granted that all technology products have this issue to some degree, but it's particularily bad in the case of Vala. I can't get the Gnome toolset working because I'm not using a gnome desktop. If this were Microsoft or Oracle, we'd call it vendor lockin. I'll give Gnome the benefit of doubt and chalk it up to tunnel-vision or not-invented-here-syndrome. But the result is that I am using Atom and command line make, and scratching my head alot while I seach the web for clues.

But that can be fixed. The real issue I belive is the dependancy on GObject. Remember, GObject was created to compete with Microsoft COM. COM was the object system that backed VB6. It was also the cause of much of VB6 unreasonable behavior. DotNET was created to replace COM. Microsoft wanted a 'pure' object system that would met the requirements of any language. Vala follows the VB6 model of shoe horning the langage to fit the existing object system. And this leaks through the abstracton and results in arbitrary constraints on the language. I continually get compilation errors - things like interfaces and properties sometimes don't compile until I base the class on GObject, resulting in other side effects, requiring more than one ground up redesign. And I still find myself surprised by the results, and not in a good way.

So, what was I actually able to accomplish in those six weeks of vala? First, I discovered Genie, Vala's whitespaces language. This is a great alternative to Vala's curly braces, and I credit it with speeding up the process. It seems to be designed to provide intelligent defaults, and the overall effect is much less typing, and an easy to read grammer. It is missing a couple of features present in Vala - namely lambda's and multidimemsional arrays - though I can declare them in Vala and then comsume them from Geanie. I will miss Geanie.

So, after six weeks, I have a prototype shmup game using SLD2 and Bosco.ECS (My ecs inspred by Entitas). It's a little dissapointing. Performance is not better than Unity. And with Unity, 6 weeks later I had a full game enviromment, with menu, scores, leaderboard, running on Windows, Linux and Android. I still can't get a Vala game to compile on or for Windows 7. Nor have I yet addressed sound or a UI. In case you're interested in Vala, my project is https://github.com/darkoverlordofdata/shmupwarz-vala

I really like Vala and wanted it to work, but its mostly frustrating. And I found that I Genie, the 'other' language compiled by valac, is vastly underrated. Genie could be the next big thing, if Gnome lets it. But I'm moving on to something more fruitful.