Manifesto
This document serves to outline the general philosophy that has driven the creation of the Truth language. While it is by no means exhaustive, it aims to summarize the rules that have guided the decisions that have shaped the language and the architecture of the system. There are 3 core goals of the Truth language, which are described below.
Truth aims to solve three main issues with data, namely: Architecture, Management, and Interoperability.
Today's methods for architecting data are needlessly complex. This is because it not only requires knowledge of the problem domain, but also the intricacies of a particular data modeling system, whether the tool of choice is a relational database, a graph database, or something following object-oriented principles. And most commonly, these two skill sets aren't even held by the same party. Truth aims to make the architecting of data a non-technical task.
Additionally, today's data modeling systems are leaky abstractions that tend to contaminate the final data set with their implementation details (foreign keys, bridge tables, node IDs). The end result tends to be an information architecture that isn't as aligned with the problem domain as it could be, which is the source of many complications.
Type systems built into data modeling tools aren't expressive enough to constrain data to a degree that achieves strong data integrity. Even if a data modeling system provides a rudimentary type system (in the form of strings, numbers, and booleans), this is barely better than no type system at all when we consider that there are literally millions of data types found in the wild that can be represented in a thousand different ways. Attempting to shoehorn all data into a few built-in primitives leads to what is essentially untyped data.
In order to maintain data integrity, data needs to be as well-typed as possible. It should also be organized into a well-reasoned taxonomy. To do this, we need to be able to construct our own data types that accurately represent reality as closely as possible. Focus must be shifted from data sets to data types.
We've established that data integrity is more or less a function of the quality of it's associated type information. However, when data moves between systems, its typing information is lost. By storing types in a standardized format in a publicly visible location, type information can flow between systems.
Truth is designed to bring us closer to what we believe will be the final era of software development, stated as simply as:
Software should be built by the people that need it.
We aren't there yet. Given the current means by which software comes to fruition, domain experts such as engineers, designers, and system administrators are rightfully wary of allowing those who are unskilled in technical matters to be making alternations to a software system. But we propose that this is due to shortcomings of present-day tools rather than an immutable law of nature.
Software should be built by the people that need it, because these people truly understand the problem they seek to solve. Attempting to communicate these problems to an outside party is the endless source of details lost in translation.
In a Truth-enabled world, presentation optimizers would analyze the Truth code and emit user interfaces that align with the requirements specified in the document. Performance considerations would be handled again by analyzing the Truth code, and structuring (or restructuring) the underlying data storage mechanism accordingly. Focus would be shifted from writing code to generating it, and using Truth as the guide for these generation processes.
Truth should not be thought of as an ever-expanding language that will continually gain features throughout it's lifecycle until it's finally retired. While this may be an appropriate strategy for application development languages, Truth is intended to be a foundational format. It is designed to evolve not by growing the core, but rather through the creation of community-developed Agents, which can be optionally applied to Truth code on an as-needed basis. This allows the core to remain as narrowly specified as possible. In fact, outside of the type system which is delivered through its hierarchical has-a : is-a format, Truth will likely only have 4 features throughout it's entire lifetime. These features are:
- Plurals
- URI recognition
- Regular Expressions
- Comments
Truth provides no built-in facilities for common features found in many class-based languages such as abstract, sealed, public, private, etc. But because the Truth type checker is entirely pluggable, such features could be easily provided by an Agent. Examine the following Truth code where modifiers become available in a document via a fictitious Modifiers.js agent that assists the type checker:
Modifiers.js
Employee : Class
ID : Number, #Private, #Required
Name : String, #Required
The list of tokens recognized by the parser has been kept to an absolute minimum. There are only 4 recognized tokens in the entire language, which are : , ... /. Each of these can be escaped, and for this reason, there are virtually no restrictions on the set of characters that can be used within an identifiers. Even spaces are valid.
Although spaces inside identifiers may appear odd to seasoned developers, this was a critical design decision in order to make Truth not appear as non-cryptic as possible to non-developers.
Of course Truth has no built-in keywords, and this is especially important when considering globalization. Theoretically, speakers of any language should be able to express their statements of Truth without having to learn a set of foreign words or characters, whether that's English, Spanish, Polish, or Japanese. In fact, an alternate statement format that operates in a reversed is-a : has-a order with reversed indentation is under consideration. Such an option could bring Truth to speakers of right-to-left languages such as Hebrew, Arabic, and Farsi.