DEV Community: Max Feige

TypeScript 102 - Beyond The Basics

Max Feige — Wed, 23 Aug 2023 12:47:41 +0000

The seemingly endless sea of TypeScript tutorials you'll find online do a great job of providing resources to both beginners and advanced users, but what about those in the middle? If you know the basics but aren't quite at the advanced level yet, then this series of articles is for you. In it we'll be exploring some tools and techniques that'll take your TypeScript code to the next level!

This guide assumes that you're already familiar with the basics of TypeScript and JavaScript. You should understand the concepts of types, interfaces, the as keyword, functions, and classes, as we'll be building on all of these fundamentals.

Let's start in the shallow end: the building blocks TypeScript gives us and what we can do with them.

Union (|) and Intersection (&) Types

Unions and intersection types are incredibly useful for enhancing the flexibility of your code.

A union type, denoted by |, allows a variable to be one of several types. This is useful when we want our code to accommodate a variety of data types. Here's an example using interfaces:

In this case, a person is either a Teacher or a Coder. The work method, which is shared by Teacher and Coder, is valid since it's present regardless of which type person is. Methods specific to one interface, however, may not exist in person, and that's where TypeScript steps in to stop us from trying to use them. Without additional work, TypeScript will only allow us to use properties that it knows will exist.

We can also use unions with primitive types:

In this example, we're allowing myVar to be a number or a string. TypeScript ensures we can only use properties or methods common to all types in the union, thus preventing us from using the string-only method toLowerCase.

When we use a union, we're establishing that any variable assigned to our type is going to satisfy the properties of at least one of the provided types. TypeScript will then go further and only allow us to access properties and methods common to all types - at least if we don't give TypeScript more information to narrow the type with! Don't worry if that sounds complicated, we'll dive into narrowing shortly.

Next up is the intersection! Intersections, denoted by &, complement the union and allow us to merge multiple types into one. A variable declared using an intersection must have the features of all combined types. Let's illustrate this with an example:

As you can see, an intersection allows us to create a new type by combining the overlapping properties of both interfaces. Intersection types can be used with primitives as well, as shown here:

Since the primitive types string and number are mutually exclusive, an intersection is impossible. The intersection results in the type never, which we'll talk more about soon. For now, just know that it symbolizes a type that can't exist.

If we try to intersect two types with conflicting properties we're also greeted by never:

In this example intersection, id would be required to be both number and string simultaneously, which is impossible. TypeScript sees this and assigns it the type never, effectively preventing us from using our newly created type.

Overall, intersections allow us to construct complex types from simple building blocks, and TypeScript will ensure that any values we assign to an intersection satisfy all types in the intersection.

Utilizing both unions and intersections effectively gives you the ability to easily mix and match your existing types with ease, saving you the effort of manually creating similar types.

Type Narrowing

One of TypeScript's most important features is type narrowing, a process by which the type of a variable is (wait for it) narrowed using, for example, a conditional. This gives TypeScript more information about what type we're providing it. Let's expand on a previous example to see this in action:

Our function specialPrint takes an item, which is either a string or a number. The function will then check if item is a string and will use either toLowerCase or toFixed based on the result. Thanks to the conditionals the methods are contained in, TypeScript will recognize that the code can only reach these methods when item is the correct type and will bypass its limitations on methods that aren't shared between every type in the union.

Ever have a variable in limbo waiting for user input or for a network request to finish? These variables normally start out as undefined, which can be a common source of headaches for many JavaScript developers. TypeScript gives us the tools to tackle this issue by using a combination of unions and type narrowing. This approach helps us write code that's clean and bug-free!

In this example, any Person could be a Teacher, Coder, or null. Since null has no methods, we cannot directly call person.work(). Instead, we must ensure that person is not null with a simple conditional. Once we've done this, TypeScript recognizes that person is type Teacher | Coder and we're able to call the work method safely.

This is where the power of type narrowing really shines. By using type checks, we can ensure that our code behaves as expected and is free of runtime errors. This makes our code safer, easier to understand, and easier to maintain. There are many more ways we can employ type narrowing in TypeScript, but that's an article for another day. For now, just know that TypeScript has an eye on your conditional statements and will understand which types are possible within them.

