DEV Community: Lori-Shu

The Magic of Radix Sort

Lori-Shu — Mon, 29 Jun 2026 16:15:24 +0000

Radix Sort is a sorting algorithm which does not rely on comparison and achieves highly optimized time complexity of O(n). Although it is not suitable for numbers containing too many digits, we developers can leverage its speed to solve specific problems.

The genius design of Radix Sort is that it exploits the fact that a single digit has only 10 possible values (zero to nine). First, it initializes ten "buckets." Each one is designed for storing the numbers that have the corresponding digit. Second, Radix Sort uses the buckets to sort the input, which is putting the numbers in the bucket with their digits. This process has to consider the digit from the least significant digit (LSD) to the most significant digit (MSD) in order to guarantee the sorting stability and the complexity. Then the algorithm repeats the process until the sorting of the most significant digit is done. While at every cycle Radix Sort writes back the numbers to the original array, at the next time that it scans the array from the beginning, it preserves the results of the previous cycle. With this operation, the numbers which have the same lower digits won't change order unless some of them have bigger high digits and get placed to larger bucket in the remaining cycles. In addition, if we want the "bucket" to work well, we usually make it a queue so that we can push and pop elements in a FIFO (First-In, First-Out) order to maintain stability. Otherwise, we could use a standard vector and perform the write-back in reverse order.

Insight: I'm impressed by the optimized O(n) complexity of Radix Sort. It turns out that if we abandon the comparison model, the optimization of sorting algorithm can go further. For memorizing, I think it is better to emphasize the concept of "bucket" and "non-comparison-based sorting."

The Complexity of UI Layout

Lori-Shu — Sat, 27 Jun 2026 15:48:59 +0000

For backend developers like me, handling the widget layout of UI is a burden. In general, there are two mainstream layout strategies: absolute positioning and relative positioning. Frontend engineers leverage these strategies to create magic. In order to simplify and visualize the layout, developers came up with some great tools like the "DOM Tree" in HTML and anchoring and docking mechanisms in UI libraries. These tools and designs make the code logically look like the output UI, which makes it easier for developers to bridge the gap between programming abstractions and visual implementations.

Insight: In my experience, we can also leverage the decoupling idea in UI sector—treating components as independently as possible. This structural arrangement improves maintainability and accelerates the product development in the long term.

The Characteristics of Existing Graphics APIs

Lori-Shu — Fri, 26 Jun 2026 15:51:36 +0000

The Graphics APIs are responsible for connecting high-level code to drivers (one kind of low-level software which controls the external hardware). The quality and efficiency of Graphics APIs are vital to building advanced graphic environments and applications. We could classify these APIs into two kinds: platform-specific APIs and cross-platform APIs.

Platform-specific APIs are usually the most efficient APIs on the platform. They conventionally are developed along with the system development process so that they can interact with the operating system seamlessly. In addition, hardware manufacturers are willing to support them with the highest priority. Nowadays, DirectX series are the first-class APIs on Windows, which power most existing games. Metal is the current official API on macOS; however, things become far more interesting on Linux.

Cross-platform APIs are those which are capable of running on multiple platforms. A fact is that the cross-platform APIs are almost all designed for Linux at first and they are in fact the first-class APIs on Linux. However, because of the "open source" root of Linux, the APIs are able to run on other platforms, requiring minimal effort from system developers. OpenGL and Vulkan are the prominent implementations built by the Khronos Group. OpenGL is older, less efficient on large applications while the abstraction is higher and easier to use. Vulkan is more advanced with modern graphic features while the abstraction is more sophisticated and takes a lot of work to integrate in high-level applications.

Insight: Currently, the axiom is that a Graphics API cannot be both the most efficient and cross-platform. We may expect Vulkan to be the game- changer.

How Does the Backpressure Mechanism Work in mpsc::channel?

Lori-Shu — Wed, 24 Jun 2026 16:02:51 +0000

There is a powerful mechanism called "backpressure" derived from mpsc::channel. Alongside the function of data transfer, we could also utilize the channel with this mechanism to achieve a specific effect.

