Are Some Programming Languages More Aspie than Others?

Post Reply New Topic

What docs are you talking about exactly? If you are talking about some software docs, that is a bit naive. You need to know what the possible return values might be more like.

I'm talking about documentation that comes with functions you didn't write. I'm talking about development on a large scale where you might not have access to the source code of the functions you're calling. How else would you know how to interpret the return values of a function if it's not documented? How is this naive? Do you go through the machine code provided by other developers to figure out what they are doing rather than referring to documentation?



No, I don't write that. If you read my previous posts you'd know I write it as


[/sarcasm]

Seriously, I get that you guys don't see the difference between that and my other examples. I chalk it up to differences of opinion. Deal with it. You're not going to convince me to change.

i'm not sure what the [/sarcasm] is for.

There is no syntactic difference between what I showed and your examples.

There is a semantic difference, in that your example, where you chose to exchange the two expressions supplied to the equality operator, one of those expressions happened to be a direct reference to a variable.

I actually do find the defensive code form "if (<constant> == <expression>)" to be occasionally useful. However, your compiler switches should be set to warn about the (probably accidental) usage "if (<variable> = <expression>)".

In fact, I often use that sort of semantic form, on purpose, and the compiler is happy to accept it when I show it was intentional, by writing it as "if ((<variable> = <expression>))".

Generally, though, using "if (<constant> == <expression>)" often obscures the meaning and the layout of code. It is not similar to normal speech. "if (MyApple == Red)" looks fine. "if (Red == MyApple)" is just silly.

To go back from C/C++ specifics to programming languages. This problem is special C/C++ problem. Languages which are based on Algol (Pascal, Ada, Modula) do not have the problem:



An assignment is always ":=" and is not allow in an expression to evaluate, so a typcial C-Expression like:



in Algol and Algol-based languages this would need to have the following form:


There are also other differences, that logical operators are written as logical operators:




The typical C/C++ typo of "&" "|" (bitwise) and "&&" "||" (boolean) can not happen!
---

In my option this programming languages based on Algol are here much better, because they separate clear the call of function (procedure) and evaluation of an expression and the assignment of data. In this respect C and C++ was a huge step backwards to lift this clear separation and allow potential error, which are only shown via compiler warnings.

Algol doesn't make function calls separate. They are constituents of expressions, just the same as just about all languages.

It is such a stilted coding technique: separating every function call onto its own line, with a temporary variable being assigned the result.

Also, accepting that an assignment is just another form of binary operator has always seemed far more natural to me. It was started in Algol and Coral, both of which allow multiple LHS assignment variables. C merely took their lead and improved on the idea. Pascal was more awkward, and took the form of a variable list, separated with commas, as the LHS of an assignment.

(I'm pretty sure that the Algol68 syntax covered everything that went into C, and far, far more. I've lost my copy of the Algol 68 report. I used to spend hours reading it.)

You are right - I had to look up, also for Pascal (it is a while ago I wrote the last time in Pascal and I confused the programming style I was trained with the actual standard.

The main different here remains that Algol and Pascal do not allow assigment in boolean expressions, quite sensitive.

Nonesense they should tell you what the function does not what statements to write, that is your job.

I think people are getting confused over the assignment and not focussing on the fact there is an unnecessary comparison being made.

If you do not wish to call the function more than once then assignment makes sense, but you still don't have to compare against true/false if the function returns a bool. Besides in many instances you can remodel your logic so it is one statement.

I guess I can best explain that I prefer my conditional statements to have some sort of comparison operator in them. I don't write (x > y) == true or the reverse as they already have a comparison operator. You seem to think that's confusing (along with flipping constants and expressions in conditionals) and I don't.



Please supply a quote of me where I said I expect function writers to document the statements I should write or do my job. I said:



Are you going to answer the question or just throw back another nonrelated statement?

So... assuming that we are talking C here, you are saying that documentation that baldly tells you that you must compare a return value to FALSE when you are aware that the value defined for FALSE is 1,315,926,085 is good documentation for a well designed system that will be bug free?

If such a situation did exist (which it does, from time to time), the documentation should be riddled with cautions explaining why the design is flying in the face of the language's defined truth values.

ah but it returns a value, just like a function can

You could have a function like IsGreaterThan(x,y). If you use an OO language '>' is a method of x which takes y. You could just as well substitute 'isGreaterThan?' for the method.

Whether it is a method, or construct doesn't matter it is there in order to retun a value. If you already have a return value there is no need to compare it to true/false.


You didn't understand my response or else you would not be asking that.

It is not their job to tell you what you should be comparing. It is their job to tell you what the possible return values are.

If I was given a library which internally defined FALSE to something other than 0, I probably would not use it. Or if I had to, I'd #define NAMEOFTHELIB_FALSE to whatever they use and use that in my code.

Lau, is this really the best example you can come up with to refute what I wrote? In the situation you describe, if there's no source code to identify the unconventional definition of FALSE - then yes, I'm going to follow the documentation on my initial run at the problem. Obviously the code won't work - I'll have to debug and identify the actual return values of the function and change my code to deal with it or move to a different library that behaves as it is documented. I don't understand how I would be "aware" of the unusual definition of FALSE without doing this or reading the machine code.



I didn't say there was a need to compare it. I said I prefer the syntax. Do you understand the concept that someone could prefer something you do not?



I fail to understand how you think they are different. Perhaps you can elaborate. In my mind, telling me the return values of a function also tells me what I should be comparing the result to.

Yes I understand you prefer (true==true) to true, suit yourself.



It assumes that you are going to compare it to anything. true is understood, it needen't be compared to true

(Why "internally"? I stated what the documentation specified.)

This is directly contradicting your statement that I just quoted. You stated that you would do what the docs told you to. Now you say that you would not.


What? You think that the documentation will prove to be wrong? Why would you imagine that?

You then seemed to say that you would then proceed to reverse engineer the code to figure out what MIGHT be the "correct" thing to do... and there you lose me... you now seem to be saying that the documentation should be ignored if it doesn't agree with your notions of what it should say.

If your code results in an error, rather than examining your code, where you have erroneously assumed that FALSE might be defined as 0, when I have stated that it was not, you will assume that your code is correct, and then analyse the library, for some alternative explanation, other than you ignoring the documentation?

==============

Oh! And I'm being very silly, aren't I? 0_equals_true. I forget how many languages I've known where you were the case. Of course, in C the truth value of zero happens to be false, so ((0 == true) == false) is not false.

Somebody called?

I thought you were stating that the documentation specified that the library uses and returns an usual version for FALSE. By internal, I mean that's what the library uses and that my program may use something else.




I said I would start there and if the docs didn't match the behavior I saw, I would attempt to figure out why. How is that a contradiction? I'm certainly not going to follow the docs, have a broken program and give up.




Because I just wrote a program using their library and the return code for the function is different than the documentation indicates it should be. I consider this to be different than receiving a documented error. If I receive a documented error, then I have to examine my code to make sure the input parameters are valid, the library has been initialized correctly, etc. But in your problem I'm receiving a value of FALSE that is undocumented and unusual.




If a function returns a value that does not correspond with its documentation, I'm going to try to figure out why. If the docs say a function will return TRUE or FALSE and I receive a value of 5, then I see 2 options:
1) Figure out if the return value of 5 somehow maps to TRUE or FALSE. Since I don't have the source code, I can either look through machine code or perform API testing to try to determine if 5 seems to map to TRUE or FALSE.
2) Give up and either use something else or bail on the project.

What would you do in this scenario, Lau?




Error or result outside the set of documented return codes?




I don't know what you're being. You seem to have a point to make but I'm not receiving it.