Why 42

42 is a new programming language, whose name is inspired by The Hitchhiker's Guide to the Galaxy. Why should you give 42 a try?

42 programs are secure, easy to optimize and customize. In 42 you get:

More in details:

  • Seamless caching
    Most of the performance issues are not about smart ways to generate ultra fast assembly. Most often they are about code repeating the same operations over and over again. In 42 various forms of caching are proven semantically unobservable. This means that those optimizations are easy to insert and are unable to induce bugs into the system.
  • Deterministic parallelism
    Caching and parallelism are the two main ways to optimize code. While caching avoids doing the same operation over and over again, parallelism allows doing more things at the same time. In other languages, parallelism allows for non deterministic behaviour; that is a nightmare to debug, especially when it is unintentional. In 42 all parallelism is deterministic by construction, thus no bugs can be caused by the quirks of parallel execution. This allows us to take full advantage of many cores while keeping the simple deterministic and sequential execution model in mind when testing and debugging code.
  • Typed class decorators
    In a typical 42 program, the huge majority of the code is automatically generated by user defined class decorators. This allows for exceptionally compact programs, like a fully 3-tier application in less then 100 lines. Instead of providing the full code, a code decorator takes a suggestion (a fragment of the full code) and produces the full result. In this way the programmer can focus the majority of their time on writing the important bits of their code, while redundant and repetitive code is automatically generated.
  • Always-on constraints
    Personal names start with an upper-case letter, Those two lists have the same size, This map contains an entry for all the cities of Japan. When writing code, we often assume our input data to satisfy certain expectations. In 42 we can encode those expectations as user defined constraints on the data, and it is then impossible to observe broken constraints. In this way the data we work on can never become ill formed.
  • Fine grained permissions
    A secure program never does the wrong action. For example, it never commits ill-formed data to the database. In 42 a single localized part of code can clearly specify what those actions are and what are the corresponding correctness criteria. The rest of the code will be unable to break those criteria, and thus be unable to perform wrong actions. In this way the programmer can focus the majority of their time on writing correct software, while the security is guaranteed by the system. This has pervasive security implications: in a large application, the most experienced programmer can write those constraints. Other programmers and library code will be unable to break those constraints, no matter how hard they could try.
  • Integrated deployment
    In other languages, writing a program is just the first step. The program will need to be then tested and uploaded so that clients can use it. This usually requires using a plethora of different tools. This is not the case in 42: A typical 42 program will compile, test and deploy itself. In 42 everything about an application is encoded by the code of that application.
  • No need of system knowledge
    42 is designed from the ground up to avoid the need of any system knowledge: A good 42 programmer just need to be good at designing code. On the other side, to be a good programmer in other languages, you would also need to know about shell commands, operative system conventions, environment variables, character encodings and anything else usually connected with a specific operative system.
  • Towels!
    Not all projects have the same requirements, and not all the developers have the same preferences. Most languages are stuck with a single standard library, that ends up being obsolete after a few years. In 42, towels cover the same role of the standard library, but towels can be personalized, to fit better a given company, project or programmer. Methods and classes can be added, removed or simply renamed. This can be done while preserving compatibility with the all of the third party libraries. The same features allowing programmatic refactoring of the towel can be used on smaller units of code, allowing to reuse, compose and customize code in a very flexible way.

All those statements looks unbelievable given current programming wisdom.

  • In the guide, we explain the language, and we explain those statements and how they work.
  • You can also download 42 and try it yourself.
  • You can also engage with the open source GitHub repository.

Pure and fair Object Oriented language

42 is a pure object oriented language, where every value is an object. This means that:

  • Numbers are objects, so thay can have methods like «» or «».
  • All operators are just method calls, thus «» can be sugar for «», and so on. Note how «» is just an ordinary method name. Any class that offers the method supports the operator.
  • Classes are objects, so when you write «» you refer to the method «» offered by the object denoted by «». class objects are just objects, and you can also store them in local bindings if you wish, as in «»
  • The code is an object, but only at the granularity of Libraries; that is, balanced pairs of curly brackets representing classes (or interfaces) with methods and nested libraries. This is useful for meta-programming, which we will see later.
  • Differently from other pure object oriented languages, in 42 all objects have the same treatment, both syntactically and semantically. For example «» This is a declaration for a local binding «», using the string class «» and the method operator «», used as string (or in general sequence/collection) concatenation. Coming from another programming language, you may be surprised that we have to write «» before «» and «». This extra verbosity is needed to provide fair treatment to all classes. (see more in Basic classes) In 42 we do not give preferential treatment to special objects/classes. In this sense, we consider most other languages to be discriminatory. They give priority to their "preferred" version of numbers and strings, and this puts into a position of unfair disadvantage library code trying to define its own kinds of numbers/strings. Instead in 42 you may encounter strings like «» or «». The same for numeric classes: to talk about a street, 20 meters long, you would write «». Note that we write the class name after the number, while usually the class name is before. 42 is a little incoherent in this point, both for better readability and because «» would be considered an identifier by the parser. You may encounter «», «», «», «», «», «», «», «» and many other numeric classes.

A simple language

We believe 42 is a simple language, where all classes are final and interfaces are the only instrument to obtain subtyping. Moreover, 42 does not offer many controversial features usually found in other programming languages, including: (method) overloading; threading; numeric conversions and coercions; var-args; primitive types and automatic (un-)boxing; inner classes; arrays; generics; scope-hiding of local variables/bindings, methods and fields; closures/lambdas and null.