Why? No flame... just curious.
>> I hate Unix, and Linux, and their derivatives... and Ritchie & Kerrigan for their programming language, also.
>
>Why? No flame... just curious.
Not a problem. (Even if it WAS a flame I’m perfectly capable of defending my positions with reasonably sound logic... while half-drunk.) [;)]
My reasons start at Unix’s design-philosophy, and in order to get at that we MUST understand and illustrate some of the shortcomings of C [remember that C & Unix “came up together” pretty much].
In C there are certain things that are not met by design: notably index-checking for array accesses, which is an extremely common programmer’s error comes to mind. The reason that C CANNOT check the index of an array is that it’s notion of array is “a pointer to memory” and an index into that pointer is the addition of an integer multiple of the size of that array’s elements added to that array. So, the concept of an array “having bounds” is foreign to C and “the responsibility of the programmer.”
This is also the root of why some APIs are, in a word, tedious & hideous. OpenGL, for example, has functions like:
glLightf — The glLightf function returns light source parameter values.
glLighti — The glLighti function returns light source parameter values.
glLightfv — The glLightfv function returns light source parameter values.
glLightiv — The glLightiv function returns light source parameter values.
All of the above have the same ‘base’ idea: returning light source parameter values.
Because C cannot distinguish between arrays by their sizes, as shown above, these cannot be all overloaded into an glLight function with ONLY the parameters being different types because ANY of them that takes a “vector format” (array) of integers or floating-point values cannot be distinguished at run-time because all that is being passed is an address... even if you had arrays of both different element-types and lengths, which can be farly easily spotted by the programmer, the compiler cannot be bothered with such differentiations.
C also doesn’t really have user-defined ‘types’... even the enumeration is an alias to “the smallest word-size that will hold all such values”... in other-words you can have a boolean type with True = 1 & False = 0... and it still takes up a byte. Worse yet you can assign another number, say 42, to the ‘boolean’ type.
The C-programming design worked around that [boolean] shortcoming by saying: “Well, no... Zero = False... and True = NOT Zero” then, magically “if (42){}” becomes acceptable syntax... this in itself might be managable, but it combines with another design choice to produce a frustrating and completely unnecessary error:
“= vs ==”
Bucking the trend of hundreds of years of math, where = is an evaluator they chose = to be the assignment. {Languages like BASIC, and [IIRC] Fortran, had the LET keyword to distinguish an = as assignment from = as an evaluation, Pascal & Agol used := as the assignment operator.} For the evaluation operation they chose ==. The = operator returns a value, namely that assigned to the variable. In this way the C/C++ programmer can say a = b = c = d = 3... and a, b, c, and d all become 3 thanks to that magic property.
Now comes the part where things start colliding in “bad ways...” “if (x == 3)” is a test for x having the value of three, whereas “if (x=3)” is the _assignment_ of three to x, followed by three being evaluated by the if-statement. {Because 3 is not Zero that test will ALWAYS execute the ‘true’ portion of the if-statement.}
Again, in C/Unix-design mindset, it is not the compiler’s responsibility to catch the error... and it is not the language-designer’s responsibility to prevent such possible ‘misunderstandings’; it is the responsibility of the programmer.
Tangent: the == and != evaluators actually break consistency with the rest of the language. +=, -=, /=, *=, %= are all the shorthand for “apply the operation to the value of the variable on the left side and the value on the right side and assign it to the variable on the left side.”
Notice that there is missing !=, which should/would be “apply a bitwise NOT to the value on the left and assign it to the right value.”
Now, keep that “the responsibility of the programmer” attitude; we come to how this impacts the general user: in Unix-land it’s always the user’s fault for ‘not understanding the minutia.’
Apple Corporation however had a different start [with its Macintosh], they were all about making their computer USABLE to the general user. And that is indeed the correct way to design: you make your program, your ‘idea’, into not something that the user CAN use, bu something the user can use EFFECTIVELY.
As a programming-language C (and C++) fail, utterly, at that. They assume that the programmer LIKES debugging and writing lines and lines of statements that could have been avoided with something as simple as array bounds-checking. As a counter-example I’ll show some Ada:
For Index in Some_Array’Range loop
Some_Array(Index):= Some_Array’First; — Assign the first possible value
End Loop;
The above loop will NEVER go out of the array’s bounds, it is using the information of the bounds of the array itself as its control mechanism. The above loop will work FOR ALL arrays containing: Integers, Floating-Point numbers, Characters, Boolean, and User-defined enumerations and all subtypes thereof (though True..True and False..False aren’t helpful as subtypes of Boolean).
The mismash of the C/Unix design-philosophy and the classic Macintosh-philosophy will almost assuredly result in an inferior product. Micosoft, on the other hand, seems to be really pushing C# and the DotNET platform and while C# does have a lot of C++’s syntactic shortcomings it is far more programmer-centric {the ‘end user’ of the language} than C/C++; as evidence of this I submit both memory-management and the C# forall loop.
In short:
I HATE the Unix design-philosophy; it would be better to put some thought into stopping problems with the design of the system than offer something that “works” and constantly throws the responsibility on the user/programmer. {In this manner it is very much like our government is now: if only it weren’t for those “scary tea-bag people” we could have a health-care paradise... oh, and the taxpayer is responsible for the deficit.}
Does that sufficiently address your question?
{I could go on, drawing into the more Unix/Linux specifics/idiosyncrasies but I think I’ve explained the general-concept enough that you should understand the thrust.}