DEV Community: Jami

Esoteric Coding Languages: Malbolge

Jami — Mon, 01 Jun 2026 13:06:33 +0000

Esoteric programming languages

are often created to add a little bit of spice to the coding world. They're mysterious and often unsolvable for the average coder due to their unnecessary difficulty. Luckily, the world loves mystery. **BranFlakes **and **Befunge **seemed to be as bad as esoteric languages could get until Malbolge was introduced.

Malbolge was made to be almost impossible to use due to it's self altering and base-three arithmetic code. It builds on the difficulties of earlier esoteric languages like BranFlakes and Befunge by playing on older versions of computer science and encryption.

Malbolge was made in 1998, named after the 8th circle in Dante's Inferno, and created by Ben Olmstead. The first written program however, was made through a Beam Search algorithm (a quick problem solving search algorithm using breadth first search to build it's search tree) designed by Andrew Cooke (through a Lisp implementation).

Two assembly languages currently exist to write Malbolge code. The first is LaL which was implemented by Japanese researchers and the second is HeLL due to a precise specification of LaL not being available as of 2013 (now available). Both of these languages utilize *mnemonics *(a strategy of accessing information in long term memory) and labels so that ternary memory address access is not necessary to run it's program. It's use is not necessary, it is more to say that it was done rather than for useful applications.

Malbolge was generated by a Beam Search Algorithm: A heuristic search algorithm that only searches the most definitive nodes at a time. Because Beam Search expands limited nodes it is most beneficial for large searches. It utilizes _best-search-first modification _which alters log probability to return decent results. Beam search is often used in machine translation systems due to it's accuracy and ability to search larger databases.

Malbolge has 3 accessible memory locations (registers) 'A' (accumulator), 'C' (code pointer), 'D' (data pointer). After every instruction if the memory that 'C' points to is within the range of 33-126 then the following translation table is used:

When the interpreter executes a program it first checks to see if the proposed code is an ASCII character. If it is, it subtracts 33 from it and adds 'C' and then modifies its character index by 94. If the original code is not an ASCII character the program automatically terminates.

The word Cat in Malbolge

This strange language has eight instructions and it's code functions based on trits of each machine word. The variable 'J' sets the pointer to the value already being pointed to. The variable 'I' sets the pointer to the value that will be pointed to. The star character rotates the trinary value of the cell that 'D' points to, to the right of 1. The variable 'P' performs a tritwise operation on the cell 'D' points to with contents of 'A'. The variable '<' reads the ASCII value from the stdin and converts it to Trinary and then stores it in A. The forward slash character converts the value in A to ASCII and then writes it in stdout . 'V' indicates the machines termination and lastly 'O' increments 'C' and 'D'.

A-Trits:

Di-Trits:

Trinary -> ASCII -> Decimal -> Hex-Table:

There are two techniques for writing Malbolge. The first is to print the text and terminate the code. The second technique is used for conditionals, loops, and inputs. In the second technique the developer designs the program as if every cell of memory can be initialized with arbitrary values, then generates the initialization code that writes the corresponding values into memory.

Malbolge utilizes '.code' and '.data' to determine where memory cells are used. Values within both of these must be assigned to a label and as the code self modifies, it's Movd/nop becomes a Movd instruction (an instruction which copies scalar quantities), which then becomes a Nop after modifying and encrypting again. Nop is short for no-operation meaning it does nothing and does not access any memory.

Malbolge is a wild and strange coding language that is not used very often. It's implementation is mostly for shock value and to show just how complicated machines can become. While it's not necessary to learn, it can be a great way of understanding how complex languages can get and how computers are able to interpret that complexity.

Sources:
https://en.wikipedia.org/wiki/Malbolge
https://en.wikipedia.org/wiki/Beam_search
https://dev.to/viz-x/malbolge-the-programming-language-designed-to-be-impossible-1bl7
https://www.geeksforgeeks.org/machine-learning/introduction-to-beam-search-algorithm/
https://direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00346/96473/Best-First-Beam-Search
https://wiki.c2.com/?ProgrammingLanguageNamingPatterns
http://www.lscheffer.com/malbolge_spec.html
https://lutter.cc/malbolge/tutorial/cat.html
https://ctl.stanford.edu/memory-strategy-mnemonics
https://en.wikipedia.org/wiki/NOP_(code)
https://www.cs.auckland.ac.nz/references/macvax/op-codes/Instructions/mov.html

Mutation Testing for Dummies

Jami — Sun, 24 May 2026 00:34:42 +0000

