The Haxial Programming Language
Design Philosophy and Advantages
Target Audience

The intended target audience/userbase of Haxial Compiler includes:

Here are 2 definitions of Software Engineering:

"the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software"
("IEEE Standard Glossary of Software Engineering Terminology", IEEE std 610.12-1990.)
"the establishment and use of sound engineering principles in order to economically obtain software that is reliable and works efficiently on real machines"
(F.L. Bauer. "Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7-11 Oct. 1968", published Jan 1969.)
Ease of Use

The Haxial programming language ("KL") is designed to be simple and easy to use and understand, however there is a limit to how simple it can be made because it must also be suitable for real-world applications. It is intended to be suitable, practical, and effective for real-world software as opposed to toy, academic, experimental, or prototype software.

Therefore some things in Haxial Compiler are less simple than they could be in theory (because of real-world considerations), and there are still some learning challenges for people new to software engineering. Overall the Haxial language is far easier to learn and use than the C and C++ programming languages.

The Haxial language is meant to be simple but that is not intended to mean minimalist in the facilities it provides. It is intended to be comprehensive, providing many useful facilities (building blocks) in a simple manner without complication and obscurity, and without requiring arcane syntax.

Memory Allocation

Memory allocation and deallocation is managed automatically. There are commands to create objects, but there is NO command to delete an object. The object will be automatically destroyed (and its memory deallocated and made available for reuse) when there are no more references to it. If you wish to cause the destruction of an object, you can cause this by removing all references to the object.

A reference to an object can be removed by setting the reference variable to the null reference, or by setting the variable to refer to a different object, or indirectly by causing the destruction of a "parent" object that contained the reference.

Usually you can create objects and forget about the issue of their eventual destruction. When the last reference to an object is removed or set to null, the memory is deallocated and made available for reuse immediately or promptly. There is no significant delay.

Compare this behavior with the C++ language, where memory is normally managed explicitly and manually by the programmer, creating a considerable burden for the programmer. In C++, it is easy to make the mistake of using an object after deleting it, causing the program to crash. Whereas in the Haxial language, it is impossible to make this mistake because there is no command for deleting objects, and the object will remain valid until all references to it are removed. In C++, it is easy to refer to a deleted object. In the Haxial language, it is impossible to refer to a deleted object.

Crashes

A program crash is a sudden severe failure, causing immediate forced termination of the program (and thus possible loss of data). In the C++ language, it is easy to accidentally or deliberately write a program that crashes. There are multiple different ways of causing a crash in a C++ program. Whereas it is by definition impossible for a KL program to crash (unless safety checks are disabled).

However it is conceivable that the runtime environment or system managing the KL program might crash, if it contains a bug. If a crash occurs when running a KL program, it is by definition always the fault of the runtime environment or system or compiler, not the KL program. There should be nothing a KL program can do to cause a crash (when safety checks are enabled).

If a KL program attempts to do something impossible or incorrect, then an error message is displayed to the user (and the program is NOT terminated). So it IS possible to write a KL program that causes an error message, but it is NOT possible to write a KL program that crashes (if a crash does occur, then it is the runtime environment or system crashing, not the program itself crashing).

In C++, it is easy to accidentally or deliberately write beyond the end of a buffer. This is known as a "buffer overflow". It causes the program to crash or malfunction, and can also create a security hole that can be exploited by attackers. Whereas with Haxial Compiler, programs are prevented from writing beyond the end of buffers (if they attempt it, an error message is simply displayed).

Consequently, KL programs are usually more reliable and secure than programs written in C++.

Even if you do succeed in writing a reliable and secure program in C++, how much time and effort was wasted being extra careful to avoid the easily made mistakes? How much quicker and easier would it have been to write the program if there was no need to be constantly vigilant regarding the easily made disasterous mistakes? How much time could have been saved if there was no need to double and triple check the program code looking for potential crashes or security holes? And when you have eventually written the program and satisfied yourself that it free of crashes and security holes, what if you need to make some changes to it or add some new features? That will immediately re-introduce the possibility of crashes and security holes.

Cross-Platform Portability

The Haxial language is designed from the very beginning to be cross-platform / portable, meaning able to run on different operating systems and in different environments.

A KL program is written the same way regardless of which operating system it will be run in. There is no need to write a different version of your program for each operating system. The same source code works for all.

In some situations, you might make your program detect the current operating system and behave differently, but usually (in nearly all cases) a KL program is written without regard for which operating system it will run in.

Compare this to the C++ language. The C++ language itself is mostly the same across different operating systems, however the functions that interface with the operating system are very different. C/C++ has a small library of standardized functions that operate much the same on different operating systems, but these are woefully insufficient for most real-world applications, necessitating the use of non-standardized OS-specific functions in most cases, ending or eroding cross-platform portability.

Portable Verifiable Executable Format

When KL source code is compiled, it is compiled to a portable and verifiable executable format. Programs are deployed/distributed to end-users in this portable verifiable format (compiling to a standalone native code program file is also supported). When the user installs the portable program on their computer, it can then be converted to native machine code format for best performance.

The native machine code generated on the user's computer can be optimized for the particular type and model of CPU in the user's computer, and the Operating System they are running. Note that it can be optimized for the particular MODEL of the CPU in the computer, not only the general architecture of the CPU. This method can achieve the best possible performance because the native machine code is made specifically for the particular CPU in the user's computer, rather than being made in a slower general manner for all CPU's conforming to a general architecture.