"Backpressure" relies on the async runtime. When a bounded channel is full, the sender will suspend the current task and yield control back to the async executor until it becomes ready again. This only works in an async context. Otherwise, the sender will just block. How can we use the phenomenon? In my experience, this can be used to automatically suspend background tasks. In most cases, the data flows in one direction. Once we control the consumer at the endpoint, the tasks along the entire pipeline are gracefully suspended. This can save a lot of work if we want to temporarily stop the consuming process and the upstream tasks. Symmetrically, it works in the scenario that we make the producer side stop sending.

Insight: There are many elegant optimizations leveraging the side effects from the original action. In addition to "backpressure", I have encountered mechanisms like storing information in the unused bits of a chunk of memory, storing static assets in the static space of an executable file etc.

What Do I Know about Gradle?

Lori-Shu — Tue, 23 Jun 2026 16:28:37 +0000

Developers starting their careers with Java must have encountered the package manager—Maven. The software has become the standard for developing Java projects. However, have you ever heard of another build tool for Java? Gradle is capable of managing Java projects as well.

Gradle maintainers describe it as "a highly scalable build automation tool designed to handle everything from large, multi-project enterprise builds to quick development tasks across various languages." I am going to talk about how it interacts with Java.

Build Acceleration
The architecture of Gradle enables it to build with cache. If some parts of the code didn't change since the last build, Gradle will reuse the build files that correspond to the unchanged code. This significantly reduces the build time compared to building from scratch. The design is similar to another build tool "cargo" which is contained in the Rust toolchain.
Dependencies Management
Gradle supports downloading dependencies from a central repository just like Maven. Although it is convenient, it takes a lot of work for Maven to make it great. The burden of handling dependency conflicts is a nightmare for developers. Gradle tried to absorb the experience of Maven. It employs DSL (Domain-Specific Language) script to declare project metadata, dependencies etc. Originally, it corresponded to Groovy DSL (build.gradle). Iterating to modern version, it is taking a transition to Kotlin DSL (build.gradle.kts). Compared with powerful but old XML solution of Maven, Gradle achieves more clear declaration and less boilerplate code.
Remaining Limitations
Despite the fact that Gradle gained so many optimizations, there are remaining defects. First of all, the core of Gradle is written in Java so that it needs a JVM to run. Java developers all know that not only is JVM one of the most powerful features of Java but also a drawback when it comes to distribution. The user side often doesn't have a JRE or JDK installed and the JVM can make a distribution pack huge. Another problem I have encountered is the default wrapper configuration. In order to unify the Gradle version especially for Android projects, Gradle makes the wrapper configuration default but it is a pain in the cases that I just don't want to automatically download another version of Gradle.

Insight: Gradle currently supports many languages including some outside the JVM ecosystem. I recommend Java developers to try switching the long term supported projects from Maven to Gradle.

Design Patterns of Software Architecture

Lori-Shu — Mon, 22 Jun 2026 15:23:29 +0000

Let's talk about Design Patterns. Design Patterns are special structures applied to code base. These unique structures are efficient and elegant as long as developers use them in the fields that they are good at. Common Design Patterns and their use cases are arranged as follows:
Observer Pattern: The Observer Pattern allows objects (observers) to subscribe to a subject, so they are automatically notified of any state changes. Observer Pattern is used in products like message queues which has to broadcast messages to all the message subscribers.
Strategy Pattern: Strategy Pattern separates strategy code from certain client code, leading to convenient switch of strategy. Strategy Pattern makes strategy code run outside client (e.g., compiling to different executable files), which achieves low coupling. Programs like browsers which support plugin systems are using this model.
Template Pattern: This model encourages developers to extract abstract classes or interfaces so that we improve the reusability of code (often written in child classes or interface implementations). Java programmers are familiar with this model because Java uses abstract classes and interfaces everywhere.
Adapter Pattern: Sometimes we want classes with different interfaces to work together. Adapter Pattern defines adapter interface extracting the common "traits" of these classes. The abstraction is capable of calling methods of different classes by identical interface. The famous JDBC (Java Database Connectivity) is a demonstration of Adapter Pattern. Adapter Pattern is good at maintaining compatibility. No matter whether the implementation is new or old, as long as it implements the interface, the code will always work.
Decoration Pattern: This pattern prefers composition rather than inheritance. Each time the type needs a new function, we add new member fields rather than create child class to extend its responsibility. Rust enforces composition over inheritance at the language level, which significantly reduces the dependence complexity and is proved to be ideal for writing clear-minded code in practice.

