The Tobii EyeX eye tracking controller is one of the coolest gadgets I have tried recently. With it you can orient yourself within a 3D world by simply gazing at the corners of the screen, which is something we all do naturally as we explore any virtual scene. The resulting user experience is similar to using an ‘endless’ screen and when paired with a high resolution display, it feels surprisingly more immersive than the current crop of low-def HMDs.
At Lucidscape we are building a new kind of massively-distributed 3D simulation engine to power the vast network of interconnected virtual worlds known as the Metaverse.
Handling massive virtual worlds requires a fundamentally different approach to engine design, one that prioritizes the requirements of scale, thoroughly embraces distributed computing and many-core architectures, and that is also unencumbered by the legacy decisions which hold current engines back.
We have recently conducted our first large scale test where we simulated the interactions of 10 million participants on a cluster of over 800 servers.
Suitable Technologies did a great job with the Beam, the user interface is great and the robot handles very well. One-on-one conversations felt natural despite of the loud environment however multi-party conversations were challenging at times, but still workable.
Watching a robot demonstration, through the eyes of another robot
We all know that the cost of computing is on a definitive downtrend and while this is a great thing I worry that it is also steering developers to become less proficient in writing efficient (and reliable) code.
If most problems can be solved by throwing money and hardware at sub par wasteful code, what is the incentive to writing thoughtful, efficient programs?
The answer is RELIABILITY (and possibly to save your planet)
While the cost of computing is going down the adoption of dynamic languages is going up and that worries me. Perhaps I am just a backwards man who hasn’t seen the light yet but I urge you to bear with me as I present my argument against the use of dynamic languages in a production environment.
Why do I claim that dynamic languages are wasteful?
If you appreciate theater it is likely that you also appreciate that the actors have to work hard at every performance. It is a beautiful thing, but it is also a lot of repetitive work and that is exactly the problem with dynamic languages in general.
How so? Every execution (performance) requires that a lot of work is done by the language runtime (showtime) environment. Most of the time this is repetitive work, mindlessly repeated every time you run your code.
Compare this with the stark contrast of cinema (compiled code) – there is no showtime hustle, the movie is already shot, cut, edited and packaged for delivery. No energy is wasted.
You might ask me how significant is this waste I am talking about and the truth is that most of the time it is negligible but like everything in life, the devil is in the details.
Hypothetically, let us say that at each execution a dynamic program wastes a mere 10,000 CPU cycles doing “preventable runtime busy-work”. That figure is utterly insignificant if you are looking at the trees only, but as you step back to look at the forest your perspective might change.
Imagine this same piece of code running on a few hundred-thousand computers around the world and being executed a few thousand times a day on each. Now multiply this by each program of each dynamic language in existence and you might conclude that dynamic languages are not very good for our planet because computing demands energy and energy demands natural resources.
“But dynamic languages are more productive so the energy wasted on one end is saved on another!”
Some might argue that dynamic languages are able to offset their “global footprint” by being more productive. Unfortunately, I beg to differ.
Unless you are simply writing throwaway (or generally short-lived) code, the odds are that whatever you are building will remain in play for years to come. This brings two new variables into the equation, one is maintenance costs and the other is failure costs. I am going to argue that compiled languages do a better job at minimizing those costs in the long run due to the increased reliability they offer.
First, we need to define what “productive” means in a quantifiable way because there is no room for fuzzy subjective opinions in computer science.
I believe that the Total Cost of Ownership (TCO) of a software solution is the ideal metric of productivity. A language that can deliver a piece of software with a lower lifetime TCO should be considered more productive simply because more was produced for less.
TCO encompasses everything from time-to-market risk, development costs, maintenance costs, failure-rate costs as well as any other overhead incurred.
My argument is that while dynamic languages may accelerate the initial delivery of a software solution, it does so at the cost of reliability and maintainability. This is detrimental for the TCO bottom line because in practical terms (at least for large, long-lived projects) it translates into decreased productivity.
“But compiled languages are too hard!”
The place for dynamic languages
With all that being said, I must disclose that I often use dynamic languages in my research when it makes sense, mostly for throwaway code or prototyping. In fact, one of my favorite tools (MATLAB) is centered around a particularly terrible dynamic language. What I am against is using dynamic languages for the development of code intended for production environments. That is all.
If you love our planet and you love computer science, I urge you to not take the easy way out, embrace the beautiful complexity of machine efficient code and write greener programs by using a compiled language. It can only make you smarter in the long run