I Wrote A Programming Language - Object Oriented

Global variables are denoted by square brackets [] and assigned to a subquery using curly brackets {}. This subquery represents internal initialisation, which may be either classification-based (defining the requirements for joining a group) or factory-based (ensuring you have the required X or Y traits to join by providing them).

Groups

These variable groups are artificial divisions within a single, unified database record. They function similarly to SQL partitions—though, in my view, SQL often applies that concept poorly—by separating a larger database into classes: distinct sets of records that share sufficiently similar data. In traditional SQL terms, these would be tables.

Though in python you might think of them as being a class object though it would represent multiple objects of that class grouped together like how in a game all the enemies might be in a list called enemies. Goblin doesn't do one single enemy you create the behaviour for all objects in the same group by defining their data, relations and what groups they are a part of. You try to limit interfering with individual row level data.

Other languages may refer to these concepts as variables, parameters, tables, and so on. I prefer to think of them simply as groups of data. Each group defines its data requirements upfront: it may act as a classifier, allowing only an Alice to join alice_table, or as a factory, applying rules that ensure data conforms to the group it is intended to represent.

Hereafter I tend to call them groups, but they work like classes in many languages but you ignore the individual bits and data and build the bwhaviour of a group built component by component by adding functions to the group to represent its behaviour.

For example, alice_table accepts only records where name = Alice. A mutant_factory, however, may transform any record it receives into a mutant, thereby placing it within the group of mutant records. In either case, whenever you access data through alice_table or mutant_factory, you are guaranteed that it matches the group's description.

the Alice table works as a classifier it takes data and classifies it as being a Alice. The mutant factory forces the data to become a mutant.

Importantly, each group encapsulates its own code. That code runs only on data that belongs to the community represented by the group.

Functions

Functions are defined using square brackets [], an equals sign, and two calculations denoted by (). The first calculation specifies the values that must be supplied to use the function, while the second defines the changes applied to the supplied data. This function increments steps_walked by the value that immediately follows it.

In the code's backend, a square bracket is referred to as a global. Because the intention is that they can be called anywhere, even inside other calculations and subqueries. 

This nested behaviour allows orchestration of longer data pipelines. In the above mutant factory example there is nothing stopping a internal script within mutant_factory applying additional functions or even forcing the data to join other sub groups as needed.

Unlike Python or C++, Goblin functions do not require () or ; when they are called. They read the input data, determine the number of expected values, and then look for those values immediately after the function name.

This approach is more readable and reduces unnecessary syntax. In the example above, increment_steps is defined with the steps argument in the first calculation (). When it runs, it uses the next value after its square brackets [] as the argument.

Overall, this keeps the language simple and reduces unnecessary keystrokes.

Goblin is not type-sensitive. In the future, controls may be applied through data classification. The intended design pattern is to place rules—similar to those used in query languages—at the beginning of a function to define any data or conditions to which the function should not be applied.

Object Orientation

As per the ideas around object-oriented programming. I want to store the data and methods usually used to change that data in the same place. 

Therefore, the vec in ← the command between two global values [] denotes giving this function and storing it as a tool inside this object. 

Therefore all the common things which the programmer wants to do to a Alice is now stored in one place. 

You call a function stored this way with the global ([]) lookin (.) and global ([]) command sandwiched together. Which denotes look here go do this.

Again, the function already knows which values to look for, so providing the value 5 adds it to the value stored for Alice (within the Alice table). If you provide a name or another unrelated value, it is simply ignored. I am still undecided about errors and similar behaviour; this is something to resolve once the language's Zen has developed further.

This creates isolation within the programming language. If I write a function and assign it to a variable using the vector in ←, it is restricted to running only on data within that variable's context and partition. If I delete increment_steps, it cannot be used anywhere else. Instead, it remains embedded within the system designed to store and manage the data it is intended to operate on.

Because a function or group will only run on data it is explicitly given each group is a simplified little sand box.

Factory as the Default: Object Orientation as a By-product