Insight: Even though the benefits of these Design Patterns are tempting, experienced developers only apply them in suitable cases. The trade-off mindset must always be kept in mind.

Position Calculations in Two-Dimensional Arrays

Lori-Shu — Sat, 20 Jun 2026 15:56:11 +0000

I keep falling into the same trap: coordinate calculations. I'm here to record some of the lessons with possible solutions which could solve or relieve some of the traps.

Firstly, how do we choose the coordinate axes? When we take math classes, professors often draw the x- and y-axes with the origin located at the bottom-left corner; x goes right and y goes up. This is intuitive but we need to switch our mindset when we are in programming. We still consider a two-dimensional array in such axes only if we can fit the dimensions. For example, an array a[3][4] has three elements in the first dimension and four elements in the second dimension. If we view it as a 3×4 array, the first dimension is mapped to x while the second dimension is mapped to y. If we view it as a 4×3 array, the first dimension is mapped to y while the second dimension is mapped to x. Either layout is valid only if it remains consistent with that mapping. After fixing the axes, we should consistently follow the same mapping whenever we access the array. In order to make the variables more readable, sometimes we use names like "row" or "col". Never mix "x/y" and "row/column" terminology. Just pick one. The code tends to become a disaster when I mix them together.

Secondly, how do we calculate a point from other points? In many cases, we determine the position of a point through linear combination of other points. For example, the midpoint between two points is given by 〖(pos〗_2+〖pos〗_1)/2. However, when pos1 is the origin, I often neglect it in subsequent calculations, leading to incorrect results. To avoid that, we should understand the position formula and the idea of relative position. Every coordinate is ultimately defined relative to the chosen origin. However, when we calculate the middle point between two points, the midpoint is defined relative to the two endpoints rather than the origin.

Insight: Handling dimension mappings and relative positions is a common source of bugs in programming. I hope that "Be consistent with the coordinate system you have chosen." and "Understand what a formula actually represents geometrically." will not bother me again in the future.

Understanding Recursion from Hanoi Problem

Lori-Shu — Fri, 19 Jun 2026 15:30:18 +0000

The algorithm of solving Hanoi problem is often used to demonstrate the recursive idea in programming. Frankly speaking, recursion often manifests itself as a function calls itself. With that structure, recursive functions should always encompass the termination logic with respect to the base case. Otherwise, they can't stop and will end up throwing out "OOM" (Out Of Memory). The reason why we can make Hanoi problem a recursion is that every step of Hanoi is related to the previous step except for the first step. For example, the problem of size four can be seen as one process moving the top three disks to the auxiliary pillar. Then we execute the process moving the biggest disk to the target pillar. At last, we move the three to the target pillar. The last step is symmetrical to the first because moving the top three to an empty pillar is logically the same as moving to the pillar having the biggest disk. This characteristic determines that Hanoi can be represented by recursion.

Insight: Recursion is a classic programming idea. We use it to solve problems and reduce redundant code. However, when we make mistakes like forgetting the termination or naively force-fitting the idea, it is painful.

The Talent Flow Within Artificial Intelligence Companies

Lori-Shu — Thu, 18 Jun 2026 14:39:25 +0000

As one of the most rapidly evolving industries today, the artificial intelligence sector sees companies aggressively recruiting researchers and engineers renowned for their exceptional talent. Consequently, top-tier minds in this field have become the center of intense global attention.

In this landscape, OpenAI acts as a foundational talent pool. Many engineers who launched their careers there have since departed to create groundbreaking AI products. For instance, Dario Amodei, the CEO of tech unicorn Anthropic, was formerly a researcher at OpenAI. Similarly, Ilya Sutskever, widely recognized as a core architect of GPT, left OpenAI to co-found a new venture named Safe Superintelligence. Both tech leaders departed due to concerns that OpenAI’s commercial trajectory might pose a serious threat to humanity. Driven by this insight, they have pursued alternative paths to AI safety: Amodei pioneered the concept of "Constitutional AI," while Sutskever aims to solve safety challenges before achieving artificial general intelligence.