Any, Unknown, and Never

TypeScript has a few special types: any, unknown, and never. Let's start by taking a look at any:

Thanks to any, the above code is perfectly acceptable and will not yield any errors! A variable of type any has the flexibility to be set to whatever value you want, and other variables of different types can be set to it without issue. In other words, TypeScript does no type-checking on a variable of type any. While you might occasionally want a variable to be treated like this, type-checking is one of the best reasons to use TypeScript in the first place. This means that it's usually best to use unknown instead.

Although you can set an unknown variable to whatever value you want, other variables cannot be directly set to it. Instead you must explicitly cast its type, like so:

Using unknown is preferred to using any because it encourages us to explicitly pick when and how we convert it to another type.
Finally, let's look at never:

The never type is restrictive in that it prevents the assignment of any values to it. Similarly, no other variables can be set to a variable of type never. This type symbolizes an impossibility; something that should never happen. One common place we may see never is in functions that should always throw errors and never return a value:

I've made a short summary chart for these three types:

All three of these serve distinct purposes, each with different balances between type safety and flexibility. While any provides maximum flexibility, it comes at the cost of losing the type safety benefits given by TypeScript. Because of this, you should instead use the unknown type and explicitly tell TypeScript to cast your variables. Lastly, the never type will always give us an error when we try to interact with it. We use never when we want to tell TypeScript that there should be no scenario in which an outcome occurs, and that you want an error to be thrown if it does. We'll go deeper into some advanced uses of never in future articles.

Literal Types

TypeScript also gives us literals, another powerful feature that represents exact values and can be a specific instance of a string, number, or boolean. Let's look at one:

Here we created a variable called userRole with the type "basic". Because of this, the variable myUserRole can no longer be assigned to any other string. A literal on its own doesn't seem that useful, but when combined with some of the other functionalities we've explored we can construct some useful types:

Through a combination of unions and literals, we've created a type that could have one of three possible values. This could come in handy!

When we create a variable with let or var, TypeScript typically assigns it a general type (like string, number, or boolean). Alternatively, if we declare a variable with const, TypeScript will assume that its type is a literal. Let's check out an example of this:

We can also tell Typescript to behave this way when declaring with let or var by using as const.

as const is a helpful way to make sure that your types are as specific as possible. Additionally, we can use as const on objects to ensure that the fields are specific:

Overall, literals are an excellent way to limit the values our variables can contain. You can see that as const has changed the type of our object's fields into literals. It's also added the keyword readonly, though. What's happening here?

Readonly

TypeScript introduces several new keywords, one of which is readonly. This keyword allows us to specify parts of an object as mostly unchangeable. Let's investigate:

Now TypeScript will give us an error whenever we try to change (or "write to") the id variable, hence the name readonly. The only time a readonly property can be set is during initialization, or when the object is created. This concept also applies to classes:

Just like with our interface example, we can't change the id field after it's been initialized. For a class, this means we can only change id in the constructor. After the constructor has finished executing, TypeScript will no longer allow us to change that field.

Finally, readonly can be applied to arrays:

This prevents us from adding, removing, or changing any element in our array, but we can still assign a new array to the variable containing it.

readonly is an excellent keyword to use in large codebases, as it allows you to explicitly choose when something should be observable but unchangeable. This bars people from accidentally modifying data they shouldn't be able to, which in turn prevents bugs and clarifies the intent of your code.

Conclusion

The features explained in this article are among the most frequently used in TypeScript, and by thoughtfully utilizing them yourself you can construct less error-prone systems and maintain JavaScript's inherent flexibility. Remember, TypeScript isn't about making your life harder! It's about making your code safer, more maintainable, and easier to understand.
As you continue to use and explore TypeScript, I encourage you to try out these concepts and discover for yourself how you can apply them to your own projects. In the next article, we'll dive deeper into some of the common utility types given by TypeScript. Stay tuned!

Bit Manipulation: Exploring A Lost Technique of Programming

Max Feige — Mon, 31 Jul 2023 12:20:33 +0000

