Why DirectSharp

Even when an agent writes the code, people should be able to read it.

I use C# every day. DirectSharp grows out of years of building real applications and a wish that has stayed with me: I want everyday code to be more comfortable to read, write and explain to another person.

I want code that you can read almost as a specification: a clear account of the rules, the work and its outcomes. DirectSharp is still a general-purpose language with imperative control flow, and it has not reached that ideal. The ambition is to bring an implementation and its explanation closer together, so a reader can check whether the code expresses what was intended.

How I got here

I started with C and C++ using Borland tools. When I moved to Windows development, I moved to Visual C++ and MFC. I was convinced that C-like languages were superior to languages such as Delphi and Visual Basic 6. That was how I thought serious programming was supposed to look.

I later moved to C# for web development and came across VB.NET for business applications. In the 2000s, I would sometimes copy part of the code into an email, adjust it a little for the reader, and ask a business colleague to confirm the rule. They could recognize what it meant and tell me whether it matched the business. That made me reconsider what I valued in a language. Being able to have that conversation mattered.

Today, C# is the dominant language on .NET, and it is the one I use. I have tried Python, Java and TypeScript, but they never drew me far away. I already had a powerful, versatile environment for enterprise applications: an IDE, libraries, web development, APIs, desktop software and data processing. I like having those tools together. C# is excellent, and I want DirectSharp to build on the .NET ecosystem I know and value.

Words, structure and everyday code

Over the years, I have often shown code to a fellow developer or read it aloud to a business colleague while explaining a bug. I would find myself translating the syntax back into words: this is a customer, this is its type, this is the operation, this is the condition. Sometimes saying the punctuation aloud felt ridiculous. The rule we were discussing was much easier to say than its notation was to explain.

I also got tired of pressing Shift over and over to finish a piece of code. I know what the symbols mean. I have used them for decades. Familiarity has never made them my favorite way to write an ordinary business rule.

At the end of a file, a run of closing braces such as }}}} tells me that several scopes end. I have to work back through them to remember which ones. Indentation helps. I still prefer an ending that names what it closes: end if, end action, end class. When I return to the code, those words give me something to recognize immediately.

I am happy to type more letters when the result is easier to read. DirectSharp still uses punctuation and operators where they help; I want the declarations, conditions and operations around them to be comfortable to follow.

I have been a manager for years, and I still love development. I appreciate simplicity more now than I did earlier in my career. I want code that I can return to, understand and discuss without making a ceremony of it.

Why now, when agents can write the code?

I have carried ideas for this language in my head for years. LLMs now make it feasible for me to put them together and work through the details.

I hear the argument that nobody will write code anymore. Agents will do it. Fine. Let agents do more of the typing. Someone still has to decide whether the application does what was intended. An agent can explain its work; I want a reasonable chance of checking the code too.

Even someone happily building through “vibe coding” will occasionally want to look inside. Why did this customer pay a fee? What happens when the email address is missing? Does this change affect existing orders? They should be able to follow the relevant rule and reason about it.

I do not want “I cannot read this; let another agent deal with it” to become the only practical response. Asking another agent is useful. Being able to understand enough to question its answer is useful too. Readable code gives people a way back into their own software.

I wanted this simplicity when I was typing every line myself. With AI building more of the code, I need it even more.

Who I am building for

I am building for people who develop and maintain ordinary business applications, including those who now ask agents to write much of the implementation.

Enterprises cannot staff every internal application with their most experienced engineers. Teams have varied experience; people leave, and others inherit unfamiliar systems. I want the language to help the available team follow the rules and concentrate on the business problems.

I also care about learners and occasional programmers. Visual Basic, VBA and Access made practical programming approachable to people who were not full-time developers. I want that spirit in a strongly typed language with direct access to .NET. A learner working with an agent should still be able to follow a condition or loop.

An analyst reading a rule with a developer should be able to recognize the business in it. Testing, domain knowledge and engineering judgment still matter.

A few reasons to open the code

These are the kinds of applications I have in mind: order entry, billing, approval workflows, customer administration, reporting and integrations. They deserve careful engineering, even when they are small internal systems and nobody works on them full time.

A rose is a Rose is a ROSE

In my view, accepting case-sensitive names as a programming default was one of the biggest avoidable mistakes in making code harder to read. Engineers became accustomed to it, and it became a convention people were expected to learn. I still see the same name in rose, Rose and ROSE. I do not want capitalization alone to give those names three different meanings. Casing should help me recognize a name, not make me wonder whether I am looking at another one.

DirectSharp identifiers are case-insensitive. Different capitalization refers to the same name; a second declaration in the same scope cannot create a different variable merely by changing the case.

Here is a small demonstration, written with deliberately different casing:

let rose = "red"
Global.System.Console.WriteLine(Rose)
Global.System.Console.WriteLine(ROSE)

Both calls read the same variable and would print red. This is an action-body fragment, not a complete program. In ordinary code I would keep the spelling consistent; casing is still useful typography. It should help people read a name rather than secretly change its identity. This rule concerns program names and does not rewrite the text stored in a string. The identifier rules give the precise limits.

Practical foundations

Most DirectSharp application code should be ordinary classes, actions, interfaces and data, using existing .NET libraries directly. A validator can be a class using FluentValidation. A class kind can give a repeated inheritance/interface header a useful name. These should feel like normal application programming.

The standard library belongs alongside the compiler: practical collection, text, service and coordination contracts, implemented largely in C# and tested with the language. I want people to build useful applications with it.

.NET is the practical home of v1.0, with an initial C# backend. A future community might explore other targets if there is a good reason; that remains a possibility, not a v1.0 portability promise.

I want DirectSharp to make business application code easier to write, easier to read and easier to understand—whether a person or an agent wrote the first draft.

Read the language tour, the Customer example, or the standard-library plan.