My contribution to computer science literature is this: I love object-oriented programming, but only when followed through to its logical conclusion.

In the code below, object orientation in Goblin is virtual: at any moment, you can begin a query at the root and locate data at the base. This reverses the conventional process, in which you first define a complex object as a map for future behaviour and then instantiate new versions of it.

The above defines a set of rules for joining—and, as we will see later, leaving—groups. In Goblin, however, the default approach is not to create rigid tables that define a dataset, but flexible groups that members can join or leave.

Once a group has been joined, you can update and modify the data within its record. As shown below, you can call alice_table and use it much like a variable in other languages to work with the collection of data.

The problem, the way I see it, is that data is meant to represent observations about the real world. The map of functions and objects should represent the artificial structure that maps our understanding of it. A problem I see with SQL and the theories behind databases, i.e. is that the map is the territory; i.e. the database explains reality is the assumption, and I see that problem throughout the process that your master database management process involves a foreseeing of how the schema works, a creation of it and implementation. At the point of implementation its actually quite fragile;e i.e. any future changes could materially damage it, and therefore your DBA (database administrator) becomes allergic to change because any change to a schema is a failure on all the products downstream of said schema (which is every business object in production). Therefore, a dynamic organisation will lose pace as it scales because any change to the database at its heart becomes a major change. 

I might be exaggerating this point, but I think it is true to some degree in every organisation as a truism.

In Goblin,n the tables are virtual, and only the data is real,l so the schema can be obeyed when using the objects,s but if a new row now belongs to more than one group, it will not break the system because the tables themselves do not own the data. If someone breaks the schema, it's not a production failure; you just instantiate a new group. 

I think this is a powerful concept because the current business structure runs something like this: a job comes in, it is allocated by a service desk or manager, who can then pass it to one operation, who then needs to handle it. This can create business ping-pong where multiple groups are responsible or joint responsibility is needed because the schema has space for a single foreign key that denotes ownership in the database; it's likely it will be assigned to a single space. If it's not assigned like this,s then some complex data workaround will exist that enables multiple inheritance. 

In Goblin, you would just add to all the applicable owners. Those owners can be represented as groups. Those groups will all run code when they receive the record using the join command, which means they have a chance to make that data record theirs as needed and take full ownership,p but because ownership is joint and as long as they do not name their variables the same thing, ng then ownership is shared no matter how polymorphic the object is.

So currently, I bet in the NHS and a local IT service desk there will be a task that two people or two doctors should see, and I bet they will not because the data pipeline and the data structures that control ownership are not polymorphic,c as in I cannot assign it to multiple places at once.e, The above process in Goblin would say you can assign it to anything you want, and it's on those teams or objects to define the things that they do not have any interest in being alerted on. If it came to you and should not, let's add extra rules on the initial query script that permitted that. 

That is because everything in the database is across a static structure that ingests data and has to classify it into static tables that, in essence,ce own the data. 

Current databases do not handle mutants well

Polymorphism is a well-established concept in computer science, yet it is often handled poorly in modern databases.

Goblin addresses this by building pipelines automatically. When a new record is created, Goblin generates a pipeline using the join command, followed by each relevant global ([]) that the new entry may belong to. In this example, alice_table and mutant_factory are included.

Because the Alice table only accepts Alices, the record will be added. The mutant factory transforms everything it receives into a mutant, so this Alice is now also a mutant. 

In many databases, this would disrupt the workflow: because a table owns the object, it can only follow one path through the internal business logic that determines ownership and responsibility. Goblin allows data to be two things at once, placing this mutant in both groups.

