Philosophy

Behind and Beyond Jai

Friction in modern OOP C++

Modern C++ has arisen as the "de facto" standard for many of the most complex software like videogames. But it not the best possible choice as 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 that may lead to poor performance products.

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. This reduces the effectiveness, performance, and security of the code.

In the end, friction not only reduces enthusiasm, and freedom of the coding teams but also heavily reduces the quality of life of the programmers so their productivity. It wipes away the joy from the creation process and makes the programmers feel like living a miserable life (cit.).

Writing software is an activity that involves creativity. To be productive the programmers need to stay motivated and focused for large periods of time. They have to load the software and make it run in their brain entering in the zone where all the magic happens. Fred Books stated a famous phrase cit. that sais that no matter what kind of tools the programmer uses, about 70% of software development happens in the mind, thanks to the correct way of thinking about the problems. Friction keeps programmers away from this mental state.

All of these are very big problems for the software industry. Imagine if it would be possible to gain only 20% or even 10% 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 even if this won't pretend to be the magic siver bullet that will solve all the problems.

Data-oriented programming

The author of the language stated that "video games are machines that fill memory". Most of the time, coders 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 the main memory, and from there into the video card or the processor cache to be processed and returned to the main memory. Because of the nature of video games, where often user experience is driven by the quality of visuals and time reaction, all this must be done as fast as is allowable by the available hardware. This kind of problem goes beyond the capabilities of many modern programming languages, which may allow the programmers to write code faster but will prevent them from writing fast code. And even C++ that should produce really fast machine code fails if it is not used properly. Almost all modern languages are designed to allow average experienced programmers to produce safe effective code in a reasonable amount of time. But most of them prevent experienced senior programmers to deal directly and easily with the lower levels of the machine code to squeeze out all the available elaboration power from the CPU and the GPU.

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 make up 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.

In the years the academic culture about software development has moved away from the real Information Technology concerns (the data) toward the tools used by the programmers (the software). The attention was driven toward code, algorithms, and patterns instead than on the matter of fact of the problems: how to transform data effectively, that should be the true purpose of the software. This is nothing new, instead was really clear years ago. Fred Books stated a famous phrase cit. resembled in this brief intervention.

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 to solve 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.

---

Navigate

• Home
• Back: Introduction
• Next: Why jay?