Coder Legion - Recent posts tagged compiler

Programming Is Magic: Bryan MacLee’s Journey Building scrml

Sun, 04 Oct 2026 22:32:36 +0000

Real developers. Real journeys. Real ideas.

Bryan MacLee is a truck driver specialising in the oil and gas industry, but programming is much more than a hobby for him. Driven by a deep love of JavaScript, frustration with web development's complexity, and an unconventional idea about how software should work, he is building scrml — an open-source compiled language for the web.

Interview & Story by Mehadi Hasan
CoderLegion Community & Editorial Team

It Started With “Hello World”

For Bryan MacLee, the answer to what initially attracted him to programming is surprisingly simple:

“Hello world.”

But explaining why programming became such an important part of his life takes a little longer.

Bryan describes programming as:

“The truest form of magic that we humans have ever created.”

It is a statement he stands by.

For him, programming is a recursively unfolding logic puzzle. You begin with a question, follow the logic, discover another layer, and continue uncovering how things work.

Even when a particular language or technology becomes repetitive, the underlying activity never really loses its appeal.

And that love of solving problems eventually led him somewhere unusual: instead of simply using programming languages, Bryan decided to build one.

A Truck Driver Building a Programming Language

Bryan works as a truck driver specialising in the oil and gas industry.

Outside that professional world, he spends his time exploring programming, JavaScript and the development of scrml.

He doesn't believe in the conventional idea of work-life balance.

As he puts it:

“Work and grow like progression is air. Laugh and love like the world ends tomorrow. To hell with balance.”

His oilfield work and programming are largely separate worlds. He doesn't claim that driving trucks has directly shaped his coding philosophy.

However, his enthusiasm for software and technology sometimes follows him into his day job.

One important difference is that Bryan has the freedom to choose what he works on and when.

He doesn't have a software manager demanding features or deadlines. He can explore ideas because they interest him, without having to turn every experiment into a commercial deliverable.

That freedom has helped him preserve something many developers struggle to maintain: his excitement about programming.

Loving JavaScript, but Disliking How It Handles the Web

Bryan's preferred programming language is JavaScript.

Not TypeScript.

JavaScript.

He loves how quickly he can write code, experiment and see whether an idea works. For prototyping, he considers it an excellent language.

But there has always been something that frustrated him.

JavaScript's role in interacting with the DOM and styling the web can become complicated, especially when building complex reactive components.

Bryan has experienced those frustrations firsthand.

Initially, he tried to solve them by building a library.

But as his ambitions grew, he began considering a framework.

That idea didn't last long either.

He felt frameworks could only go so far because they still operated on top of JavaScript, relying on conventions and abstractions that the underlying language itself didn't understand.

Around the same time, he developed an academic interest in Rust.

He admired its design, despite describing it as a beautifully hideous language.

That exploration prompted a question:

What if he could take some of the ideas he admired and build something around them?

The answer would eventually become scrml.

The Small Frustration That Started scrml

The origin of scrml wasn't a grand plan to create a new programming ecosystem.

It began with a small annoyance.

Bryan was working on a complex function and had written an expression whose result he wanted to reference.

But he couldn't think of a suitable name for a temporary local variable.

He sat staring at the cursor, increasingly frustrated.

Eventually, he typed a generic name and tried to move on.

But the interruption stayed with him.

He wanted to write an expression and reference its last fall-through value without having to invent a name for something that would only be used once.

As Bryan explains:

“I wish I could just write the expression and reference the last ‘fall-through’ value.”

And that was the moment scrml was born.

Not because he wanted to recreate Rust's enums or pattern matching.

Not because JavaScript state management was frustrating, although that was certainly part of his broader motivation.

It began because he wanted to stop naming one-time-use local variables.

Everything else, as he jokes, was a bonus.

What Exactly Is scrml?

scrml is a compiled programming language designed for web development.

It takes .scrml source files and generates HTML, CSS and JavaScript.

But its central idea goes beyond translating one language into another.

A single scrml file brings together:

Markup
Application logic
Styles
SQL

The compiler examines the whole program and determines how its parts relate.

It then separates client-side and server-side responsibilities and generates the necessary connections.

That includes server routes, fetch calls, CSRF handling and reactive dependency tracking.

Bryan wants developers to describe what their application should do without manually writing all the repetitive wiring required to make different parts communicate.

The language also introduces concepts that are central to his design philosophy:

First-class state
Exhaustive enum matching
State-machine constructs
Typed errors
A cohesive syntax across the application