Tests are important when it comes to implementing source code. Developers need ways to ensure the security of their source code as it becomes more complex. Increased complexity means that tests may become less capable of catching bugs. Mutation testing allows developers to test the weaknesses in their test suite, which shows what edge cases need to be handled and what constraints must be added to prevent farther bugs.

Mutation testing is a process developers use by creating bugs within their source code and running tests that should fail (failing tests mean a bug was found). When tests run, if the bug has survived, the tests meant to catch it were not thorough enough to handle certain edge cases. Mutation testing is classified as a white-box testing method which is best described as: a system that examines the internal functionality of an application. This is widely used in languages like Java and XML(a tool that stores and transports data). It's purpose is to find code that may not be nested properly, discover new errors, and to understand how errors spread within the application. The goal is to prevent these errors from happening again in the future.

Mutation testing tools are used mostly for continuous integration and continuous delivery. CI/CD is a modern practice of automated building testing and releasing applications. This operation entails committing code to a shared repository frequently. Typically CI/CD without Mutation Testing requires a waiting period. Usually wait times without Mutation Testing with CI/CD jobs are due to a weak test suite. Mutation Testing can make that process much more efficient due to a decreased wait time for CI/CD jobs to finish.

The first implementation testing (documented) was by Timothy Budd as part of his PHD study titled "Mutation Analysis" in 1980. It was originally proposed by Richard Lipton in 1971. Then in 2004, "Certess inc." added to much of the practice as part of hardware verification. Today, Mutation Testing is based upon two hypothesis; One being the Competent Programmer Hypothesis: this is where programmers write programs that are close to being correct. The other being The Coupling Effect: This is where simple mistakes can snowball into much more apparent and/or pervasive ones.

Mutation testing types can vary. One type of Mutation testing is called Value Mutation Testing. This is when values that are usually assigned to constants are changed to test whether tests fail or whether the mutations survive. Failing tests is a good thing, as it provides insight that the tests already implemented are thorough at catching bugs. Mutations surviving however, implies the opposite.

const num = 35;

changed:

const num = 3000005

The second type of Mutation Testing is Decision based. Decision based testing is when arithmetic operators are changed. Sometimes the changes can be slight, other times the changes can be apparent.

if(dog = cat)

changed:

if(dog >= cat)

Similar to Decision Based Testing, Statement Mutation testing is when one statement or variable name is replaced with another during reassignment. In this example giraffe is the variable that is being changed.

if(dog < cat)
  let giraffe = 10;
else
  let giraffe = 20;

changed:

if(dog < cat)
  let bunny = 10;
else
  let bunny = 20;

High Order Mutation Testing is when we change more than one single operation or value which can make it more difficult for tests to catch. These changes are usually too subtle to notice at first glance, however when you take a closer look you can see where the bug is.

let function (int a, int b){
 if (dog = 1):
 return cat < dog
 return cat > dog
}

changed:

let function (int a, int b){
 if (dog = 1):
 return cat <= dog
 return cat > dog
}

Mutation Testing can be simply implemented by first creating the source code. Once the code is created, inject mutants. Use one of the types of Mutation Testing to create small bugs that the test suite should hopefully catch. Next, run the tests. If a test fails on the line where the bug was created, then that test is solid. Otherwise, the bug survived and the tests are not thorough enough to prevent that bug from infecting the rest of the source code. Calculate how many tests failed and from there, rebuild the tests in accordance to any edge cases or general constraints that should be added.

