| Challenges | Solutions | |
|---|---|---|
| Correnctness - how bug free is the code? | Define/disallow undefined behavior | |
| Variable mutation during a function being ran | Define (at the function definition and the function call) which variables it mutates, and have const by default | |
| Unexpected/unhandled errors | Null pointer dereferencing | Use a type system that forces pointers to not be null by default |
| Failed syscalls | Force the programmer to handle any possible failure cases for syscalls that could fail | |
| Comparing 2 values of different types - like a pointer and a number | Use a type system that forces at compile time that this does not happen | |
| Unhandled possibilities | Force exhaustive case matching | |
| Readability - How readable is the code? | Concise, clear syntax with one way of doing common operations. The order of text in a function should show the order of runtime execution. Each package is a directory made up of common assembly files, with common assembly files that are in the same directory automatically getting access to each others functions. The main way of naming would be snake case since it is more readable than any other case. | |
| Modifiability - How easy is it to make changes to the code? | ||
| Performance - How fast is the code at runtime? | Create a syntax that shows the programmer how their code is slow | |
- Stop using compiler "magic" to ensure that the program is correct, and that the binary runs fast. Instead, create a syntax that shows how the program is ineffecient, and the programmer will optimize their code better then any machine could.
- Stop hiding undefined behavior behind "pure" functional abstractions that pretend errors never happen. Instead, make a syntax that defines the undefined behavior, and forces the programmer to handle it, then the programmer can be sure that the program is correct.