A particular issue, known as the “Pyramid of Doom,” can be heavily detrimental to the function of your web business, and can negatively impact client experience and profitability. The good news, however, is that the Pyramid of Doom can be avoided by implementing a style of programming known as “promises,” potentially saving your company thousands by circumventing a very common JS issue.
What is the Pyramid of Doom?
A Pyramid of Doom can occur when a program contains code that makes too many assumptions about classes, other programs, or data it is attempting to call upon. Generally associated with nested indentation in JS, a Pyramid of Doom is characterized by a single value somewhere within a “pyramid” of indented code returning null and breaking the entire program. Locating the value that is causing the Pyramid is time consuming and sometimes nearly impossible, meaning that in the occurrence of a Pyramid, a great amount of money can be spent in labor alone trying to fix the problem, not to mention the potential cost of affected services being down.
How Can a Pyramid of Doom Be Avoided?
The commonality of the Pyramid of Doom problem has led to a number of solutions arising to address, solve, or outright avoid the Pyramid of Doom. One of the tactics that has eliminated Pyramids of Doom in many languages that were developed after JS was developed is “syntactic sugar.” Syntactic sugar actually refers to the general “sweetening” of languages for human use by including convenient syntax shortcuts. The programming language Perl, for example, incorporates a form of syntactic sugar in the form of the “unless” statement. Unless statements do not exist in all other languages and this can help clean up and simplify code for later parsing by other coders or users, as well as allowing for sidestepping certain types of the Pyramid of Doom.
Syntactic sugar is not the be-all-end-all of the Pyramid of Doom problem or other programming oversights. In certain contexts, syntactic sugar has even been criticized for adding unnecessary layers to programming that actually doesn’t simplify the process at all. Sugar that doesn’t successfully sweeten the programming experience is often jokingly referred to as syntactic saccharin.
Some languages have also incorporated the flip-side of the syntactic sugar solutions, known as “syntactic salt.” Syntactic salt is defined as features of a language or compiler that impede the creation of bad code, typically designed to target extremely common issues.
Who Developed Promises/Futures?
Future/promise constructs have been around for quite some time, though the term was originally coined by Barbara Liskov and Liuba Shrira in 1988. The constructs were originally developed to combat latency issues, but did not reach peak popularity with the programming community at large until 2000. In 2000, many users began to see the value in using promises/futures for web development to help streamline and improve website functionality. Since 2000, many languages have implemented promise/future constructs.
Want to know more? We can help you at www.nixa.ca! We are a company of professional web developers who can help you learn new techniques, master old ones, and avoid the most dangerous missteps in web development. Contact us today!