The great thing about Mutation Testing is that it allows for more secure test updates. When a bug is not caught, developers can know exactly what to fix and how to make it more secure. Finding bugs that our unit tests can not find provides more efficient code. On the downside, it is very time consuming, and it is not available for Black Box Testing(evaluating functionality of an application without knowing it's source code). In addition to this, some mutations are too complex to debug, making it difficult to implement corrective code or test against mutations. In all, Mutation Testing is a great method to implement when looking to create more secure code and build an even more secure test suite.

(https://www.computer.org/csdl/journal/ts/2024/05/10472898/1VpY3do6cyA)
https://stryker-mutator.io/docs/
https://www.computer.org/csdl/journal/ts/2024/05/10472898/1VpY3do6cyA("IEEE Transactions on Software Engineering"; May 2024)
https://www.geeksforgeeks.org/software-testing/software-engineering-white-box-testing/
https://www.redhat.com/en/topics/devops/what-is-ci-cd("redhat.com"; June 10, 2025)
https://bell-sw.com/blog/a-comprehensive-guide-to-mutation-testing-in-java/
(https://www.geeksforgeeks.org/devops/what-is-ci-cd/)
https://www.diffblue.com/resources/what-is-mutation-testing/
https://en.wikipedia.org/wiki/Mutation_testing
(https://www.geeksforgeeks.org/software-testing/software-engineering-black-box-testing/)
https://www.sciencedirect.com/science/article/abs/pii/S0950584909000688
https://www.cs.cmu.edu/~ckaestne/pdf/fse20hom.pdf

Breaking Down Code

Jami — Mon, 20 Apr 2026 01:58:36 +0000

Disclaimer: I am a student coder for a coding bootcamp program, not an educator. My blog posts may come off as confusing however the entire point is me figuring out the answers to my own questions and proving myself wrong as I write. The full answer will never be given or explained well initially however as I write I will do my best to get to a suitable solution. Happy reading!

One of the lessons from this week that really stumped me went a little something like this...

// Memorize an expensive function's results by storing them. You may assume
// that the function only takes primitives as arguments.
// memoize could be renamed to oncePerUniqueArgumentList; memoize does the
// same thing as once, but based on many sets of unique arguments.
//
// _.memoize should return a function that, when called, will check if it has
// already computed the result for the given argument and return that value
// instead if possible.

My interpretation...

Create a function: Memoize
This function should only take primitive (aka simple) values as arguments. It should return a function that when called, will check if it has already computed the result and return it if it has.

Memoize is based on Once: A function that takes in another function and returns a new version of the function it takes in. It can only be called at most one time and any calls after that should return the original function. This means the code can only run once and should only have one solution.

We solved Once by first creating a new variable called alreadyCalled and setting it equal to false and another new variable called result. We then returned an empty function that determined if alreadyCalled was not false and instead was true, then apply the arguments to the given function and compute the result and set the answer equal to the result variable. After the function returns the result, set alreadyCalled to true and return the result of the function.

  _.once = function (func) {
    let alreadyCalled = false;
    let result;
    return function () {
      if (!alreadyCalled) {
        result = func.apply(this, arguments);
        alreadyCalled = true;
      }
      return result
    };
  };

In this code if there is already an answer then there is no need to run the return function, the result will automatically return as it is outside of those conditions. In any other case, if the result has not been computed, the computer will run the return function determining already called as true. Next the computer will apply the input arguments to the function using .apply and this which accesses the initial func parameter. Once the answer is produced the result will be set and alreadyCalled will be set officially to true. The result will be returned and the code will end.

How this applies to Memoize:
Memorize (a different function) is used to store the result of a function like the one above. Mem-o-ize is designed to check whether a result in Memorize has already been stored.

We start by making a memory variable within the Memoize function that will store the results of any function just like Memorize traditionally would.

 _.memoize = function(func) {

  const memory = {};

};

Say we have a function that takes 5 as an argument. The purpose of that function is to square the number 5 in this instance. The result would be 25. The way this would be stored in the memory object would appear like so:

{5: 25}

If 5 is used again as an argument in the future, then there will be a result of 25 again resulting in the memory object appearing like so:

{5: 25, 5: 25}

Memoize needs to check whether 5 has already been used as an argument and whether the results are the same as well. This would mean that there is a duplicate result which based on the tests we're given would not be ideal or necessary.

The next step in Memoize is to determine what to do if the arguments we are given are not string values. In order to check for duplicates we need these value types to all be the same. If there is a string '5' in the object but then a 5 in the object, it makes in more difficult for the computer to check for duplicate results in an efficient manner.

The part that stumped me wasn't necessarily how the function should work, but more so how JSON.stringify worked. JSON.stringify is meant to compute a specified parameters position into a string to make it easier for the computer to read and recognize. From what I've read, in this instance JSON.stringify would stringify the position of the argument, not necessarily the argument itself. If an argument of 5, 6, 7, 8 are entered then 5 would hold call position 0, 6 would hold call position 1 and so on using typical indexing. I couldn't understand why the position itself needed to be a string or how it made it easier for the computer to read. What I've learned is: Javascript naturally stores keys in objects as strings to make for a more stable key lookup. I had no idea. So to revamp everything I've said until now, what's actually going on is JSON.stringify is positioning the arguments given to the input function as their own object. Under the hood, this would appear as

{"0": 5, "1": 6, "2": 7, "3": 8}

What then happens is the function computes the action you are looking to do based on the given argument and it's position. When the function computes the computer stores it as so:

Computer Model:

{{"0":5}: 25, {"1": 6}: 36, {"2": 7}: 49, {"3": 8}: 64}

Mental Model:

{5: 25, 6: 36, 7: 49, 8: 64}

The true purpose of Memoize is speed. If the answer has already been created then it will be produced efficiently, otherwise Memoize will compute it itself and then return the result.

To complete this code we must create a variable that is set to utilizing JSON.stringify on the arguments that are input into the function.

 _.memoize = function(func) {

  const memory = {};

  return function() {

    const key = JSON.stringify(arguments); 

  };
};

Lastly, we create our condition. If there is a key and value already in the memory object, the value will be returned since the point of Memoize is to improve efficiency. If there is no key in the memory object that we created (aka if the memory is empty) a value for the stringified key variable that applies the argument on the function. Because the key has already been defined as the positioned arguments...

Ex: {"0": 5, "1": 6, "2": 7, "3": 8}

These will be our new keys and we can set the values as the result of completing the action on the argument via the function (Ex: squaring each argument) and we return the values in the memory.

 _.memoize = function(func) {

  const memory = {};

  return function() {

    const key = JSON.stringify(arguments); 

    if (!(key in memory)) {

      memory[key] = func.apply(this, arguments);

    }

    return memory[key];

  };
};

This lesson taught me more about how to use JSON.stringify, how it works and why it is necessary to update functions we have created in the past to improve efficiency for our code. Coding is all about efficiency and finding new pathways to limit as many bugs as possible. Thank you for reading and until next time!

This Weeks Lesson

Jami — Mon, 20 Apr 2026 01:00:45 +0000

If I have learned anything this week about coding javascript and debugging sites using developer tools, it's that I know nothing at all. I have somehow passed the bootcamp phase of the code camp I'm a part of. Week after week for 3 hours a day we sat on meetings learning everything from variables, to loops, to functions. I can tell you why loops are necessary in code. I can tell you that without them, coding would be very meticulous and messy and it would be very difficult to debug anything, however I am now learning loops can be just as messy.

This week we had a few lessons that were very difficult for me in which I could feel myself falling behind. One was the function of the underscore library and the importance of utilizing functions to run instruction specific code. I'm realizing there's something for everything. There is a setTimer function which takes in a parameter of a wait time in ms. There is a way to take the difference of values multiple array's and return the values that are reoccurring in each array all to be returned as a new array. To put it short, there are many different ways to do many different things.

Before I started code and realized what developers meant by it being a language I assumed code was mostly like simplistic math. I assumed it only had one way of solving and one solution. I'm now realizing there is a whole world of code. There are combinations of code I had no idea existed until a few days ago.

Here's an example:

Say you're given a list of people and they all have names and ages and that list goes on for miles. You're told you need to be able to sort this list in numerous ways whether that be from a - z, z - a, or some other way of sorting.

For this example we created a _.sortby function that could take in a collection (that list) and an iterator (whatever key in the list you're sorting). This stumped me for a while because the instructions declared that we have to find a way to figure out if the iterator is a string or whether it is something else. In no world would I have assumed that the iterator would be anything but a string. That's the thing, in coding you have to be able to look ahead in case there is a typo on the part of another developer who potentially forgot to include quotes around a word that we are using for lookup or in the case that there is no string at all. For this problem we sliced the list and used .sort and two parameters to sort the list in ascending order.

_.sortBy function(collection, iterator) {

return collection.slice().sort((a, b) => {

}

To specify what we wanted to sort in the list, we included conditions via an if statement. If the iterator itself was a function and already had the sort conditions specified (that being the key and the sort type) then we would invoke the function on the first parameter to the invocation of the second parameter to sort the list in ascending order. Otherwise, if iterator was a string, we would return the first parameter and call the key in the list (Ex: 'name') to sort the list in ascending order using bracket notation instead of function invocation.

_.sortBy function(collection, iterator) {

return collection.slice().sort((a, b) => {

if(typeof iterator === 'function') {
return iterator(a) - iterator(b);

  } else if (typeof iterator === 'string') {
    return a[iterator] - b[iterator];

}

})

}

This was our final solution. Before Friday I had no idea how to use .sort and I would have had trouble understanding why it needed to be used differently depending on whether a parameter acted a as a function or a string. Now, I can semi-confidently say that a - b is a sort type. It will always sort in ascending order. To invoke the iterator function on the sort type is to simply say what we need to sort in ascending order within the list. To use bracket notation on the sort type is to do the same thing. The syntax is just different depending on the type of value iterator entails, but .sort never really changes.

Looking back, there is not much account for how the code should run in the instance that name is not a string and was entered incorrectly or for many other instances like what would happen if iterator had no value at all and was undefined or null. However, that seems like a lesson for next week. For now I believe we did our best with the information we were given and the code still passed all the provided tests. That's all for now!