Scrml is built to produce web technologies rather than operate as another framework sitting on top of JavaScript.

That distinction is fundamental to Bryan's vision.

One Language. One Compiler. One Understanding of the Program.

Bryan believes modern web development can become unnecessarily fragmented.

A typical project may involve separate tools for markup, styles, logic, compilation, server communication and other responsibilities.

Each tool sees only part of the source code.

That fragmentation is one of the problems he wants scrml to address.

His philosophy is:

“One walk. One language. One compiler that reads the markup, the logic, the styles and the SQL together, and actually understands how they relate.”

Because the compiler sees the whole program, it can generate connections that developers would otherwise have to create manually.

For example, when an application needs to communicate between the browser and server, scrml can generate the necessary routes, fetch calls and serialization.

Bryan also dislikes what he calls leaky abstractions and coloured functions.

His goal is to move responsibility into the language and compiler rather than leaving developers to manage conventions across multiple layers.

In his view, if the compiler understands the program, entire categories of mistakes can become impossible to express.

Making State a First-Class Concept

One of the ideas that influenced scrml was Bryan's exploration of state in functional programming.

He encountered a conventional definition of state as stored data, variables and conditions remembered by a program at a particular moment.

He wasn't satisfied with that explanation.

Instead, he developed his own description:

“A snap-shot of a data set, at the moment of observation.”

That led him to question why programming languages commonly provide logic and type systems but don't necessarily offer state as a first-class language feature.

Scrml incorporates state directly into its design.

For example, a state cell can be declared using a tag-like form and then referenced through the language's state syntax.

The compiler can track dependencies and manage the connections required for reactive behaviour.

Bryan is also working on stronger lifecycle and validation contracts, along with new approaches to state declarations.

These are part of his broader ambition to make the compiler responsible for more of the correctness guarantees.

Why Bryan Is So Serious About Dependencies

Bryan has a strong preference for minimal external dependencies.

He describes himself as someone who likes to build things himself and has a visceral dislike of not understanding the code in his own source tree.

He also sees automatically updating dependencies as a potential security problem.

That doesn't mean scrml prohibits importing external code.

Instead, Bryan wants imported code to enter through an explicit capability-gated mechanism.

His underlying principle is that a program should retain ownership and awareness of the code it uses.

He is particularly critical of developers introducing dependencies for trivial functionality.

His example is isEven.

For something that can be expressed through a simple mathematical operation, he questions why a developer would need to search the web for an external package.

For Bryan, fewer dependencies can encourage developers to understand what their applications actually contain.

Scrml includes a standard library intended to cover most common web application needs.

The goal isn't to eliminate useful code sharing, but to make dependencies more intentional.

“Assume the Compiler Works Perfectly”

Bryan's article Assume the compiler works perfectly addresses a particular challenge he has encountered when introducing scrml to other developers.

A couple of people had tried it and responded that nothing worked.

Bryan understands that this is a fair reaction, particularly when working with a new compiler.

But he wanted to ask a different question.

What if the compiler were already finished and worked perfectly?

Would developers actually want to write applications in scrml?

That is the question behind the article.

He isn't asking people to ignore technical problems or pretend the implementation is complete.

He wants to separate two questions:

Is the underlying language idea appealing?
Is the current compiler implementation mature enough to deliver it?

Building a compiler is a substantial undertaking, and Bryan knows the implementation still has work ahead.

But he wants feedback on the vision itself, not only on the current state of the tooling.

The Current State of scrml

Scrml is open source under the MIT licence.

At the time of Bryan's interview, the compiler was at version 0.8.0, running on Bun, and was not published to npm.

He has also reached an important turning point in its development.

The original TypeScript compiler prototype gradually became the product.

Over time, technical debt accumulated to the point where continuing to extend the existing implementation became increasingly difficult.

Rather than continuing to patch the old structure, Bryan has paused that compiler work and begun building a bootstrap approach.

The current TypeScript compiler is intended to compile a natively written scrml compiler.

In theory, this should help eliminate entire classes of bugs through construction rather than relying only on testing.

He is also working on standalone left-hand-side state declarations, as well as stronger lifecycle and validation rules.

It is a significant undertaking, but one that reflects his willingness to rethink the foundations rather than keep extending an architecture that no longer serves the language's direction.

Why He Still Loves JavaScript but Doesn't Want to Write It

Bryan's relationship with JavaScript is unusual.

He genuinely loves the language.

