Create FUBS authored by Eron's avatar Eron
### "Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program."
Linus Torvalds
# FUBS
I had enjoyed programming since I was 10 years old. By 2016 I was programming an Android App with Google's shit and I hated my life. Apple's shit was more infuriating. Don't get me started with the embarrassment known as the "Javascript ecosystem". FUBS is a software development system that made me like programming again.
It can perhaps best be described as what C++ should have been. It will continue to be a private work in progress for many more months. It will be released when it is ready and when [FUWD](fuwd) is ready to host it.
## Core Priciples (roughly in order of importance)
1. Have a unified execution and authoring environment. Any program must also provide the tool with which it was created and allow itself to be modified. We endeavor to make it as frictionless as possible for a user of a program to understand or modify it.
1. Anyone can code. Make it easy for anyone to modify any part of the system. Imposing restrictive [encapsulation](https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)) is selfish and elitist.
1. Milliseconds matter. A programmer should see the results of a program modification instantaneously.
1. It is extremely important for systems to be [self hosted](https://en.wikipedia.org/wiki/Self-hosting_(compilers)). Only use other programming systems as a bootstrap mechanism. If your system uses nothing written with another system, then you can rest assured that it is complete.
1. [Dynamic analysis](https://en.wikipedia.org/wiki/Dynamic_program_analysis) with 100% [code coverage](https://en.wikipedia.org/wiki/Code_coverage) is far more effective at catching programmer mistakes than static analysis will ever be. Programming tools can make such testing much less cumbersome.
1. Never compromise the present for backwards compatibility. Fix mistakes as soon as they are identified regardless of how it affects existing dependees. An antiquated dependee can either keep up or become an artifact.
1. The programming language must make it easy for the programmer to understand and control what the computer is doing at the lowest level. High level abstractions should never lessen this understanding.
1. Use concrete [AST](https://en.wikipedia.org/wiki/Abstract_syntax_tree) metrics to measure some aspects of code quality.
1. Fewer nodes for the same program with similar execution time and space is always better.
1. If node A refers to node B, a shorter path from A to B through the AST is always better.
1. [Dynamic reachability analysis](https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)) is the wrong way to reclaim memory.
1. Static analysis with [type](https://en.wikipedia.org/wiki/Type_system) annotations is a good way to catch many programmer errors.
## Details so far
* FUBS is basically an object oriented imperative language.
* Classes can contain inner classes, data fields (singleton or per object), and functions (singleton or bound to an object).
* Inner classes exist soley for the purpose of providing name spaces.
* A class may specify one or more super classes for inheritance.
* Diamond inheritance is prohibited.
* Name collisions for singletons and object fields are prohibited.
* Name collisions for object functions create a function group for [dynamic dispatch](https://en.wikipedia.org/wiki/Dynamic_dispatch).
* Because diamond inheritance is prohibited, a class can have another type of parent class (called a "trait") that permits diamond inheritance. A class may not be instantiated if it has an unrealized trait in its ancestry. A class can realize a trait by having the specified class declared as a super class somewhere in its ancestry.
* Only classes exist at the top level. All functions and data are fields of a class.
* Strongly typed.
* Supported types:
* Primitive types (passed by value):
* Single byte
* No operations allowed except storing and retreiving from array and casting.
* 4 byte integer
* 8 byte integer (not implemented yet)
* IEEE 745 single precision floating point
* IEEE 745 double precision floating point (not implemented yet)
* Boolean
* Reference types (nullable):
* Array
* Big Array (for 64 bit heaps) (not yet implemented)
* Object (bound to a specific class)
* Big Object (for 64 bit heaps) (not yet implemented)
* Functions (including closures)
* Signedness of integer types is determined by the binary operator chosen.
* Type inference required for local variables.
* No automatic coercion except for widening of object types
* Any primitive type may be cast to any other primitive type.
* Class parameters provide for [generic programming](https://en.wikipedia.org/wiki/Generic_programming).
* An object type is provided to speciy how wide a class parameter may be.
* Heap management so far:
* No dynamic reachability analysis except when debugging.
* A reference type may be "prime", which means that it will be automatically freed when it leaves scope (for local variables), or its parent is freed (for object fields).
* Static analysis will help catch program errors with respect to prime reference management.
* Copies of prime references are permitted. The static analyzer will try to prove that a copy does not escape the lifetime of it's associated prime reference. If it can not, the programmer must annotate that reference as "fragile".
* Only rudimentary support for strings.
* A string constant may be specified in a program. It will manifest itself as a mutable array of single bytes with a null terminator.
* [Balls](https://en.wikipedia.org/wiki/Exception_handling):
* Exists only on a trial basis. Will be evaluated on an ongoing basis. Candidate for removal.
* Execution model:
* Fully self hosted.
* Programs are stored as a binary representation of its abstract syntax tree.
* An IDE is being developed to directly manipulate the abstract syntax tree.
* A text format exists for bootstrapping and luddites.