An important question to answer before undertaking any project is "why?". This is particularly true in programming languages. As such, this article explains the "why" behind the Ivory programming language.
The State of Modern Programming Languages
Programming tasks tend to fall into two categories: high-level "software engineering" tasks, and low-level "systems" tasks. In the modern world, software engineering tasks tend to be user-centric, and focused on creating applications for a specific task. Languages designed for this task tend to be abstract, expressive, and designed to facilitate a software process. They are designed to run with a great deal of support from the system, and tend to be very abstract. Systems programming, however is focused on creating the actual framework itself. This type of programming requires a greater degree of direct control over the execution environment. At the lowest levels, systems programs stand alone on some hardware, without the benefit of a runtime of any kind. More abstract programs tend to be servers, which still are greatly concerned with efficiency. These two tasks have radically different aims, and require a very different approach.
In the beginning, there was nothing but systems programming. Programmers used very simple languages to write freestanding programs that directly interacted with hardware. As such, older languages such as C were designed around this approach. In the modern world, applications run with a great deal of assistance, and on vastly more powerful machines. Modern programming is more abstract, and programs have the benefit of a very complex runtime environment. Languages too, have evolved and grown more complex and more abstract to reflect this.
However, systems programming has not gone away, nor will it ever. Ultimately, the runtime environment itself must be written. As long as the field of computer science continues to evolve, so will the systems on which everything is run. As such, the tools for systems programming must continue to evolve as well. However, most systems programming is done using tools over 40 years old. Many systems languages were designed in a different era, when different concerns were important, and in many ways, are outdated. This is not to say that these tools are poorly suited for their task. They are simply old.
Systems Languages and the "Hack" Stigma
Many systems languages still used today were designed in a very different time. Memory and execution time were scarce, programming was done with punched cards, and it often took 20 minutes to compile a file. Compiler technology was in a much more primitive state, and the highly aggressive optimizations that exist today did not.
This had a number of effects on the structure of the languages. The first was that programmers were required to do their own optimizations. Compilers were assumed to be mind-numbingly stupid. Function inlining, loop unrolling, subexpression elimination, and others were all done by hand. This, in turn caused languages to support constructs designed to facilitate this. Secondly, languages were designed to be easy to compile, so as to make the compile times shorter. This caused a number of design decisions to favor simpler solutions to solutions that were better, but more complex.
Since that era, programming languages have been focused on software engineering, and have made a number of advances. Modern languages designed for this task are too abstract to be used in a systems programming role. They depend too heavily on runtime environments, and they fail to provide a sufficient degree of control. For instance, it is extremely difficult to use a language with intrinsic dynamic allocation to write an OS kernel, as certain areas of the kernel cannot use the allocator (because the allocator depends on them to function). However, many features of modern languages can easily be implemented in a systems language. Additionally, a systems language may benefit from a degree of managed code features. Implementing a 100% managed environment removes too much of the direct cortrol needed for systems programming, but it is entirely feasible to implement managed code features which can be used optionally.
Because of the origins and practices surrounding systems languages, and the lack of modern features in systems languages, systems programming as a whole has acquired the stigma of being inherently "hackish". This is not true however. Given the right tool, there is no reason systems programs cannot be as well-designed and maintainable as any other type of program. This stigma is merely a symptom of the age of the tools available for systems programming.
Ivory: A Modern Systems Language
Ivory was first born of the desire for C to have certain features. Ivory's first and foremost goal is to be every bit as powerful and well suited to its task as its predecessor. Its goal is to be able to implement an OS kernel using no other language or runtime (with the exception of a boot loader). This being said, Ivory aims to be a much more powerful, sophisticated tool than any other systems language in existence.
Ivory is designed with modern compiler technology in mind. It is designed to be friendly to whole-program compilation, to give compilers information they need to perform optimizations, and to facilitate better source code organization. The language includes modules, signatures, and templates to promote better organization practices (and also to permit better optimizations). Many old practices, such as preprocessor macros are dispensed with due to modern optimizations like inlining and constant folding. In the same spirit, keywords and language features that existed to facilitate manual optimizations are removed. At the same time, new features are added whose purpose is to give greater control over the end program, but only where it is needed. Overall, the language is designed to encourage better practice, and created to ensure that doing so does not sacrifice efficiency.
Additionally, the Ivory language is designed to incorporate features of modern languages, as well as new features useful in systems programming. These range anywhere from the addition of exceptions to the addition of an absolute value operator. The language supports a number of managed types, which can be used optionally to ensure more stable execution. Finally, Ivory supports a number of features designed to explicitly grant control over certain areas of the program. Many practices based on assumptions, such as the alignment of structures in C, can be directly controlled in Ivory with the use of a keyword. Thus, Ivory aims to gain as much expressive power as possible, while still being as suitable, if not more suitable to its task than any other systems langauge.
Conclusion
Ivory represents a much-needed modernization of the tools available for systems programming. It aims to provide systems programmers with a more powerful, better suited, and more expressive language for systems programming. Ivory is designed to encourage, not hinder better practices in systems programming, and thereby to make obselete the stigma against systems programming. Ivory, true to its name, is created to be suitable to the task of building the skeletons around which software systems are built, while at the same time being far more polished, expressive, and powerful than any previous systems language.