In an era when processors were sluggish and memory scarce, programmers had to come up with ingenious little tricks to accelerate their software, the king of which was bit manipulation. Yet as technology has progressed, our faster processors and sophisticated programming languages have relegated these hacks to obscurity. Though they no longer offer the same tangible performance advantages, rediscovering them can enrich our perception of how logic and creativity exist in the world of coding.

We're set to take a deep dive into some of my favorite bit hacks, exploring and understanding their underlying mechanics. As we delve into the intricacies of each trick my hope is that you'll gain a richer understanding of what's happening beneath the surface of your code. At minimum I hope to install in you an admiration for the cleverness encapsulated in these hacks.
First lets take a quick review on how binary numbers work:

We'll talk about the specific bitwise operations we use for each problem, but feel free to reference this table or check the Wikipedia page page for more details:

Example Problems

Even Or Odd?

Every coder's journey starts somewhere, and often one of the first stops is the basic math problem: "Is this number even or odd?" It's a rite of passage, teaching some foundational concepts, providing some quick feedback, and being just fun enough to be engaging.
First the classic approach:

bool isOdd(int number)
{
    if(number % 2 == 0)
    {
        return false;
    }
    else
    {
        return true;
    }
}

In this version, we're checking if the number is divisible by two (the textbook definition of evenness) - no remainder, no oddness. But let's check out how a bit based solution works:

bool isOdd(int number)
{
    return number & 1;
}

Now that's an elegant solution! No comparison, division/modulo, or jump required. A simple AND that outperforms the conventional method with ease.

What our code is doing bitwise is checking if the final bit in the number is on. In the same way that we can know a number is odd in base 10 by considering the final digit (checking if it is 1,3,5,7, or 9), we can do so in binary - but here we only have two digits to consider. If the digit is 1 then we know it to be odd, otherwise it is even. This AND statement gives us the final bit, which yields us a 1 in the case the number is odd, and a 0 otherwise. Conveniently, most languages will implicitly convert those to true and false respectively. As an exercise, you can verify this solution works even using negative numbers in two's complement!

Determining The Sign of a Number

The challenge of identifying a number's sign is as ancient as it is pervasive. We often need to handle positive and negative numbers differently, requiring us to discern the sign of a given number. Let's first look at a simple modern approach.

int sign(int x)
{
    if(x < 0)
    {
        return -1;
    }
    else if(x == 0)
    {
        return 0;
    }
    return 1;
}

This is a standard solution that's quite simple to arrive at. It's also quite long and has some if statements. Next let's look at the fastest bit based version:

int sign(int x)
{
   return x >> 31;
}

Introducing The Right Shift Operator (>>): A shift operator is one the most simplistic operations our computer can do. It simply takes all of the bits in a number and moves them to the left. An arithmetic shift (the kind we use) also copies the neighbor bit when we add new digits. Let's look at an example:

00101010 >> 1  = 00010101 - move all of our bits to the right one space
10110101 >> 3  = 11110110 - move all of our bits to the left three spaces - note because a 1 was in the leftmost spot our 3 new digits to the left are also 1.

Remarkably simple isn't it? This solution relies on certain conditions to work: it requires the int to be 32 bits, and for the most significant bit (left-most bit) to represent the sign of the number. Given that most modern languages utilize the arithmetic shift, when a new bit is added to one side it replicates the adjacent bit. Thus, if x is negative, the resultant number will in binary be thirty-two 1s in binary, translating to -1 due to two's complement representation. If x is non-negative, then the leftmost bit is 0 and all new bits given by the shift operation also become 0, leaving us with 0. So, if x is negative this code returns -1; otherwise it returns 0. As compact and efficient as this solution may be, it's important to note its underlying assumptions and that it doesn't return 1 when the number is positive, unlike our initial solution.

Can we find a compromise? A method that's quick and succinct, and aligns with the output of our original code? With a few tweaks to our existing code we can:

int sign(int x)
{
    return x!= 0 | (x >> 31);
}

Introducing The Or Operator (|) - The OR operator combines the bits of two numbers, producing a new number with a 1 in any position where either of the original numbers had a 1. Let's look at an example:

