The Haxial Programming Language
Criticisms of Other Languages

The C programming language was developed in 1972 by Dennis Ritchie at Bell Telephone Laboratories. C was designed as a system implementation language, but has also been used for many application programs.

By modern standards, C is antique and underpowered. It also suffers from being prone to crashes and security holes (it is easy to make mistakes when using C that cause crashes or security holes).

The C++ programming language is the C language plus a number of extensions developed by Bjarne Stroustrup beginning in 1979. This extended version of C was named C++ in 1983. It continued to be prone to crashes and security holes.

Note that Bjarne Stroustrup is NOT the creator of the C++ language. Rather the C language was developed by Dennis Ritchie, and then Bjarne Stroustrup designed some extensions to it known as C++. Thus Stroustrup is the creator of the extensions, not of the entire language, and not of the core or most important parts of the language.

A few of the C++ extensions to C are good ideas, and the others are mostly rubbish or unnecessary/unhelpful complication. C++ has been a popular programming language, however the popularity of C++ was in fact mostly the popularity of C not C++.

A quote of Bjarne Stroustrup follows. This quote helps reveal that C++ is a poorly designed language:

"I designed and repeatedly taught a freshman programming course at Texas A&M University. I use standard library features, such as string, vector, and sort, from the first week. I don't emphasize STL [Standard Template Library]; I just use the facilities to have better types with which to introduce the usual control structures and programming techniques. I emphasize correctness and error handling from day 1. I show how to build a couple of simple types in lecture 6 (week three). I show much of the mechanisms for defining classes in lectures 8 and 9 together with the ways of using them. By lecture 10 and 11, I have the students using iostreams on files. By then, they are tired, but can read a file of structured temperature data and extract information from it. They can do it 6 weeks after seeing their first line of code. I emphasize the use of classes as a way of structuring code to make it easier to get right. After that comes graphics, including some use of class hierarchies, and then comes the STL. Yes, you can do that with complete beginners in a semester."
-- "An Interview with Bjarne Stroustrup", James Buchanan, Dr. Dobb's Journal, 27 March 2008.

Stroustrup says that it takes him 6 weeks to teach a beginner how to read a file of structured data and "by then, they are tired". 6 weeks! 42 days! This is such a basic task, yet it takes 6 weeks to teach it in C++, a surprisingly long amount of time for such a basic task. In a sensibly designed language, this basic task can be taught within a few days (or at most half the time that Stroustrup suggests), and without making the student "tired". This highlights the bad design of C++.

Furthermore, Stroustrup appears to think that 6 weeks is an impressively short amount of time to teach that task, demonstrating that he has a poor understanding of modern software engineering.

C++ does not have any standardized networking or graphics capabilities. Various third parties have created their own differing/unique networking and graphics libraries for others to use (some for free, some for a fee), but the C++ language itself has no standard ability for networking or graphics.

In 2008, the C++ Standards Committee added even more obscure and rarely helpful features to C++, such as "lambda functions" and "closures", while ignoring essential features such as networking and graphics. "Lambda functions" and "closures" do not make a useful real-world program, whereas obviously networking and graphics capabilities do. This demonstrates that the C++ committee has insane priorities, and a poor understanding of real-world practical software engineering.

Like nearly all programming languages, C++ uses words from the English language for keywords and standard function names. Not only do the designers of C++ have a poor understanding of how to make a sensible programming language, they also appear to have a poor understanding of the English language, despite being English speakers.

For example, imagine you have an array/vector of items, and you want to add an item to it at the end, and you are writing a function/command to do that. What name would you choose for the function/command that adds an item to the array? Most likely you would name it "Add" or "Append". Those are sensible choices for the name, and they demonstrate an understanding of English.

However in C++, the function is NOT named "Add" or "Append". Instead it is obscurely named "push_back"! This suggests that the designers of C++ have a poor understanding of English, or that they have some sort of mental difficulties with English, or perhaps a touch of Down Syndrome.

Now what if you wanted to make a function/command that removes the last item from an array? Obviously a sensible name would be "RemoveLast" or "remove_last". However in C++, they again seem to struggle with their comprehension of English -- the name is "pop_back". In a desperate and weak attempt to justify this obscure name, someone might say that "pop" is meant to be the opposite of "push", but no, in English the opposite of "push" is actually "pull".

Another example: C++ has an array/vector function named "empty". Does that mean it empties the array (removes all items), or does it just report whether the array is empty? The name "empty" gives no clue either way. The "empty" function in C++ actually reports whether the array is empty, thus a better name would be "IsEmpty" or "is_empty".

This suggests that the designers of C++ do not understand the English grammar concepts of adjectives (descriptive words) versus verbs (action words). The phrase "Empty the array" is using "empty" as a verb. The phrase "Is the array empty?" is using "empty" as an adjective. The C++ function "empty" is named as if the designers lacked an understanding of the difference between an adjective and a verb.

C++ compilers tend to give bad error messages when the programmer makes a mistake. For example, consider the following C++ program:

#include <iostream>
#include <vector>
using namespace std;
int main()
{
    vector<int> aList;
    aList.insert(10);	/* this is a mistake */
    /* correct code is:  aList.insert(aList.begin(),10); */
    return 0;
}

When that is compiled using GCC 4, it produces this hideous and unhelpful error message:

stltest.cpp: In function 'int main()':
stltest.cpp:9: error: no matching function for call to 'std::vector<int, std::allocator<int> >::insert(int)'
/usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/vector.tcc:93: note: candidates are: typename std::vector<_Tp, _Alloc>::iterator std::vector<_Tp, _Alloc>::insert(__gnu_cxx::__normal_iterator<typename _Alloc::pointer, std::vector<_Tp, _Alloc> >, const _Tp&) [with _Tp = int, _Alloc = std::allocator<int>]
/usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/stl_vector.h:657: note: void std::vector<_Tp, _Alloc>::insert(__gnu_cxx::__normal_iterator<typename _Alloc::pointer, std::vector<_Tp, _Alloc> >, size_t, const _Tp&) [with _Tp = int, _Alloc = std::allocator<int>]
The C# Language

The following is an example of how to declare a function in the C# language, with 1 parameter. The single parameter is an integer variable being passed by-value.

void MyFunction(int i)

Therefore, you would think that the following 3 examples are all passing by-value:

void MyFunction(int x)
void MyFunction(MyStruct x)
void MyFunction(MyClass x)

But actually the first 2 are passing by-value, and the last example is passing by-reference. (This is assuming that "MyStruct" was defined previously using the "struct" keyword, and "MyClass" was defined previously using the "class" keyword.)

The following example demonstrates how to pass an integer variable by-reference, meaning passing (to the function) a reference to an integer (as opposed to the value of the integer):

void MyFunction(ref int i)

Therefore, you would think that the following 3 examples are all passing a reference:

void MyFunction(ref int x)
void MyFunction(ref MyStruct x)
void MyFunction(ref MyClass x)

But actually the first 2 are passing (to MyFunction) a reference to the value, whereas the last example is passing a reference to a reference to the value (a double reference).

The following 3 examples are all passing (to MyFunction) a reference to the value:

void MyFunction(ref int x)
void MyFunction(ref MyStruct x)
void MyFunction(MyClass x)

As you can see, it is inconsistent. When passing by-reference, sometimes the "ref" keyword is used, other times it is not.