Google has similarly nurtured an impressive roster of AI pioneers. Among them is Pete Warden, who was deeply involved in building TensorFlow, a powerful toolset for AI development. Warden continues to push the boundaries of AI deployment on edge devices (such as mobile phones) after leaving Google to start Moonshine AI. Another notable Google alumnus is Noam Shazeer, co-author of the revolutionary "Transformer" architecture. Shazeer initially left Google to found Character.ai, later returning to spearhead the development of Gemini. In a recent turn of events, he departed Google once again to join OpenAI.

Insight: Technology giants are locked in a fierce talent war, willingly absorbing immense financial costs to secure top minds and gain a competitive edge in the AI race. However, these stories demonstrate that these elite tech talents are not merely driven by profit or progress at all costs; many possess a profound sense of responsibility toward humanity and have the conviction to act on their ethical principles.

Notes on Types of Graphs

Lori-Shu — Mon, 15 Jun 2026 15:32:37 +0000

Graphs are important data structures used to implement algorithms. There are many types of graphs. The following are my thoughts on the definitions of these types:

Graph (with no modifier): A set consisting of vertices and edges.

Connected Graph: A graph where every vertex can reach any other vertex through a path.

Complete Graph: A graph where every vertex has an edge connecting to every other vertex.

Directed Graph: A graph where every edge has a direction.

DAG (Directed Acyclic Graph): A directed graph where the edges do not form any cycles.

Tree: A tree is a data structure which is a subset of graphs. It consists of vertices and edges where every vertex can reach all others, and the edges do not form a cycle.

Spanning Tree: A spanning tree cannot stand alone; it is derived from a parent graph. It is a tree constructed by keeping all vertices and deleting some edges from the parent graph.

Insight: Sometimes these graph types can be difficult to memorize, so it is necessary to review them once in a while.

Has the x86 Instruction Set Already Lost the Race?

Lori-Shu — Sun, 14 Jun 2026 14:29:33 +0000

At Computex this year, Nvidia launched yet another amazing product: the RTX Spark chip, which derives record performance from the ARM instruction set. Looking back, this transformation started with Apple, which executed its transition from x86 to ARM smoothly, thanks to its centralized ecosystem and substantial cash flow support. Then came Qualcomm, which stepped into the PC market by leveraging its massive accumulation in the smartphone market. A prime example is the Snapdragon X Elite, which is based on ARM as well. As consumers who have been using x86 chips for years, we may wonder, "What is Intel doing to preserve the realm of x86?"

In fact, they have made a lot of changes, but the world is still running toward the realm of ARM. In order to radically throw away legacy instructions in x86, Intel started an internal project called "x86S." However, analysts at Intel estimate that products built under this new project will inevitably be unpopular due to declining compatibility, leading to the loss of even more critical market share. Consequently, they announced the cancellation of "x86S." Intel is now focusing on chip manufacturing, which is said to be its unshakable core competence in the new era. We can't say x86 has lost the game just yet, as Intel is actually working on things like pushing developers to deprecate old software dependencies. However, the trend is obvious. People and big tech companies are embracing ARM.

Insight: From an objective standpoint, some may be confused by the series of actions that Intel has taken. What lies beneath could be the ultimate result of dirty business and political games.

Reducing Hard Problems

Lori-Shu — Sat, 13 Jun 2026 12:12:21 +0000

Reduction is a technique that developers often derive from years of experience. The deeper I dive into programming, the more frequently this concept surfaces. Take two of the most well-known algorithms, Merge Sort and Quick Sort, as examples. Both algorithms are based on the core philosophy of "divide and conquer." The "divide" step is a classic reduction process that transforms a large, complex problem into several smaller, relatively simple sub-problems. It is well-established that divide-and-conquer approaches frequently outperform naive strategies that attempt to solve the original problem directly; both Merge Sort and Quick Sort deliver an optimal average time complexity of O(N log N). This principle of reduction is equally vital in system architecture design. For instance, distributed computing frameworks like Apache Spark and Hadoop fundamentally split massive computational and storage tasks into tiny pieces, processing them in parallel before aggregating the final results.
Insight: Reduction is an incredibly versatile technique. Not only can we use it to solve micro-level problems like algorithm design, but we can also leverage it to architect large-scale cloud services.