He appreciates its simplicity, speed and ability to support rapid experimentation.

But building scrml has changed where his excitement now lies.

He says that writing JavaScript has lost much of its appeal compared with the anticipation of writing applications in his own language.

He isn't less interested in programming.

His excitement has shifted from using existing tools toward creating a different way to work.

That enthusiasm is also what keeps him moving when scrml becomes difficult.

There are naturally moments of discouragement during a project of this size.

But the thought of eventually using the language he is building is a powerful motivator.

He intends to continue regardless of what others think.

Building a Language for More Than Himself

Bryan recognises that he doesn't need a production-level compiler simply to enjoy experimenting with his own ideas.

He could build a much smaller tool and still benefit from it personally.

But that's not the entire reason he's building scrml.

He believes the ideas have value for other developers.

He wants people to use it, question it, debate its assumptions and help improve it.

Scrml is released under an open-source MIT licence, and Bryan doesn't see it as something that belongs exclusively to him.

His ambition is to make it a shared project.

“I don't view this as ‘my’ language. MIT, open source, I gave it to the world.”

For Bryan, the value of scrml is directly connected to the number of people willing to engage seriously with its ideas.

He wants developers to challenge his assumptions and help make the language better.

What Would Success Look Like?

Bryan's definition of success is refreshingly modest.

He doesn't need thousands of users or a large company to feel that the project has been worthwhile.

His ideal milestone is simply hearing from one real developer who enjoys using scrml.

As he puts it, success would be receiving an email or message from someone saying:

“I enjoy writing scrml.”

That alone would make the work worthwhile.

He hopes scrml may eventually stand alongside other interesting programming languages, but he doesn't measure its value only through popularity.

The immediate goal is to build something genuinely useful and invite other developers to help shape it.

The Freedom to Keep Programming for the Right Reasons

One of the most interesting parts of Bryan's story is that he hasn't followed the conventional professional software-development route.

He isn't building scrml because an employer assigned it to him.

He isn't chasing a job title or trying to meet a commercial delivery deadline.

He codes when and what he wants to.

That freedom has helped him avoid becoming burned out or jaded about programming.

He also doesn't force himself to read documentation or follow technologies that don't interest him.

Instead, he can focus deeply on the ideas that capture his attention.

That doesn't mean the journey is free of frustration.

Building a programming language is difficult, and Bryan is candid about the challenges.

But his motivation comes from genuine curiosity rather than external pressure.

It is a reminder that unconventional paths can provide their own advantages.

Advice for Developers With Unusual Ideas

Bryan's advice to someone with an unconventional programming idea is direct:

“If you have an idea, and you think it is worth attention. Scream it from the rooftops.”

He doesn't believe that a lack of a traditional background, job title or established resources should automatically stop someone from pursuing an interesting idea.

Ideas should be exposed to discussion.

They should be questioned.

They should be challenged.

And sometimes they should be corrected.

Bryan sees correction as an opportunity rather than something to fear.

The worst outcome, in his view, is that someone points out where your assumptions are wrong.

That is far better than allowing insecurity to prevent you from trying.

From Truck Driver to Language Creator

Bryan MacLee's journey is not a conventional story about becoming a software engineer and climbing a corporate career ladder.

It is about someone who loves programming enough to question the tools he uses and attempt to build something different.

His journey began with JavaScript, frustration with web development's complexity, curiosity about language design and one seemingly insignificant problem: naming a temporary variable.

That small frustration grew into scrml, a compiled language with ambitions around state, type safety, application structure and compiler-driven correctness.

The implementation is still evolving.

The architecture is being reconsidered.

And the project needs developers willing to test, question and contribute.

But Bryan's motivation remains clear.

He isn't building scrml simply to prove that he can build a programming language.

He's building it because he believes programming can be made better — and because the act of creating software is, to him, one of the most remarkable things humans have ever learned to do.

About Bryan MacLee

Bryan MacLee is a truck driver specialising in the oil and gas industry and an independent programming-language developer.

He is the creator of scrml, an open-source compiled language for web development that generates HTML, CSS and JavaScript.

His preferred technologies include JavaScript, HTML and CSS, and his interests include language design, compiler development, state management and reducing unnecessary complexity in web development.

Connect with Bryan MacLee on CoderLegion.

Bryan's story is a reminder that a good idea doesn't need to come from a conventional career path.

Sometimes it starts with a simple frustration — and the willingness to ask:

Interview & Story by Mehadi Hasan

CoderLegion Community & Editorial Team

