A Portable Vision to Reshape the Software Condition

Error message

  • Deprecated function: implode(): Passing glue string after array is deprecated. Swap the parameters in drupal_get_feeds() (line 394 of /home/patsissons/drupal.acrotech.io/includes/common.inc).
  • Deprecated function: The each() function is deprecated. This message will be suppressed on further calls in menu_set_active_trail() (line 2405 of /home/patsissons/drupal.acrotech.io/includes/menu.inc).

A Portable Vision to Reshape the Software Condition

When Acrotech Solutions began, our goal was to produce elegant portable solutions to software problems. Portable solutions mean we intend our software to operate on any platform, the way one would expect software ought to work. 

The Problem with Software Languages

Platform specific languages (languages whose code base targets a specific platform) have fragmented the software solutions available leaving developers the choice of either picking sides, or writing their software in an interpreted or virtual machine language. As a result, interpreted and virtual machine languages have become immensely popular (Java is one of the most popular languages, likely due to android’s growing ubiquity and their focus on enterprise software). That is not to say platform specific languages are not still popular (the C language is always in contention for the #1 spot), just that their numbers are shifting elsewhere.

Language selection can be a very polarizing subject and can define a business to a platform (this is why there are Apple shops and Android shops). But what happens if you write a popular app for a specific target? Well, often you will be asked to convert it to another platform. This would involve re-developing the app in another language, and during this process there is the potential to introduce new bugs. Even if bugs were not an issue, it still means you need to maintain two (or more) products, essentially scaling your work load linearly across the supported platforms. What if you could make a bug fix once, or add a feature once and have all your users enjoy the changes at the same time? The option is there for developers, but is that option worth the (potential) drawbacks?

Choosing Portability versus Performance

Traditionally, the choice has always been between portability and performance. The more portable your language, the less performant you can expect the software to run (this is not a rule, just an expectation). Sometimes, however, a minor performance loss is negligible and therefore writing software in a less performant language brings many more benefits than the drawbacks of performance loss. This is largely due to the level of performance we can squeeze out of a routine CPU these day.

A good analogy to visualize the performance spread is a text processor. A routine CPU handles even the most aggressive keyboardists without breaking a sweat, only showing signs of weakness perhaps when loading, saving, or performing grammar heuristics on a large document. This is why atom.io (a new text editor rapidly gaining popularity) was written in CoffeeScript (which is essentially JavaScript, an interpreted language). When compared to its primary competition (Sublime), it is certainly slower, but by a small and shrinking margin. The point is that the reason atom.io can be reliably written in a platform independent language is because the level of performance required for common usage patterns is less than what a routine CPU can take care of.

In contrast, video rending applications (for example) require heavy CPU usage, where the overhead of a platform independent language (to translate virtualized instructions to native instructions) has a substantial (and noticeable) performance cost. To maximize performance in applications like these, a platform specific language is typically used because it makes the most efficient use of the CPU. This is not to say that you could not write a portable video rendering tool in an interpreted language, just that the benefits of the tool being portable have to convince your users that there is value over performance, which would be fairly difficult to achieve because the performance gap would likely be quite large.

So what if you could get the best of both worlds, maximum portability with a minimum performance hit?

A New Challenger Approaches

Until recently, platform independence was limited to interpreted languages (like JavaScript) and virtual machine languages (like Java). That is, until a team of developers started producing the Xamarin SDK. The Xamarin team recognized that they could leverage the architecture and runtime independence of the .NET core intermediate language (MSIL) and scale it out to full platform independence. By using the open source .NET core project mono as their home base and building the runtimes against the big two mobile platforms (iOS and Android, in addition to the already available WinPhone platform), Xamarin now allows developers to deploy MSIL compiled software (which is Just-in-time compiled to native CPU instructions) to platforms that, prior to Xamarin, did not support the language. This means that .NET developers can target 85%+ mobile device markets with a single code base, with the only requirement being compiling the code base for each platform. When comparing Xamarin performance to native performance we can see that there is an expected performance gap, but that the language features and platform independence gained far outweighs the modest performance hit.

Microsoft was working in parallel to bring a more portable development experience for its developers for similar reasons and announced the Portable Class Library (PCL), a module of software that could be run against any compatible .NET runtime. As the Xamarin SDK and PCL architecture merged, the .NET community was given the opportunity to write code and compile once to deploy to any supported platform (currently including Windows 8, Windows Phone Silverlight 8, Silverlight 5, Windows Phone 8.1, Android, iOS, OSX, and classic desktop applications). Each software module created can be defined to adhere to a portable profile, a subset of language features that can be understood by the chosen platforms and runtimes. This means a developer will choose the level portability desired for the module, ushering in the era of truly universal software development. Development packaging system, such as NuGet, are now able to link modules of compiled code to any .NET project targeting a compatible portable profile. Selecting a more portable profile can sometimes mean there is a reduced intersection of functionality available to link against, but with the advances in the portable library ecosystems (NuGet) these functionality gaps are narrowing every day.

The Acrotech Solution

At Acrotech Solutions, we use standard development and design patterns, such as Inversion of Control for example, and portable profiles to produce universally portable solutions to common software problems. For the past year, we have been working at producing a solid software stack of simple, efficient, and elegant portable solutions that bring value to all .NET projects, regardless of platform. Over the next few weeks we will be publishing successive open source software solutions along with corresponding blog posts detailing the products we are releasing, why they were conceived, how they are useful to developers, and what developers need to get started using them. By introducing the value of these libraries and tools through screen casts containing natural examples, more developers may take advantage of building portable solutions and improving the overall development ecosystem we are all a part of.

Acrotech Solutions believes not only in building better software, but helping to educate everyone on how we can achieve this. Even if our competition starts building better software, the result is that the development community is benefited as a whole, and that is good for everyone.

Full disclosure, Acrotech Solutions uses the Xamarin products to build portable solutions, but is in no way affiliated with Xamarin. That said, there is certainly going to be a noticeable bias towards preferring the Xamarin SDK, that is until something better becomes available. We believe that in the current development marketplace, the best value to customers and developers is what Xamarin offers.

In case you are wondering about why the title of this post sounds familiar, I have used a play on a quote from Tron: Legacy.

Header image was created using the content of the wikipedia page for Software Portability and feeding it into the Word Cloud Generator.