The Design of Hammer: Part I

A project needs concrete goals, or else it will wander aimlessly like a headless chicken. In the case of a programming language, this requirement is even more important, because all programming languages eventually drift towards the general purpose, regardless of their original niche.

Hammer's niche is "systems programming", a term that is admittedly nebulous. For the purposes of this post, I shall define it as the act of writing software under the following set of requirements:

1. Resources are critically limited. That is, if the software exceeds its budget, the project will be deemed a failure. Efficiency isn't simply "nice to have"; it's essential.
2. The platform on which the application runs provides few or no abstractions. "Convenience" must be ported to the platform or be created from scratch.
3. The behavior of the software must not violate expectations. Clients regard the existence of bugs as an indication of failure rather than a mere inconvenience.

The canonical example of systems programming is, of course, the engineering of an operating system. These projects, due to their nature as the foundation upon which almost all other pieces of software are built, must fulfill the requirements given above, or else perish into obscurity. On the other hand, software like web browsers, word processors or games do not fall into this category.

To enable and facilitate systems programming, Hammer has adopted the following characteristics:

• Higher order functions.
• Immutability by default.
• A strong, static type system.
• Manual memory management.
• Manual thread management.

Later posts will expand on the reasoning behind each of these design decisions.