Why C++ Compilers Prefer Performance Over Safety Checks?

Fri, 20 Jun 2025 09:24:12 +0000

C++ is a language synonymous with performance, control, and portability. For decades, it has powered the world's most demanding software systems, from operating systems to game engines and real-time trading platforms. At the heart of its power lies a controversial feature: undefined behavior (UB). This feature, or rather lack of behavior definition, has led to immense performance gains but also to programming pitfalls. When modern C++ compilers like GCC and Clang prioritize performance, they do so by aggressively assuming that undefined behavior never occurs. In this article, we will explore why these compilers make such design choices, the benefits and trade-offs involved, and how developers can harness these tools responsibly.

1. The C++ Design Philosophy: Trust the Programmer

One of the key tenets of C++ is that it "trusts the programmer." This trust is not blind; it is intentional and foundational. Unlike languages like Java or Python that emphasize safety and abstraction, C++ offers low-level memory and hardware access. It does so while striving for zero-overhead abstractions. The premise is that a knowledgeable programmer can write highly efficient code if the compiler doesn't impose runtime safety checks that might slow execution.

Control and Efficiency

C++ gives developers precise control over resource management. You decide how memory is allocated, how objects are constructed, and when resources are released. This fine-grained control enables performance tuning at a level unmatched by most high-level languages.

No Built-in Safety Net

By default, C++ does not include bounds checking, null pointer validation, or automatic garbage collection. This lack of safety net is a double-edged sword. On one side lies blazing speed and fine control. On the other, the danger of undefined behavior.

2. What is Undefined Behavior?

In the context of C++, undefined behavior refers to code that does not have a well-defined effect according to the C++ standard. When such code is executed, anything can happen. It may crash the program, produce unexpected results, or appear to work fine (only to break later).

Common Sources of UB

Dereferencing null or dangling pointers
Accessing array elements out of bounds
Using uninitialized variables
Violating strict aliasing rules
Shifting integers by more than their width
Modifying a variable more than once between sequence points
Invoking functions through function pointers with the wrong signature

These are not bugs that merely produce wrong results; they allow the compiler to assume they never happen.

3. Why Compilers Exploit Undefined Behavior

Both GCC and Clang are highly optimizing compilers. They use undefined behavior as a license to transform code under the assumption that such errors never occur. This leads to several advantages:

a. Dead Code Elimination

Consider the following:

if (ptr != nullptr) {
   *ptr = 10;
}

If the compiler determines that ptr is never null (or that dereferencing null is UB), it might remove the check entirely, resulting in more streamlined code.

b. Loop Optimizations

UB assumptions allow the compiler to:

Unroll loops
Perform strength reduction
Vectorize operations for SIMD instructions
Parallelize independent iterations

c. Constant Folding and Propagation

If a branch or operation leads to UB under certain conditions, compilers may discard it entirely or simplify control flow under the assumption that such branches are never taken.

d. Register Allocation Improvements

Assuming UB allows for more flexible reuse of registers, reducing memory access and increasing pipeline throughput.

4. Benefits of This Approach

4.1 Performance

By ignoring checks and relying on the programmer's correctness, the compiler produces leaner, faster machine code. In performance-critical domains (e.g., embedded systems, high-frequency trading), even a 1-2% gain can be significant.

4.2 Simpler Compiler Internals

When the compiler is allowed to assume certain operations never happen (like null pointer access), it simplifies the internal logic for code generation and optimization passes.

4.3 Portability

This model ensures the same code can run efficiently across different platforms without runtime dependencies like garbage collectors or VM-based safety checks.

4.4 Greater Flexibility for Developers

Developers who understand their system well can fine-tune performance and optimize memory usage, trading safety for precision when necessary.

5. The Cost: Dangerous Flexibility

5.1 Debugging Nightmares

Because UB can manifest unpredictably, bugs are often hard to detect. Code that works on one compiler version may break on another. Debuggers might show misleading or inconsistent information when UB is triggered.

5.2 Security Vulnerabilities

Many buffer overflows and privilege escalation exploits originate from UB that goes unchecked during development. Attackers exploit these flaws to insert malicious code, steal data, or crash systems.

5.3 Non-deterministic Behavior

A program might behave differently on each run or platform due to optimizations exploiting UB. This leads to issues in testing, especially in distributed or multithreaded applications.

5.4 Loss of Portability

Code relying unknowingly on UB may work on one architecture but fail on another. For example, pointer alignment or endianness assumptions may cause subtle and hard-to-detect issues.

