OSNews

Ylai responded to:>>>>>>>>.
Oh c'mon, it's rather widely known that C doesn't score high on the 'easy-to-read' rankings.

...with...

That depends heavily on factors like (I mentioned) training, personal "reading taste", and ultimatively the program itself.
<<<<<<<<<<<<<<<<<

Obviously, anyone can train themselves to believe that some piece of code is "very readable." However, the readability metric is not based on what one person thinks, but what the programming community at large thinks of the code. The fields of software engineering, psychology, and graphic arts have made considerable contributions to answer the question "what is readable code?" And that research has made a *huge* point of eliminating "personal reading taste" from the equation. Anything built on "personal reading taste" is going to be subjective, at best. The phrase "readable code" generally implies that *most* people can read and comprehend the code, not just those who share the same "personal reading taste" as the original author.


ylai also wrote:>>>>>>>>>>>>>>>> >>>>>
Perfectly indented FORTRAN77 with tons of goto is not going to score higher on your "easy-to-read" raking, even being less "symbol-loaded" than C.
<<<<<<<<<<<<<<<<<
Yes, it is a well-known fact that you can write unreadable code in *any* language. That's not the issue. The question is "how easy does a language make it to write readable code?" For example, FORTRAN IV *forces* you to use those same goto statements; you have no choice. FORTRAN77, OTOH, provides (good) structured control statements, making structured programming possible. This makes it *far* easier to write readable code in F77 than in FIV.

Ylai continues:>>>>>>>>>>>>
And on the other hand, 2/3 level loops is also not making an equivalent Pascal code more readable than Fortran 95 with direct array assignments.
<<<<<<<<<<<<<<<<<&l t;<<<<<<<<<

Yes, language facilities make it easier to specify abstract operations in a more readable form. This is one of the failings of C (and assembly language, to be fair): there are so few very high-level abstractions available. This is why C (and assembly language) programs are often considered to be less readable than programs in high-level languages.

ylai continues:>>>>>>>>>>>>>>
There is simply no language XY => unreadable logic.
<<<<<<<<<<<<<<<<<&l t;<<<<<<<<<<<

No, but there are many languages {a,b,c,...} that have features that make it easier to write readable programs than the languages in a second set {x, y, z, ...}.

For example, Pascal might be in the first set, and C might be in the second set for many problem domains. Functional languages might be in the first set and imperative languages in the second set for other problem domains.

For generic programming problems in imperative programming languages, most people feel that C is in the second set.

ylai continues:>>>>>>>>>>>>
Also arguing that assembly, even HLA is easier to read comes very close to a joke.
<<<<<<<<<<<<<<<<<&l t;

Your statement is incomplete. "easier to read" than what? There is no question that assembly language (even HLA) tends to fall into the second set of languages I was describing above. And *traditional* assembly languages are among the *worst* when it comes to helping you write readable code. One important design goal of HLA was to make it possible to write more readable assembly language programs. To achieve this goal, HLA adopted certain syntactical elements from various HLLs that have well-known, and good, impact on the readability of code. Does this mean that HLA is going to be easier to read than C? Of course not. What it does mean is that it's going to be a lot easier to write easier to read HLA source code than it will be to write easier to read MASM (or fill in your favorite traditional assembler here) source code.

To achieve this goal, HLA approriated some of the *better* syntactical elements from various HLLs and avoided those items that had superior alternatives. For example, HLA uses statements like IF..ENDIF rather than the Pascal IF <stmt> or C's if <stmt> because these blocked statements are generally easier to read than the "statement plus compound statement" that Pascal and C use. Likewise, I chose a variation of C's syntax for conditional compilation directives because C's syntax is generally better than the alternatives I've seen. As for strings and escape sequences, better solutions exist out there than the C-style character escape sequences, so I chose a different path than C.

ylai continues:>>>>>>>>>>>
But all this is simply irrelevant for the discussion. There is plainly no technical reason to avoid C escapes,
<<<<<<<<<<<<<<<<<&l t;<<<<<<<<
I suppose this would be true if you don't consider readability a technical reason. Then again, what's the technical reason for *using* C escape sequences?


Cheers,
Randy Hyde