11001100 OR (|) 204
01010101         85
---------------------------
11011101        221

Let's go over all three scenarios here:

x is positive: Then the left side of our OR becomes 1, and the right side becomes 0, resulting in 1.
x is zero: Then the left side becomes 0, and the right side becomes 0, resulting 0.
x is negative: The left side becomes 1, and the right side becomes -1, yielding -1.

However, like our previous solution, bear in mind this method hinges on the same set of assumptions about the language and hardware. While this approach might save us a few assembly instructions, it compromises platform-agnosticism. Therefore in the modern day or portable code, this solution is not advisable.

We can achieve a platform-agnostic result by utilizing comparison operators, yielding the same results as the original method

int sign(int x)
{
   return (x > 0) - (x < 0);
}

This solution does operate agnostically. I'll leave verification of this solution as an exercise to the reader - here's a hint: In most programming languages the boolean value true is converted to 1 and false is converted to 0.

Swap Two Numbers

Programmers love a good reshuffle! We may not always realize it, but every time we sort an array or a list we're engaged in a continuous process of swapping two variables. Let's recall the traditional way of swapping two numbers:

//setup
int a = 3;
int b = 5;

int tmp = a;
a = b
b = tmp;

Or in the context an a list:

int array[] = {a,b};
int tmp = array[0];
array[0] = array[1];
array[1] = tmp;

The typical swap sees us create a temporary variable to help a and b switch places. But what if we could avoid using a temporary variable? With integers we can use a nifty bit trick to swap them:

int a = 3;
int b = 5;
a = a ^ b;
b = a ^ b;
a = a ^ b;

Introducing The XOR Operator (^) - The XOR operator combines the bits of two numbers, producing a new number with a 1 in any position where exactly one of the original numbers had a 1. Let's look at an example:

11001100 XOR (^)  204
01010101          85
---------------------------
10011001          153

Now that looks quite cool! What's happening here is we are using the XOR operation to swap a and b. Lets break it down into a few different variables to see what's happening.

int a = 3;
int b = 5;
int r1 = a ^ b;
int r2 = r1 ^ b = (a ^ b) ^ b;
int r3 = r1 ^ r2 = (a ^ b) ^ (a ^ b) ^ b;

How does this simplify? Well the XOR operation has three useful properties we make use of: it's commutative (A ^ B = B ^ A), self-annihilating (A ^ A = 0), and has a zero identity (0 ^ A = A). Using these properties we can simplify the above:

int a = 3;
int b = 5;
int r1 = a ^ b;
int r2 = r1 ^ b = (a ^ b) ^ b = a ^ 0 = a;
int r3 = r1 ^ r2 = (a ^ b) ^ (a ^ b) ^ b = (a ^ a) ^ (b ^ b) ^ b = 0 ^ 0 ^ b = 0 ^ b = b;

And just like that we've swapped a and b all without a temporary variable. While this trick might not be useful in your everyday coding, it's a neat way to trade out an extra memory allocation for spending more CPU cycles.

Conclusion

So why don't we use these?

While these bit hacks are clever and may simplify the bytecode instructions, we rarely observe significant performance boosts implementing them today. This is primarily due to advancements in code compilers, and contemporary CPU features. Modern compilers are adept at uncovering and implementing these sorts of optimizations in your code, often without your explicit knowledge.

Furthermore, the complexity of today's CPU capabilities - such as branch prediction, SIMD, out of order execution, and instruction level parallelism to name a few - renders the performance of a program far more intricate than simply associating a particular cycle count with each instruction type.

Adding to their limited applicability is the fact that even if we wrote a function that managed to save 5 cycles each time its run, on a modern processor running at 3GHz, we'd need that function to execute several hundred thousand times to witness just a milliseconds worth of time savings. These aptly named micro-optimizations are rarely worth pursuing over macro level optimizations.

So when should we use these?

