|WikiProject Computing||(Rated Start-class, Low-importance)|
|WikiProject Computer science||(Rated Start-class, Low-importance)|
The current "Disadvantages" section consists almost solely of remarks about the C language that are either incorrect or inapplicable.
All statements (including assignment, if and while) return some value, and can be used in expressions.
This is not true. In C only expressions have values. 'if' and 'while', for example, have no value, not even of type void. One could also consider the goto statement, which not only doesn't return a value, it also can't really be said to 'return' at all, since control flow is non-sequential there.
Logic and arithmetic expressions can be intermixed.
While true, this is a direct counter-point to what this section *should* be arguing. In C at least prior to C99, there was no separate boolean type - logical expressions *were* arithmetic expressions. This is an example of a problem caused by too *little* orthogonality, not too much.
This can cause side effects and cryptic code.
This statement is false. The presence of an assignment operator is what causes side effects in C. Also, side effects are not a disadvantage of C, they are a fundamental mechanism of the imperative paradigm that C exhibits. Based on word usage in the cited document, perhaps the original author meant "side effects" in some sense other than the widely-used computer science definition Side_effect_(computer_science), but without the context of the rest of the article, the use of "side effects" in a computer science article is misleading. And a reading of the cited source reveals that its author Eric_S_Raymond is arguing the exact opposite of this claim - that a *lack* of orthogonality causes "side effects". Also, since the first bullet point is wrong and the second is a disadvantage of a lack of orthogonality, there would no longer be any argument in this section to support the claim (opinion, really) that orthogonality causes 'cryptic code'.
Since languages need large number of components, too much orthogonality can cause problems. From a language designer’s point of view, the most difficult task (and an important one) is to strike a balance.
The first statement takes the form "Since X, then Y", but X does not imply Y. Supporting this claim would require some kind of reference, or at minimum an example of a way in which a lot of language components (I think "aspect" or "feature" probably better encapsulates this idea) makes orthogonality undesirable. This statement is not supported by the (admittedly uncitable) common knowledge of the software development field, nor by the one citation on this article.
My recommended fix is to just delete the entire "Disadvantages" section. I will visit back at this page sometime on Friday September 21, and if nobody has responded to this talk, I will delete the section.
Plagiarizing Concepts of Programming Languages
The first sentence of this article is:
In computer programming, orthogonality in a programming language means that a relatively small set of primitive constructs can be combined in a relatively small number of ways to build the control and data structures of the language.
In Concepts of Programming Languages (10th edition) by Robert Sebesta, on page 8 (section 188.8.131.52) orthogonality is described as:
Orthogonality in a programming language means that a relatively small set of primitive constructs can be combined in a relatively small number of ways to build the control and data structures of the language.
Exceptions in C
The following list item is in the list of exceptions in C:
- A member of a structure can be any data type (except void), or the structure of the same type.
Shouldn't the parentheses around "except void" also encompass "or the structure of the same type"? It was my understanding that a struct cannot have a member that is of the same type as the struct itself. . . which is why we use pointers for linked lists, no?
The example showing the difference between the implementation of the addition instruction in IBM mainframe assembler language and VAX assembler language seems to be biased towards the latter. Well, an advertisement for VAX will not help DEC since this company no longer exists.
But the reader is given incorrect information. Assembler language is closely related to machine code, and at this level it is inportant that the Add Register instruction only takes two bytes, and has no data access in memory, whilst the "Add" instruction is four bytes long and does access data in memory. Rbakels (talk) 00:40, 15 December 2015 (UTC)
I think the easiest way to describe something is with real life examples. The problem is, with the IBM Assembly mention, I'm not sure if an example was included or not. Format the text so we know if we're reading code or not. Cammy169 (talk) 18:10, 18 January 2016 (UTC)
Orthogonality vs Consistency
The article should point out the difference between Orthogonality and Consistency.
For example, PHP is inconsistent in its use of '_' in function names, forcing the programmer to remember isset vs is_null or stripslashes vs strip_tags. But this is not a lack of Orthogonality.