Nzym is a new programming language that focuses on making programming easier, simpler, and faster, quickening production time to even produce better results, especially for multimedia applications. At the core of Nzym is a script file object that can exist on its own or be linked in conjunction with others. It is through these scripted objects that the Nzym interpreter can generate programs and content pages.

Nzym: A simple, object-oriented, interpreted, imperative, multiplatform, high-performance, multithreaded, and dynamic language.

Sadomba-Mahari Computers (Private) Limited (or simply SM), the company behind the development of Nzym, entered the web development industry in 2010, about a few months since they had been registered, as well as dabbled in the making of specialized software for the local film industry in Zimbabwe. About a few years later, they also began to develop mobile applications targeted at higher-end mobile phones on the Android, Windows Phone, and iOS platforms. The indented italicized portions below seek to give a narrative of the issues faced by SM and to give examples of the keywords of Nzym presented.

Type nameOfType = value;
nameOfType.MethodOfType = value2;
Class NameOfClass = InheritFrom;
Function NameOfFx = ReturnType;
Method NameOfMethod = ReturnType;

In the beginning, SM employed only three full-time programmers, two of whom were interns hired from the university. The greatest challenge that was presented to them was to be able to create and replicate static websites, tailor-made for various types of clients but narrowing down production time. Obviously, stylesheets were going to be different from project to project but there were elements that were going to exist in every project and that would exist in all projects especially navigation, footer widgets, the home page, contact page, an about page, and a page for highlighting products and showing portfolios. A simpler way to prototype and produce needed to be possible…

When working on a website, the team at SM knew they were always going to need to recreate common elements like the contact form or a drop-down menu but with some modifications as requested by the client. As they dealt mostly with creating static websites, it seemed to be a good idea if there was a way in which they could group these common elements into separate files for easy importing into a project, as and when they were needed, with minor modifications for the client. For example, changes in color, addition or removal of certain fields from a form, or the inclusion of icons on the menu.

The team at SM would use Bootstrap or an in-house boilerplate that existed at the time to recreate and generate different types of websites. However, these code blocks had a lot of disadvantages, especially when displaying on different devices and older browsers.

One difficulty in the work of the team at SM was having to pinpoint where to put elements they were reusing in every project. One website would have a menu system located at the top of the page above the header, and another would have a menu below the header. Sometimes the menu would be placed in the header, among other header elements and at times it was apart. Knowing where to position the clump of code with the menus was then a task that required a lot of care and if one walked away for a while from their project, it was always difficult to resume. It was equally jarring if someone needed to take over an ongoing project from another person, not being able to tell where the project was going and what had been done just at a glance.

While the work on the websites was the bread and butter of SM, there was another big project of which SM became a part of, and that involved work on a multimedia software package called AVisPar (the African Visual Package). AVisPar was a set of software programs and tools for creating 3D visualizations, films, games, game assets, and visual effects. What was to be unique about AVisPar was its ability to make use of a graphics card to produce high-quality 3D renders and save them to disk almost in real-time. AVisPar was also developed to work, not only on the most common commercial desktop operating systems but also on some Linux distributions as well.

AVisPar was a unique project for the team at SM to work on. It allowed for a lot of experimentation in terms of how to create the solutions involved but there was one huge problem that the team faced and that one was to do with handling simultaneous events. The initial code base of AVisPar had been written in C++ along with some libraries from other 3D game engines such as Irrlicht which were included. The 3D game engine Irrlicht in particular did have some multithreading functionality that was easy to use and adapt for running various processes on a single machine. However, running multiple threads on a network with various CPUs and graphics processing units involved, the threads became really difficult and complicated to handle.

From the beginning of 2011, and all throughout the year until the end of 2012, SM experienced an increase in customers requiring their services to develop mobile applications for them. SM made use of Java in creating apps for smartphones of that time that supported Java, including Android phones that were gaining a lot of market share at that time. The problem became that the code for these platforms, although written in the same language, they were not and could not be the same. The visual presentation was not portable and the functionality greatly differed, as well as the libraries used in development.