6. Mitigation Strategies for Developers

6.1 Use Static Analysis Tools

Tools like Clang-Tidy, Cppcheck, and Coverity help detect UB patterns in source code before runtime. They analyze control flow, memory access patterns, and data usage.

6.2 Enable Compiler Sanitizers

Compiler sanitizers are invaluable for catching UB during testing:

-fsanitize=undefined: Catches most UB issues like invalid casts or pointer arithmetic
-fsanitize=address: Detects heap buffer overflows, use-after-free
-fsanitize=thread: Catches race conditions in multithreaded programs
-fsanitize=leak: Helps track memory leaks

6.3 Adopt Safe Subsets

Frameworks like MISRA-C++ or AUTOSAR C++ define subsets of the language that eliminate or constrain UB-prone features. These are essential in safety-critical industries like automotive and aerospace.

6.4 Use Modern C++ Features

Prefer smart pointers (std::unique_ptr, std::shared_ptr), std::optional, std::variant, std::array over raw pointers and C-style arrays. These features enforce safer access and clearer intent.

6.5 Enforce Code Reviews and Testing

Robust peer reviews and extensive unit/integration testing help catch unintended UB before code reaches production.

6.6 Leverage Formal Verification (Advanced)

For critical systems, formal methods can be used to prove the absence of UB under all conditions using mathematical techniques.

7. Why Not Just Eliminate UB?

Eliminating undefined behavior would fundamentally change what C++ is:

More runtime checks would degrade performance.
It would become more like Java or Rust.
Backward compatibility with decades of C/C++ code would break.

UB is a deliberate, though controversial, part of the design. It is the price for raw power and flexibility.

Languages like Rust take a different path: they eliminate most classes of UB at compile time through strict ownership and borrowing rules. But this comes at the cost of a steeper learning curve and more restrictive coding patterns.

C++ allows expert programmers to write fast code with minimal abstraction costs, but the responsibility lies with the programmer to avoid UB through discipline and tooling.

8. Real-World Use Cases Embracing UB for Speed

8.1 Operating Systems

Linux kernel code is filled with performance-critical sections that rely on UB being carefully avoided but never checked. Kernel developers rely on strict coding guidelines and peer review to manage UB risk.

8.2 Game Engines

Engines like Unreal Engine are written in C++ with heavy use of UB-ignoring constructs for maximum speed. Real-time rendering and physics engines must meet frame deadlines every few milliseconds.

8.3 Trading Systems

Low-latency trading platforms depend on compiler-optimized binaries where every nanosecond counts. Programmers in this domain carefully avoid UB through disciplined coding and extensive testing.

8.4 Embedded Systems

In microcontrollers and IoT firmware, memory and processing power are limited. Developers must write tight, efficient code and often disable runtime checks, accepting the trade-offs of UB.

8.5 Scientific Simulations

High-performance computing (HPC) relies on C++ to run simulations on massive datasets. UB assumptions allow compilers to fully exploit hardware capabilities.

9. Compiler Flags That Matter

GCC and Clang both offer many flags to control optimization and UB behavior:

-O2, -O3: Enable aggressive optimizations
-fstrict-aliasing: Assumes pointers don’t alias unless explicitly cast
-fno-strict-overflow: Prevents assuming signed integer overflow is UB
-fsanitize=: Enables various runtime checks
-Wall -Wextra: Turns on helpful warnings
-pedantic: Enforces strict standard compliance

Recommended Combinations

For development:

g++ -O0 -g -fsanitize=undefined,address -Wall -Wextra

For production:

g++ -O3 -fstrict-aliasing -fomit-frame-pointer

10. Conclusion: Master the Power, Respect the Danger

C++ gives you a powerful toolset, but with it comes responsibility. GCC and Clang prioritize performance because that’s what the language promises: speed without overhead. Undefined behavior is not a mistake in the spec; it's a contract with the programmer. The compiler trusts you not to invoke UB, and in return, it gives you unmatched performance.

To use C++ effectively:

Understand the risks of undefined behavior
Use the right tools to catch it early
Write clean, testable, standards-compliant code

In the world of systems programming, performance often trumps safety—but with the right knowledge and practices, you don’t have to choose between them.

Final Thoughts

While undefined behavior may seem like a flaw, it is in fact a feature that empowers developers to write some of the fastest code in the world. If used with care, and backed by tooling and discipline, it allows C++ to remain at the forefront of high-performance software engineering.