These cunning bit manipulation tricks lend themselves well to a style of programming I call cheeky coding. Rather than focusing on writing quality code, cheeky coding emphasizes showcasing your skill in a dazzling, if somewhat mischievous, manner. The allure of bit tricks is their ability to obfuscate your code, irk your coworkers, and reduce its readability, all while maintaining a thin veneer of utility. The only time that I might recommend using this style would be in an interview setting, where it could impress your interviewer, or annoy them - ideally both.

Exploring Gray Code – The Oddball Sibling of Binary

Max Feige — Thu, 25 May 2023 13:45:00 +0000

So hopefully we're all familiar with binary. Just in case, here's a review:

That's the standard way of counting in binary. And for computers, this is a perfectly logical and optimal system. Its the way most numbers on our computer work.*

But what if we had to manually track the bits ourselves using, say, a series of heavy switches to store a counter, like counting people who enter a store? Let's take a look at our hypothetical counter:

After some period of time, we've had several people come in. So by now, we have 7 people: Here it is stored in binary with our counter.

Suddenly we hear the bell ding; someone else has entered the store. So we should increase the counter to eight:

But man - that was hard! The effort required to flip multiple switches can quickly become overwhelming as the count increases. You might wonder if there's a more efficient method - and there is. It's called Gray Code.

Gray Code is an alternative binary numeral system where two successive values differ in only one bit, which means flipping just one switch to go from one value to the next. Here's what counting from 0 to 7 looks like in Gray Code:

Hopefully you were able to see the pattern - each time we flip the switch furthest to the right that will give us a combination we haven't used. You can read more about Gray Code here.

You might think that converting to and from Gray Code would be complicated - but thankfully some really smart people have created some clever algorithms that make it relatively straight forward. Here they are:

And that's how all we need!

Now, let's have some fun with Gray Code! As I demonstrated in my last article, you can create interesting images using the bit representation of numbers. Let's see how different bitwise operators - AND, OR, XOR - behave when applied to Gray Code:

Note: These are stretched a bit in the x direction, and I tend to like them that way. If you want to see the square images, resizing the images should give you something indistinguishable.

First we can compare normal binary to gray code.

Binary gradient based on x coordinate

Gray code gradient based on x coordinate

Now lets look at our bitwise operators. We'll consider two cases: First we convert our numbers to gray code, perform the bitwise operator, then convert them back to decimal.

Normal OR

Normal AND

Normal XOR

You might notice something peculiar about the image showcasing the Normal XOR operation. The apparent 'blockiness' isn't a result of image artifact compression or a mistake - it's actually an intriguing characteristic that arises from the Gray Code representation!

What's even more fascinating is that this Normal Gray Code XOR operation yields a result entirely equivalent to the binary XOR operation. This might seem counter-intuitive - I encourage you to take a look at the previous code and see if you can solve this puzzle. Unpacking these mysteries is part of what makings coding so exciting!

Now let's consider the concept of "casting". By casting, I mean performing our operation in Gray Code but not converting the numbers back to binary. While not typically used, this process can generate some fascinating patterns:

Inspired by this famous algorithm

Casted OR

Casted AND

Casted XOR

I find these patterns absolutely captivating. The process of casting in Gray Code produces an effect reminiscent of layering transparent images, creating a captivating visual representation of this weird binary sibling.

Demystifying Bitwise Operators: A Visual Perspective

Max Feige — Sun, 14 May 2023 20:52:12 +0000

Introduction

Have you ever found bitwise operators mysterious, despite their simple nature? Their function is clear, but their application and the impact they have on their inputs have eluded me. However, after my recent foray into GLSL shaders it dawned on me that they would be an excellent tool to visualize what these bitwise operators are actually doing. This led to my experiment of using shaders to generate images of bitwise operators.

Image Generation

Each generated image is a square with dimensions 1024×1024 pixels. The generation process involves evaluating each pixel individually. We take into account the current x and y coordinates, and apply our selected operation to them. This operation produces a result between 0 and 1023. To convert this result into a measure of brightness, we divide by the maximum possible value (1023). The process, in pseudocode, would look something akin to this:

Operators

Let’s dive into the world of bitwise operators: the | (OR) operator, the & (AND) operator, and the ^ (XOR) operator.

OR

