DEV Community: Aswin M Rajeev

When Should Software Refuse to Continue?

Aswin M Rajeev — Sat, 29 Aug 2026 14:56:55 +0000

A program reaches a state it did not expect. It can still execute instructions. Nothing has crashed yet. Should it continue?

I don't think there is a single answer.

If software knows it is making an assumption, silently guessing what the user intended is questionable. For a reversible operation, continuing may be reasonable if the uncertainty and its cause are clearly shown. Irreversible actions deserve a different threshold. Sometimes confirmation makes sense; sometimes the operation should simply be rejected.

That logic changes once the system itself becomes unreliable. Memory corruption, a security compromise, or an undefined internal state creates a different problem. A system in an undefined state cannot confidently decide that an action is reversible, because the mechanism making that judgment may itself be affected. Returning to a known-good state is preferable whenever possible. Otherwise, stopping may prevent corrupted execution from travelling further.

But stopping is not automatically the safe option either. In safety-critical systems such as avionics or medical equipment, suddenly removing a function can itself create danger. The design may need redundancy, isolation, degraded operation, failover, or another predefined recovery path that keeps essential functions available rather than simply terminating everything.

Asking the user isn't an escape from every decision. Waiting for an answer can leave an application blocked or preserve a dangerous state. Some decisions must happen before a user could reasonably intervene. Even an application that wants to continue exists under a larger authority; if the operating system terminates it to protect the machine, it cannot simply override that decision.

So I don't see "always continue" or "always stop" as useful absolute rules. Predicting the next state is itself a probability problem.

The harder engineering question is deciding what we are protecting—the current work, the data, the application, the wider system, or continued operation itself—and whether the system is still trustworthy enough to make that choice.

Engineering Isn’t About Building More. It’s About Finding the Best Path.

Aswin M Rajeev — Wed, 26 Aug 2026 16:59:55 +0000

Engineering, in my view, is not simply about building a solution. It is about finding the best path to accomplish a task while thinking about what that solution will cause in the long term.

A good product should be highly reliable without unnecessarily consuming the customer's resources. If two solutions achieve the same purpose, I would choose the one that saves resources rather than choosing something simply because it uses more sophisticated technology.

But reliability alone cannot define a good product. A combustion engine might run throughout its entire life, but if it continuously produces harmful emissions, what meaning does reliability have? Engineering should always uphold sustainable development and give importance to the environment.

I also believe an engineer's vision should extend beyond a small request from a user. The responsibility begins when the product is created, while different engineering fields and services take responsibility for other parts of its life.

Engineering is also not a journey without failure. Failure can be part of the engineering journey, because it can expand what we discover. Even solving a problem that wasn't originally intended can open a completely different direction.

Ultimately, engineering is not about asking "Can we build this?"

It is about asking:

"What will happen because we built it?"

Beyond Syntax: What Really Makes a Programming Language?

Aswin M Rajeev — Sat, 01 Aug 2026 18:28:52 +0000

In this post, I want to explain how I approached the design of my own programming language, Light, and why some of its rules were designed the way they are.

When designing Light, I was not only deciding how programs should be written. I also had to define how those programs should behave, how different features should interact, and what rules should remain consistent throughout the language.

One question guided many of these decisions:

What rule should govern this, and how should it interact with the rest of the language?

This led to a design centered around explicit structure and dynamic flexibility.

Light defines structural rules for program entry, control flow, data access, and reusable program units. At runtime, variables remain dynamically typed while operations such as array access, expression evaluation, and type conversion follow defined rules.

The same principle applies to Purpose blocks and libraries. They are not isolated features; their behavior is designed to fit into the language's existing execution and data model.

A feature is not complete simply because its syntax works. Its behavior must remain predictable when combined with everything around it.

That is why I focus not only on what a feature can do, but also on where it belongs, what rules govern it, and how it interacts with existing constructs.

For me, this is the foundation of Light's design philosophy:

explicit rules, structured execution, and dynamic flexibility without sacrificing consistency.

Light is still under active development, including its standard libraries, so its design will continue to evolve as the language grows.

Your thoughts and feedback are appreciated.

Explore Light on GitHub: GitHub Repository

Building the Light Programming Language: What I Learned After 9 Months

Aswin M Rajeev — Sun, 26 Jul 2026 07:45:28 +0000

A few days ago, I shared the first public release of Light, a programming language I've been designing and developing over the past nine months.

Rather than introducing the language again, I wanted to share one of the biggest lessons I learned while building it.

Before diving into that, here's a small example written in Light.

user

Purpose Add[a,b]
{
    sum = a + b
    out:sum
    stop
}

x = 23
y = 34

out="'Add{x,y}'"

Before implementing the first working version of Light, I documented the core concepts, language rules, and the initial specification. At that stage, I believed the primary challenge would be transforming those ideas into a working implementation.

Development reinforced just how inherently iterative language design is.

As implementation progressed, practical experimentation exposed interactions that weren't immediately apparent during the initial design. Some features evolved, certain language rules were refined, and additional capabilities were introduced as the language matured. At the same time, performance, error reporting, and the implementation itself were continuously improved through repeated testing and refinement.

One observation became increasingly clear throughout the project:

The specification shapes the implementation, but the implementation also helps refine the specification.

Looking back, building a programming language has been as much about evaluating and refining design decisions as it has been about writing code. Every iteration strengthened the language, improved its consistency, and reinforced the foundation established by the current public release.

This release represents an important milestone in the development of Light. While there is still much to explore and refine, it establishes the foundation on which the language will continue to evolve.

Your feedback and insights are always appreciated.

If you're new to Light, you can read the introduction to the project here:
Introducing Light — A New Programming Language:

https://dev.to/aswinmrajeev/introducing-light-a-new-programming-language-ghd

To learn more about Light and explore its documentation, visit the official GitHub repository.

Official GitHub Repository:

https://github.com/aswinmrajeev/light

Introducing Light — A New Programming Language

Aswin M Rajeev — Sat, 18 Jul 2026 16:39:04 +0000

Over the past 9 months, I've been designing and developing Light, a programming language with the long-term vision of making script automation more structured, consistent, and easier to build and maintain.

The idea behind Light began with a simple question: what would a programming language designed around structured program organization and predictable execution look like? That question evolved into designing the language specification, defining its syntax and execution model, implementing the interpreter, and building the foundation of its ecosystem.

This first public release marks an important milestone. It includes the core language and two standard libraries, establishing the initial foundation of the project. Light is under active development, with additional language features, standard libraries, and developer tooling planned for future releases.

I'm sharing this first public release to introduce the project and gather feedback from the developer community. I'd appreciate your thoughts on the language design, syntax, documentation, and overall developer experience.

Hello Light

user

name = _Light_

out="Hello 'name'"

GitHub

https://github.com/aswinmrajeev/light