The code does query folding with groups as well i.e. after establishing groups being Alice_table and group B (mutant factory members being part of both groups can be found by dividing one from the other. Both from adding them together. One minus members of the second by subtracting them from each other, and the ^ symbol will get the members which are part of one but not both groups.
That might sound like a throwaway concept, but name another programming language that lets you do arithmetic with sets or define groups and then work out the oddities. 
It felt important to me because the issues that i find when talking to managers are not about the central definitions of their data but the edge cases and where semantics cause data to sit in more than one group. This process lets you identify those edge cases as soon as the defintion is created and challenge the definition from day 1 before it's widely used. 

The data, along with a Venn diagram illustrating the intersection of the two groups, remains queryable. You can examine the inner join between the Alice table and the mutant factory using subqueries and separate the results as shown below.

I think this is particularly useful.

What makes this powerful is that most business problems are not caused by people’s values, motives, or mistakes. More often, they arise from subtle differences in meaning: Person A defines data X as belonging to group Y, while Person B does not. Yet the exact definitions of X and Y are rarely discussed because they have not been properly documented. The language used to define filters is often poorly designed, except among a small group of mathematicians and SQL experts. As a result, when last year’s budget total is off by a certain amount, it can be difficult to explain why. The language is unclear, the maths is unclear, and no one can clearly see who processed what.

Goblin uses precise language based on subqueries and mathematical set theory, including {} notation. In the example above, the definition is unambiguous: it is the intersection of two groups. If you need to understand exactly what those groups contain, Goblin can retrieve the relevant subqueries and write them out explicitly. As discussed, the language tracks these subqueries and preserves them as data sets. Ultimately, every definition resolves to a root definition: everything in the database.

This approach should resolve many common disputes. Eventually, the discussion should narrow to one of two conclusions: either a specific database rule incorrectly categorised data into a group where it did not belong—a rule that can be fixed—or the required data is not in the database at all. The latter sounds like a funding problem, and I do love funding a bigger database.

Ownership Matters

Testing confirmed that each group correctly owns the records assigned to it. The Mutant can be modified through both Alice_table and Mutant_factory. Nothing in the below indicates that, when doing the arithmetic described above, anything is changed in the data. This is important because the data is passed around by reference, with careful choices of firewalls in the processes that stop it passing outside its container. Therefore this test mattered to get right.

Pitfalls of Object Orientation and Why Factories orientation is preffered

My criticism of Python, C++, and other object-oriented programming languages comes from an experience I had while building my “wholly randomly generated computer game,” also documented on this blog.

I believe object orientation works better as an illusion than as a master. To fully commit to object orientation, you must encapsulate data and functions together—as Goblin does—while also separating namespaces and isolating them. However, Goblin rejects that isolation to preserve the behaviour of a capable query language.

The problem goes back to Bertrand Russell, who proposed the following paradox: the town barber shaves all and only those men who do not shave themselves. Does the barber shave himself? Whether or not the example feels intuitive, it transformed set theory. As a result, a good query language must be able to describe the result of any query as a relationship to the complete set of data in the database.

Accordingly, part of Goblin’s design is an unbroken—though often theoretical and background—tree leading back to the complete set of data in the database. You also cannot use a for iterator with the subquery command, because that would be like the barber who both should not, and does, shave himself…

Anyway, back to my story about the wholly random game…

I had built a substantial amount of code around objects defining agents—beings that walk around the map and do things—items carried by agents, and containers that can hold items.

I also had a demiurge: an object that wrote the rules of the entire world from scratch for every game instance. It generated random languages, items, and monsters.

Then I wanted to create a mimic. In Dungeons & Dragons, a mimic is a treasure chest—a container, in the terms above—that becomes a monster when opened. In an object-oriented design, opening that object requires a scripting hook: the code must look into the world object and retrieve the data needed to create the monster. In my game, however, that world object was the demiurge. It was randomly generated, so the system now needed to query it to find an appropriate monster.

That may sound straightforward, but by this point a system called the engine had inherited the world’s game state. It had reached into the lowest layer of the game so the player could open the chest. That communication was one-way and designed for speed. In C++, the usual solution would be a design pattern such as a flyweight: a memory connection from the chest back to the top level, allowing it to send new commands to the manager that controls the world. Even then, the engine manager would need to call back into the demiurge system, which had been deleted and moved into a lighter storage structure for runtime use, and then locate the new monster to spawn. Meanwhile, the container at the bottom of the system still needs the data required to find that new entity.

In programming, we call this scripting. To me, it feels as though we have created an entire subspace to describe a failure state—or anti-pattern—within the object-oriented model.

In Goblin, the entire system has been made virtual, and the data has been homogenised so that it can be interpreted mutually at any level. As long as you know what you are doing, you can treat the system as either a database or a scripting language. Want to stop the game halfway through and rewrite it from a subquery at the lowest object-oriented level? You can do that. I am not saying I agree with it; I am only saying that I admire the gumption.

As shown below, Goblin makes data available from multiple locations when you stage it there, allowing this kind of flexibility. In Goblin, the data could be used to define a mimic, a chest and a monster, and they could all be one record. My preference, therefore, is not to strictly enforce object orientation but to focus on factories that take your code and make it fit the polymorphic design. I.e. the goblinesque approach to having a mimic that's a monster and a chest would be to have multiple factories that make the object fit those categories and work within them; the role of a good programmer in those object-oriented programming languages is to create good objects I think it would be more fun if very deep polymorphism was the norm and the job of the programmer was to avoid these different classes and groups crashing into each other and impeding each other's functions.

Call it object-oriented programming pushed towards factory-oriented programming.

To recap, you cannot use a for loop in a function query because the database cannot reliably determine the source of that query—an issue reminiscent of Bertrand Russell’s barber paradox. A more practical way to think about it is to view the database as a complete system in which every valid query must be definable as a set or subset of the data it contains. Other team members should be able to review your work and trace it back to a clearly defined portion of the overall database. If your request cannot be understood in those terms, it falls outside the boundaries others have already established. In other words, these rules promote consistency and consideration among programmers: you should not use or extend existing values without first understanding how they are defined.

This matters because it is possible to call a non-aggregated function on aggregated data. For example, increment steps was originally written as a non-aggregated function that operates on a single record, but it is now being called on an aggregated group. That is incorrect.

That is an area I am currently thinking about. The increment step above was written to work on individual rows—it should probably be a for command—but something then joined the group and changed its function. 

Data Extraction Matters

I think much of my industry focuses on building data structures without considering how they will be deleted. In Goblin, you are meant to write two subqueries for each group or variable.

I want to build this into the language that is imposed on you. GDPR includes rights to be forgotten and to opt out. I feel strongly that the difficulty is not a programming issue; rather, it stems from the dominant database mindset. It tends to rely on labels within pre-engineered fact and dimension table groups, where the SQL database expects a particular data point.

A) Every webpage in my company will now request it simply because it exists and space has been reserved for it in memory. B) If it later becomes irrelevant or is poorly designed, it will be rebuilt—but only by adding more options to an already poorly designed drop-down menu, until the list becomes excessive and defeats its original purpose. C) GDPR requires you to store only relevant data needed for a lawful purpose; however, because the drop-down and space in the SQL database already exist, you will capture the data whether or not it is relevant. D) Even once this is recognised, the business will do nothing to address this artefact of collecting data with no use case or business benefit, because doing so would require both a schema change and a website change, and both are expensive.

In the example below, Mutant_factory indicates that, when an object is added to the factor set, it becomes a mutant (mutant=1). It also forces you to build an extraction script that will run.

In the example below, once the record has been extracted from Mutant_factory, it is no longer a mutant. However, by accessing Mutant_factory, we have also made it a vampire—and that status will remain on the record.

This should complete the idea that the groups in goblin are not objects in the classical programming sense but factories that generate the conditions that represent the groups they are named for. When something joins the mutant factory, it becomes a mutant; when it's extracted, it stops being a mutant. This is true down to the level of the data is doctored in the record to produce that effect. Therefore, once set up, all these factories should enforce the business realities they represent; if it's in the group, it is right; if it should not be in the group, remove it; if either adding to the group do not correctly set the object up to be part of the group or removing it does not set the item up for a life after existing in the group, rewrite the entrance and exit queries until you find something that enforces the actions that represent the required behaviours.