-
Notifications
You must be signed in to change notification settings - Fork 81
Philosophy
Modern C++ is the "de facto" standard for many of the most complex software like videogames. But it is cumbersome, heavy and overcomplicated. It is a "big agenda" language that evolved in many years stratifying decisions taken to mitigate problems that game developers don't have (cit.). Using this language for big complex tasks becomes rapidly a stressful and tedious activity. The coders have to express themselves in terms forced by the language and so even simple tasks become boring error-prone activities.
The tools involved in modern C++ programming has a tremendous lack of effectiveness: compilers sometimes give obscure messages, compilation time on serious programs becomes rapidly an issue, debugging can be very hard on complex problems, build process involves several connected tools, etc..
All of these problems can be expressed in terms of friction: the difficulty to get a constant fluid flow of improvement in the code till the scheduled release. Having deadlines and a list of todos that shrink slowly is stressful and painful. Moreover, friction limits the coder in terms of the exploration of alternatives and new ideas because of their time cost, reducing effectiveness, performance, and security of the code.
In the end, friction not only reduces enthusiasm, and freedom of the coding teams, but also heavily the quality of life of the programmers so their productivity. All of these are very big problems for the software industry. Imagine if it would be possible to gain only 20% in friction reduction, this could lead to an enormous amount of overall improvement. And this possibility alone justifies the idea of the creation of a new language.
The original designer said that "video games are machines that fill memory". The majority of the time, game programmers are thinking about how to fill memory with huge reams of data in ways that allow the data to be efficiently accessed and processed. Hundreds of megabytes of memory must be moved from the hard disk into main memory, and from there into the video card or the processor cache to be processed and returned back to main memory. Because video game players don’t like to wait, all this must be done as fast as is allowable by laws of our universe. The primary purpose of a programming language is to allow the specification of algorithms to manage data. Language features like garbage collection and templated data streams and dynamic string classes may help the programmer write code faster, but they don’t help the programmer write faster code.
FRICTION REDUCTION
Another major design goal of Jai is to reduce friction when programming. Friction happens when the syntax of a language interferes with the programmer’s workflow. For example:
- Java requires that all objects be classes, forcing programmers to put the global variables they need into global classes.
- Haskell requires that all procedures be functions and have no side effects.
- C++’s lambda function syntax is different from its class method syntax, which is itself different from its global function syntax.
Java, Haskell, and C++ are examples of what could be called “big agenda” languages, where the languages' idealism (and in C++’s case, its lack of a consistent vision) gets in the programmer’s way. Jai is being designed with a low tolerance for friction, especially when it is unnecessary.
DESIGN FOR GOOD PROGRAMMERS
Jai is a language designed for good programmers, not against bad programmers. Languages like Java were marketed as idiot-proof, in that it’s much more difficult for programmers to write code that can hurt them. The Jai philosophy is: "if you don’t want idiots writing bad code for your project, then don’t hire any idiots". Jai allows programmers direct access to the sharp tools that can get the job done. Game programmers are not afraid of pointers and manual memory management. Programmers do make mistakes and cause crashes, perhaps even serious ones, but the argument is that the increase in productivity and reduction of friction when memory-safe mechanisms are absent more than makeup for the time lost in tracking down errors, especially when good programmers tend to produce relatively few errors.
PERFORMANCE AND DATA-ORIENTED PROGRAMMING
If as a programmer you care about user experience (which you should), then you should care about the performance of your program. You should reason about your code’s behavior on the range of machines that you’re shipping on, and design your data and control structures to use that hardware’s capability most efficiently. (Here I’m describing Mike Acton’s “Data-Oriented Design” methodology.) Programmers who care about the performance of their software on their target hardware are inhibited by programming languages that sit between them and the hardware. Mechanisms like virtual machines and automatic memory management interfere with the programmer’s ability to reason about the program’s performance on the target hardware. Abstractions like RAII, constructors and destructors, polymorphism, and exceptions were invented with the intention of solving problems that game programmers don’t have, and with the result of interfering with the solutions to problems that game programmers do have. Jai jettisons these abstractions so that programmers can think more about their actual problems—the data and their algorithms.
These documents were verified using Grammarly free browser plugin for Chrome. Please use some spell checker before submitting new content.
- Variables and assignments
- Language data types
- Simple user-defined data types
- Expressions and operators
- Type-casting
- Pointers
- Declarations
- Arguments / Parameters
- Return values
- Overloading / Polymorhism
- Advanced features
- Lambdas
- Arrays
- Strings
- Composition of Structs
- Metaprogramming
- Templates / Generics