Furthermore, the portable executable format is verifiable, whereas native machine code is difficult or impossible to properly verify. Before converting the program to native machine code and running it, the portable executable format can be verified to ensure that it does not perform various malicious or unsafe actions. Thus security and reliability is increased.

A program written in the C/C++ language is usually compiled to non-portable unverifiable native machine code, and also distributed in that format. It is impractical to distribute a different version of the program for every single model of CPU that the users might be using, so typically the C/C++ program is compiled for the lowest common denominator of CPU, or is compiled in a generic manner avoiding CPU-specific features, potentially sabotaging performance.

When a user receives a C/C++ program in native machine code format, they are being forced to trust the program to an unreasonably high extent because the native machine code is mostly unverifiable. The advantages of distributing programs in a portable verifiable format are very substantial.

Speed

Haxial Compiler can produce fully native machine code programs, running at the full speed of the CPU. The Haxial programming language (KL) is capable of making programs that run at the maximum possible speed or close to it (same as the C programming language).

Speed, reliability, and security are all important, however reliability and security are more important. When there is a conflict between speed and reliability or security, reliability and security are favored.

People do not notice if a program runs slightly slower, but they certainly do notice if the program crashes or malfunctions and understandably they are annoyed by crashes especially if they lose data.

A KL program can be optimized to improve its speed, for example by using vector processing commands instead of individual commands. Invoking a single command that operates on multiple pieces of data (SIMD) is usually faster than multiple invocations of a single command that operates on a single piece of data (SISD).

Unlike KL, the C++ language has no standard/built-in support for vector processing commands/instructions. Individual vendors of C++ compilers may support non-standard extensions to the language to provide this capability.

Optimizing a KL program is usually easier than optimizing a C/C++ program, and writing good quality KL source code is usually easier than writing good quality C/C++ source code. Thus it is expected that a higher rate of KL programs will be well-written and optimized than C/C++ programs.

The user interface for KL programs is designed to be responsive. The user interface of a program running locally should not feel slow or sluggish.

Mathematics

Mathematicians have made a number of excellent contributions to computer science, however only basic mathematical understanding is required to make computer software in many cases (using Haxial Compiler or otherwise). Understanding of mid-level mathematics is useful or required in some cases. Advanced mathematics are necessary in certain specific cases.

Understanding of advanced mathematics is certainly not a prerequisite for software engineering. A person who has only a basic level of mathematical skill should not be or feel discouraged from entering the field of software engineering (although they may be discouraged from certain areas of software engineering).

Here are some examples where only basic mathematical understanding is required (usually):

Here are some examples requiring advanced mathematical understanding:

Some software algorithms are mathematical in nature, while others are more "mechanical" in nature.

In summary, advanced mathematics is non-essential to software development. It is essential for some tasks, but is not essential fundamentally. Therefore, whether or not you need to learn advanced mathematics depends on what type of software you will be making. And if your software will need to include an operation that relies on advanced mathematics, you need to decide whether you will be making that part yourself or using a module that someone else has made.

It is important to realize that KL is a programming language NOT a mathematical language, and programming in KL is different to the normal field and rules of mathematics, and although some things may operate similarly in KL and normal mathematics, or at first glance may appear the same, they are NOT the same.

For example, the mathematical division expression "x ÷ y" (or x above y with a horizontal line between) is NOT accepted, valid, or supported in KL. The nearest equivalent is the KL expression "x / y", but note that it does NOT have the same meaning as the mathematical expression "x ÷ y", although they do have similarity/overlap in operation/results. In some cases, "x / y" produces the same result as the mathematical expression "x ÷ y", but in other cases it does not.

Likewise, mathematical multiplication expressions such as "2 × a × b" or "2ab" or "2(a)(b)" are not accepted in KL. The nearest equivalent is the KL expression "2 * a * b", but it is not identical to mathematical multiplication. The use of the different symbol/notation should serve as a reminder of this fact.

In mathematics, you can multiply a value by a fraction as in the mathematical expression "a × (x ÷ y)", but if you write "a * (x / y)" in KL it does something similar but significantly different (there are overflow and rounding/truncation issues in programming), and the result will probably be unexpected to you if you think that programming is the same as mathematics.

When you perform math-like calculations in KL, the resulting answers are predictable and consistent but deliberately are NOT necessarily mathematically correct. Rather they are correct according to the rules of KL, rules that are different to the rules of normal mathematics. The rules governing calculations in KL are not problematic, unless you confuse programming with mathematics -- programming is not the same as mathematics!

Another difference is that in KL there is a concept of "commands" (procedures) not found in normal mathematics. Commands are different to mathematical functions, although there are some similarities. KL has both commands and functions as separate concepts.

In mathematics, you can indicate that a value is to be raised to the specified power using a superscript number, for example:
    a6
KL, not being a mathematical language or notation, does not accept superscript powers/exponents. It is possible to calculate a power in KL, but because of practical considerations, it may or may not succeed, and the result may be an approximation or nearest-representable answer.

In mathematics an expression such as "a + b × 2 ÷ 3" is a theoretical construct or part of an equation whereas in programming "a + b * 2 / 3" is a series of steps/operations to be performed/executed.

[Documentation main page]