# Otty Language Index

## What is it? 

* `Otty` is a fluffy otter mascot.
* `Otty Language` is a semantic, deterministic, and distributed programming language.
  * `semantic` because this language is built using semantic blocks and not parsed from a text file.
  * `deterministic` because the goal of this language is to describe programming instructions in a pure and explicit context. Each execution of the unit tests produces the same result. It would make no sense to execute the tests a second time.
* `Otty Language Index` is the backbone of the Otty ecosystem. The language describes programs and libraries that are dependent on other libraries. The language natively manages the relation with libraries, their storage location, and their deterministic resolution.

## Why?

* There is a belief that one day a computer will be able to understand and execute natural language. But why should this belief be true? Why is it not our natural language that could evolve into a strictly structured and unambiguous language? Why not switch to something different from text, a structured semantic language, a relational graph?
* No useless syntax discussion
  Traditional computer languages are compiled from source code written using text files. A lot of time is wasted on endless discussions about the best text representation for a new concept. Parsing is a nightmare [Parsing: a timeline](https://jeffreykegler.github.io/personal/timeline_v3). Operator precedence or parentheses is a problem that only exists during parsing. A semantic language can introduce and use any new concept without wasting time on its textual representation. No time is wasted creating a grammar or a parser.
* Self-described language
  Because the language is self-described, it allows anything if someone makes the effort to implement it. For example, all other programming languages could be represented in this semantic language if someone were to make the effort to describe them. A self-described programming language has no restrictions. This complete freedom allows any kind of programming concepts and optimizations. And, without restrictions, this programming language could become a nightmare. To prevent this, the language helps put restrictions in place and eases their adoption by explaining the benefits. Restrictions could target readability, simplicity, maintainability, evolvability...

## Risks

* Adding a new programming language is beneficial only if it eventually replaces another bigger piece of complexity in a simpler way. But if it fails to replace something, then it increases the world's complexity.
* Human and AI are used to text files. There are many existing tools for manipulating text files. Storing a programming language in a structured semantic model creates a barrier. It forces us to adapt all tools and forces humans and AI to change habits. This could prevent adoption. For example, if a user loves a super-powerful diff tool, he will not be able to use it with a semantic language. The new semantic language should also include a powerful SCM tool.

## How?

### Code Database

* The language semantics (source code) are stored in a local database and can be pushed to a remote database to be shared. The local database is connected to other remote databases, allowing some dependencies between libraries.
* If the local database has a reference to a remote database, it creates a local copy of the used libraries. The local copies will not be discarded as long as they are used by the local database. So if the remote database disappears, the local database can still work with the local copy of the libraries.
* The Otty Language Index can be used to discover libraries in other remote databases. It does not store the libraries themselves, but it stores an index of all existing remote databases.
* The Otty Language Index is public and only stores language semantics of public libraries. It does not store private libraries but allows you to discover them.
* The code database allows the addition of metadata to the code, such as quality or security labels signed by trustworthy companies. Issue or feature discussions on the code. Summary of the code, issues in the code, and architecture advice provided by external paying tools.

### Semantic Language features
* Naming
  * A semantic language stores the name of the code elements (classes, methods, fields, variables, types, functions, ...) only at one location, and then uses references to this name in the rest of the code. This allows easy renaming of code elements without affecting the code that uses them.
  * Names of code elements can use any character by default, including spaces and emojis. The user interface can use different colors to differentiate them from the rest of the code. Even two names with the same text can be differentiated by the user interface using different colors. For example, a method parameter and a class field have the same name but different colors.
  * The language should allow the use of any character in names, including spaces and emojis. This allows for more expressive and readable code. For example, a variable could be named 'number of carrots' or 'age of a human' instead of 'numberOfCarrots' or 'ageOfAHuman'. It also allows for better internationalization and localization of code.
  * The code is not stored as text files, but as a structured semantic model. Not only is the latest version of the code stored, but all changes applied to it are also stored in the code database. This allows users to rename a code element outside the library that defines it. Dependencies in the code database are deterministic and immutable. Updating a library to a new version is always an intentional action from the user. During an update, the user will be informed of all the naming changes that will be applied to the code. Because the dependent code uses references, the name change in a dependency does not change the code that uses it, except for the library version. But the library's author can provide an explanation for the name change to help users understand the reason. This is true not only for renaming but also for any change in the code. When the library's author changes a method's contract, even if the method name remains the same, the author can explain the impact for the users in the change comments.
* The language does not support any platform by default, but it intends to support all platforms by implementing libraries without having to change the language. So it should be able to support the same platform supported by those [compiler toolchains](./CompilerToolchains.md)
* Class definition:
  * No mandatory order for the fields and methods. They could be displayed in any order by the user interface. The order is fixed only if the code is intended to be converted to another programming language that requires a specific order, such as Java. For example, related fields and methods could be grouped to improve readability and to identify a possible decomposition of the class into multiple classes.
* While viewing the code, it is easy to see only public elements (class, methods, fields...). By default, libraries only display public elements. But it is possible to display private and protected elements as well, so you can browse all the library's code.
* The language allow to apply standards and constraints. For example, it is possible to disallow instanceof and cast.
* The language should allow mock, spy, dependency injection, identification of a test method, ...
* The constraint 'final' on a class or a method is converted into a recommendation to not extend the class or override the method.
* When a method is overridden, the call to the super method is either present or explicitly mentioned to be skipped, and if possible, with an explanation.
* It is possible to temporarily decorate an object with additional fields and methods. For example, a 'Car' can become a 'TaxableCar' with a get field 'taxCalculator' in a specific context. And then continue to be a Car outside of this context.
* Object could be mutated from one type to another with logic to convert the fields.
* Function or method has a more flexible concept. It can be a group of statements with several parameters and several return values. Not all return values need to be updated at each execution. It means that any selected group of statements can be extracted as a function or method by keeping exactly the same behavior.
* Writing generic code should not have any constraints. Not segregation of primitive types, not signature conflicts between two methods having generic parameters, not limitation to extract any part of the code as a method or function that will be inlined. Implementation of the generic code can be done incrementally by implementing only a portion of the required code.
* Adding constraints to a type should be encouraged. At the same time, complex types can be aliased.
* Abstraction Layers
  * The lowest abstraction layer is the one that is closest to the machine code. It is generated dynamically by a defined language library. The highest abstraction layer is the one that is closest to natural language.
  * Optimization can occur not only on the machine code but at any abstraction layer. Because the code is strongly semantically defined and supports pluggable advanced symbolic execution models, it is possible to optimize it at higher abstraction levels. To ensure the reliability of all optimizations, the tests could be run for all possible combinations, including no optimizations.
  * The language does not hardcode abstraction layers. The language is capable of nothing but allows everything. This then needs to apply constraints to standardize the code, making it more readable and understandable to a team used to a given standard. So the language allows the creation of different abstraction layers, where the code has less and less freedom but greater readability, maintainability, evolvability, and cohesion.

### SCM

* The language is natively SCM-oriented. The language is aware of each change and its author. It is possible to easily revert a change or to understand the history of a piece of code. The language can also automatically generate changelogs and release notes based on changes to the codebase. A program that depends on a library can be updated to a new version of the library by applying some basic, safe changes to the codebase, such as renaming classes or methods.
* A dependency between a program and a library, or between two libraries, is not done through a binary artifact, but through a source code version/tag/commit (except branches, which can be moved).
*  
* 

### User interface details

* The language will not use ';' to separate statements. Being a graphical interface, it is possible to isolate statements in separate blocks. And, why not use alternative colors to separate statements?
* The language will not use '()' to group expressions. As a graphical interface, it is possible to group expressions, and it is a user interface choice whether to show parentheses.
* Block of statements will not need '{}' to be grouped. But the user interface may display the code as if it were Java, with semicolons, parentheses, and curly braces.
* The user interface can support a more compact display by using icons to represent a class (c), an interface (i), a method (m), a function (f), a variable (v), a type (t), an enum (e), a test (T)... Including a hint to distinguish between public, private, protected...
* Character strings
  * Character strings are edited in html input text fields that allow all characters. All non-control characters are allowed. And there will be a way to enter and display control characters such as newlines and tabs. It is visible to the user to understand which line break is used.
  * Quotes around a string are not needed. It is useless because there is a graphical delimitation.
  * The background color of the input text field will be different from the background color of the code editor to clearly distinguish between code and the beginning and end of the character strings. Even if the string content is indented, it will be clear how many characters make up the indentation and what kind of space is used, visually distinguishing between spaces and tabs.
  * Even if all characters are allowed in the character strings, a keyboard shortcut exists to exit the character string input field. This allows the user to easily exit the character string input field without using the mouse. For example, the user could press 'Enter' to exit the character string input field or 'Shift+Enter' to insert a newline in the character string, or vice versa.
  * A character string will be strongly typed. It is possible to define a type 'string utf8 json'.
* byte arrays
  * Byte arrays are edited in a hex editor that allows all byte values. The visualization should be clear and intuitive, like the output of the 'hexyl' command-line tool.
* Templating
  * The language should support templating into strings or byte arrays. For example, a character string can contain a template with placeholders that are easy to identify because of the input text field's background color. No need for a dollar sign or curly braces to identify the placeholders. There should be an IDE button to insert a placeholder into the template and explain which shortcut to use to insert a placeholder from the keyboard.
* Comments could be long without affecting readability by using collapsible comment blocks. Users only see the first line of the comment blocks. Users can expand the block to read the full comment. Or comments could even be completely hidden and replaced by an icon (i).
* Browsing code
  * The IDE should collapse the details of the code by default to improve readability. And when browsing the code, code that is less related to the central code collapses automatically.
  * Code search (ctrl+F / cmd+F) can be semantically oriented, focusing only on classes, methods, or fields.
  * Getter and setter methods could be displayed as fields to improve readability, with only a small icon to indicate that they are methods if the code is intended to be converted to another programming language that requires this distinction. By default, all fields can be extended with getter and setter methods.
* Because it is a structured semantic language, the user interface can easily zoom in and out of the code. The type declaration can be displayed or omitted depending on the zoom level. The body of classes, methods, functions, lambdas, loops, conditions... can be displayed or omitted. A bounded list of statements can be commented to allow the zoom level to decide whether to display the statements or the summarized comment. The lowest zoom level can decide to even display inlined functions under their call site. The user can also choose to manually expand or collapse any part of the code. The zoom-in feature goes as far as transforming the code into machine code, allowing the user to understand the underlying CPU instruction and its performance characteristics.

### Strongly typed

* The language is strongly typed. Not only with regular types like int, string, boolean, ... but also with user-defined types by adding constraints on an existing type. For example, a type 'int' could be defined as a 'positive int' or 'int between 0 and 100'.
* The functions are also strongly typed. But if the return value can be inferred from the function body, then the user does not need to specify the return type. But the function signature always displays a return type, even if it is inferred.
* Variable declarations always have an explicit type, even if it is inferred from the variable initializer. For example: (v) size = 3
* Type derives from another type by adding constraints. For example, a list of nested encoding applied to a string (utf-8, json, query-string, html-attribute-value, sql-escaped-value, …)
* Being strongly typed prevents the mistake of putting a variable of one type into a variable of another type. For example, if I have a variable 'number of carrots' and a variable 'age of a human', the language will prevent me from putting the number of carrots into the age of a human. This is especially important when dealing with complex data structures that are error-prone, such as nested lists, maps, or arrays.
* By default, the language will bring a first level of inferred constraints on the types. For example, a type 'age of a human' having default boundaries of 0-200, will become 'age of a human between 21 and 200' after a test 'age of a human > 20'. Additional constraints can be added by more advanced symbolic execution models. The language will allow additional models.
* The IDE should help the user to understand the characteristics of any type that are inferred from the underlying algorithm.
* Narrowing a type 'int between 0 and 100' to a more specific type 'int between 0 and 10' should be a single test condition or throwing a condition exception with a custom message.

### Performance hints

* Because the language allows several models to be added on top of each other, it is possible to add a model that provides performance hints.
* The user should be informed of the performance implications of a piece of code. For example, if a piece of code has time complexity O(n^2), the user should be informed that it is inefficient for large inputs. When no production data are available, performance hits will be determined using a standardized hypothetical computer. The goal would not be as accurate as when production data are available, but rather to convey the magnitude of the code's performance implications.
* Memory usage should also be part of the displayed hints.

### Halting problem

* The language allows infinite loops only through an explicit statement that indicates that the loop is infinite. All callers to this piece of code will be informed that it will never stop, and the caller can not add instructions after the call. It would be dead code.
* So all code that never halts is explicitly marked as such, and this information is propagated to all callers.
* All code not marked as never halting should be guaranteed to halt. The language allows the addition of models to statically prove that a piece of code halts, or to inform the user if the proof fails or cannot be done.

### Interoperability with other programming languages

* The language should be able to convert code to and from other programming languages. The requirement is to define a deterministic context in the source language to enable its conversion into the semantic language.

### Learning

* The main factor that helps adoption is through an enjoyable learning experience.
  * The language can be experienced through an online playground that allows users to write code and see the results in real time.
  * An online game is also a learning tutorial that explains the language concepts in a fun and engaging way.
* Documentation provides live examples that users can play with to understand the concepts and see the results in real time.
*