The OR (|) operator looks at each bit in each number, and if it see’s any 1’s it writes a 1 to the resultant bit. Otherwise its a 0. Let’s illustrate this with an example:

010110 |
100100 =
110110

Not too complicated right? Let’s see what our operator looks like:

Wow! That’s a lot brighter than what I expected. Now there’s a few patterns here you may notice.

Our image seems to be sort composed of squares within squares. Each of these squares is the result of the X or Y coordinate having a bit changing from 0 to 1. The line you see in the middle horizontally represents our Y coordinate 10th bit turning from 0 to 1. Likewise the line vertically represents our X coordinate’s 10th bit turning from 0 to 1.

Let’s delve into a few other intriguing emergent patterns. Our image tends to get brighter as we go further up and further to the right. This is because, in general, the larger a number is the more bits it will have. In fact, the very last number in our range (1023) is composed entirely of 1’s — meaning no matter what number we OR with it the result will be 1023.

There’s also this sort of dark diagonal line going on. This line forms because of a few special mathematical properties. The first is that (x | y) will always result in a number greater than or equal to the maximum of x and y, i.e.

(x | y ) ≥ max(x,y)

To decrease a number is to take one of its bits and turn it from on to off. The OR operator is unable to turn bits off, so it cannot decrease any numbers and thus we must have a number that is larger (or at least equal to) both of the inputs.

So that dark diagonal line is actually forming when X and Y are nearly equal each other. In particular, when X and Y are equal we could say that (x|y) = X = Y. In other words, the diagonal line represents the numbers that affect each other the least in terms of the OR operation!

Next we have an image I found a bit more interesting:

AND

The AND (&) operator scrutinizes each bit in every number. If it spots any 0’s, the resultant bit is set to 0. Otherwise, the resultant bit is set to 1. For example

010110 &
100100 =
000100

Let’s take a look at how this operation appears

Again we see the pattern of square subdivisions – for the exact same reason too. Whenever the X or Y coordinate has a bit that flips, the bitwise operation changes drastically.

You’ll notice a plethora of darker regions in this image, in stark contract to the OR image. Yet these patterns appear for a similar reason.

Just like the OR operation we can come up with a mathematical equation

(x & y ) ≤ min(x,y)

Which means our AND operation only has one pixel at peak brightness – all the way at the top right corner!

Here we see the opposite diagonal pattern of the OR operator. Instead of being at a dark value on the diagonal we see a bright value! This is because the same mathematical fact that was true for OR is true for AND:

(x & y ) = x = y

The difference this time being that because AND has a tendency to decrease numbers, we see a bright line along the diagonal where it doesn’t decrease them.

In fact, if you were to pick out each point that is exactly on the diagonal, you would find that for both the OR image and the AND image that they have the same brightness!

XOR

The XOR (^) operator observes each bit in every number, and checks to see if they differ. If so, it writes a 1 to the resultant bit. Otherwise, it writes a 0. As an example

010110 ^
100100 =
110010

Let’s see XOR in action

This is the most complex of the three basic operations. We still have the same blocky section as before, but a much more interesting pattern

We have a dark diagonal and a light diagonal that cross through each other right in the origin. This is because, when x=y,

(x ^ y ) = 0
What about the light diagonal? Well for the XOR operator to produce a bright color, we would require the binary representations of our two numbers to be opposites – i.e. for every 0 in x there should be a 1 in y and vice versa.

We can also see that, looking at a single square, two of the four quadrants are darker than the others – the upper right and lower left quadrant. This is again because our numbers correlate more in these sections. In both quadrants, as X increases so does Y.

The XOR operator presents us some delightful complexity with its crisscrossing diagonals. It’s my favorite of the three by far.

CODE

You can find code for the shader’s here. Some slight editing will be needed to select the appropriate bitwise operator. Each shader is also available on Github.

Conclusion

I hope this visual exploration of bitwise operators has shed some light on their intricacies! I originally started on this adventure after reading about bithacks. I’ve crafted a series of other images from OR, XOR, and AND operators based on some different binary representations of numbers, which I’ll dive into on my next post. For now, here’s a sneak peek!