The question of why I decided to build McBasic is perfectly legitimate, especially considering when I am doing it. This is no longer the 1990s, when Visual Basic was, for many developers, one of the simplest and fastest ways to build a Windows application. Today we have an enormous number of languages, frameworks and development environments, many of them excellent. There are already several products based on BASIC, or at least on a similar approach to visual development, and, as if that were not enough, we now have artificial intelligence, which can write a substantial part of an application for us.
So the question is not whether BASIC is still a usable language in 2026. I think that is fairly obvious, and I have little interest in writing yet another nostalgic defence of it. The questions I find more interesting are different: why choose a BASIC-based environment today, why choose McBasic when similar tools already exist, why use it instead of a modern development environment and, perhaps most importantly, why try to make programming simpler at precisely the moment when AI appears capable of writing almost anything we ask it to write?
It is actually that last question that, in my view, makes the project more interesting today than it would have been five or ten years ago.
For many years we associated programmer productivity largely with how quickly someone could write code. More expressive languages, libraries, frameworks, code generators and increasingly sophisticated IDEs were intended, among other things, to reduce the time required to turn an idea into working code. Artificial intelligence is radically changing that part of the job because today I can describe a function in plain English and get, within seconds, an amount of code that would previously have taken me considerably longer to write by hand.
The problem is that writing code and building software are not quite the same thing.
Even when AI writes the code, there is still a project, a framework, libraries, dependencies, a build system, configuration, a database, resources, certificates, permissions and everything else required to turn that code into an application that can actually be run and distributed. There is also a more important problem: sooner or later somebody needs to understand what has been built, particularly when something stops working or when, six months later, the application needs to be changed.
From this perspective, AI has dramatically reduced the cost of producing code, but it has not necessarily reduced the complexity of software by the same amount. In some cases it may simply be doing a better job of hiding that complexity, because it is now possible to produce relatively complicated systems without fully understanding everything that has been generated.
This is where BASIC becomes interesting to me again.
Not because it is technically superior to Swift, C#, Kotlin or any other modern language. That would be a difficult argument to make seriously. What interests me is that BASIC is simple, readable and relatively predictable. If AI generates code for me, I want a reasonable chance of being able to read it and understand what it is doing without working my way through five layers of abstraction. If something goes wrong, I want to be able to follow the flow of the program. If I open the project again six months later, I would prefer the code to still look like something intended to be read by a human being.
A very ordinary piece of code such as:
If Customer.Balance > CreditLimit Then
ShowWarning("Credit limit exceeded")
End Ifis unlikely to win any awards for language design, but it has one rather obvious advantage: it is difficult not to understand what it does. At a time when more and more code will be produced automatically, I think that characteristic may become more important rather than less.
That brings us to the second question: if I want to use BASIC, why McBasic? There are already several modern implementations, and some are mature products that have been developed for many years. PureBasic is cross-platform, has an established community and produces very compact executables. FreeBASIC is an extremely capable compiler. Xojo provides a complete RAD environment and is probably one of the contemporary products closest, at least conceptually, to some of what I am trying to achieve. Then there are QB64, twinBASIC and several other projects approaching the problem from different directions.
I did not start McBasic because the world was missing a BASIC compiler. If that had been the problem, using one of the existing products would have been considerably more sensible.
The problem was that I could not find exactly the environment I wanted to use.
First, I wanted an environment designed around the Mac, where the Mac was not simply one of several supported platforms but the starting point of the project. I also wanted to recover the visual development model that made environments such as Visual Basic so productive: create a Form, add controls, change their properties, double-click a control and write the code for its event. If I want to understand what a window looks like, I look at the window in the designer. If I want to know what happens when I press a button, I look at the button’s Click event.
This distinction matters because McBasic is not primarily an attempt to invent another BASIC dialect. The language is part of the project, but it is probably not even the most important part. What I am trying to build is a complete environment in which the language, IDE, Form Designer, debugger, controls, databases, components and build system all belong to the same development model.
Visual Basic, after all, did not become popular simply because BASIC was easy. BASIC had existed long before Visual Basic. A significant part of its success came from how quickly it allowed developers to move from an idea to an application. You did not think separately about the GUI library, the event system and how to create a window. You designed the Form, wrote the necessary code and continued working on the problem you were actually trying to solve.
Of course, today we can do all of this with much more modern tools. I can build a Mac application with Swift and Xcode, or use C#, Avalonia, Flutter, Electron, Qt and a long list of other technologies. I use modern tools myself, and McBasic is obviously built using modern technology, so framing this as some kind of battle between old and new would make very little sense.
What interests me instead is the difference between complexity that is necessary and complexity that we inherit because the tool we have chosen was designed to solve a much larger class of problems than the one in front of us.
If I am building an application intended for millions of users, involving multiple services, development teams and complex requirements, I will happily accept a certain amount of architecture because I probably need it. But if I am building a small business application, something that works with a database, an internal company tool, an inventory system or a utility that automates a particular process, I am not convinced that the complexity of the development environment should necessarily be proportional to the maximum capabilities of the framework rather than to the problem I am trying to solve.
For many years this space was served very well by tools such as Visual Basic, Access and FileMaker, and that space still exists. There are still plenty of situations where an Excel spreadsheet is no longer enough, but moving to a full development stack feels like a disproportionate jump. There are also applications that do not need to become products, do not need to be offered as SaaS and do not need to serve a hundred thousand users. Sometimes a program simply needs to solve a problem well for one person, one office or one small business.
This is why I am treating databases, APIs, files and other common operations as normal parts of the McBasic environment. If I want to use SQLite, display some records, modify them and save them, accessing the database should not become a project within the project. The complexity will, of course, still exist underneath, but one of the purposes of a development tool is precisely to absorb some of that complexity rather than pass all of it on to the person using the tool.
The same reasoning applies to the component system. One of the great advantages of the old Visual Basic ecosystem was the ability to add functionality without necessarily building everything from scratch. You installed a component, it appeared in the Toolbox and from that point onwards you could use it like any other control, with its own properties, methods and events. It was an extremely simple model to understand, and it is one that still makes a great deal of sense to me.
Trying to put every imaginable control and feature directly into the IDE would make little sense. I would rather have a core that is complete enough to build a normal application and allow everything else to be added through components. Advanced charts, reporting, specialised database controls, editors, protocols or integrations with external services can be developed independently and, eventually, distributed by other developers. Some may be free, others commercial. If that ecosystem works, McBasic can grow without every new requirement necessarily becoming another feature of the core product.
There is still the elephant in the room: if artificial intelligence can already generate an application from a description, why would I need McBasic at all?
I have asked myself that question several times while developing it, and I have come to the conclusion that AI does not make an environment like McBasic irrelevant. It may actually make it more useful.
When I ask an AI to build an application using a modern stack, the model has to make a considerable number of decisions. It has to choose or assume frameworks, libraries, project structures and architectural patterns. Two almost identical requests can produce applications organised in completely different ways. If I then continue developing the project through AI, there is a risk that I gradually become the operator of a system I understand less and less.
An environment like McBasic deliberately reduces the number of possibilities. The AI can know the language, the standard library, the Form model, every available control, their properties, methods and events, the component system and the exact structure of a project. It can also know the Form I am working on, which controls it contains and how the code relates to the interface.
If I am working on frmCustomers and ask it to add a search that updates while the user types, I do not want the AI to invent an architecture. I want it to look at the existing project, see txtSearch and grdCustomers, understand how the data is connected and make the change using McBasic’s development model.
In this scenario, the simplicity of the environment helps both the human developer and the AI. The AI has fewer arbitrary decisions to make, the result becomes more predictable and the user remains inside a system that can still be understood. If something goes wrong, I can ask the AI to help me, but I can also open the event and read what it wrote.
This is perhaps the aspect of the project that I find most interesting. BASIC and artificial intelligence may appear, at first glance, to belong to completely different eras of computing, but they may actually work particularly well together because they address different parts of the same problem. AI dramatically reduces the work required to produce code, while a simple and predictable environment reduces the work required to understand, organise and maintain what has been produced.
Ultimately, I do not think the reason to use McBasic is that BASIC was better thirty years ago, or that modern development tools have become unnecessarily complicated. Both would be rather simplistic arguments. I think there is still a very large category of applications for which speed, readability and simplicity of the development environment matter more than having a choice of twenty different frameworks.
McBasic is being built for that category of applications and, quite simply, because it is the tool I wanted to find when I started looking for one. If I had found a Mac development environment with the visual development model I wanted, simple enough to let me build a small application quickly but complete enough that I would not have to abandon it as the application grew, with databases, components and AI designed as parts of the same system, I would probably be using it.
I did not find it, so eventually I decided to try building it myself.