Language Syntax Preferences

[MasterRacker]

This is in response to a comment dilettante made in another thread about hating the syntax C-style languages. I'm more of an admin type, but I've done some programming on and off over the years. I've used a half dozen Basics, a couple Fortrans, Pascal, an industrial robot language based on Pascal, VBA and a little bits of a few others.

In my case, when I got to C, I thought it was food of the gods. It could just be that I like terseness, but I find it to be the easiest to read language I've used yet. Just kind of curious to see what others think.


Jeff
If your mind is too open your brains will fall out...

 

[jrbarnett]

Tarwn

To add to your list:

Powerbuilder code can be written in an OO way if so desired (and unlike VB5/6, it does support inheritance) but it is also very easy to avoid the OO methods.

John

 

[CajunCenturion]

There is a very real difference between ++i and i++.

j = 2
i = 1
if (i++ = j) ==> returns false - i is evaluated for the comparison before being incremented
if (++i = j) ==> returns true - i is increments before being evaluated for the comparison.

I will admit that it many cases it doesn't matter, but in some cases it does, and that's why both exist.

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[sleipnir214]

lionelhill:
In the most simple use of the operators, ++i and i++ are functionally equivalent. For example, in the case of this code:

i = 1;
while (i < 5)
{
   .
   .
   .
   i++;
}

It really wouldn't matter whether you use the postincrement of preincrement operator.

However, in more complex statements, it makes a difference which operator you use, because of when the increment happens before or after the variable is referenced.

For example, the output of this program:

int main ()
{
        int i;
        int a;

        i = 3;

        a = i++ * 2;

        printf ("%d\n", a);
}

will be 6. The order of operations is:
1. a's value is set to be the value of i (or 3) times 2
2. i is incremented. (i's value becomes 4).

This program, however:

int main ()
{
        int i;
        int a;

        i = 3;

        a = ++i * 2;  //notice the preincrement

        printf ("%d\n", a);
}

returns 8, not 6. The order of operations is:
1. increment i. (i's value becomes 4)
2. set the value in a to be the value in i (or 4) times 2.



Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!!

 

[jrbarnett]

Hi

I have heard that the definition of a real C programmer is somebody who can give the correct answer to:

a=1;
b=1;
c = a++ + ++b;

What is the value of c?

John

 

[sleipnir214]

It should be 3.

Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!!

 

[jrbarnett]

Sleipnir214 - Correct.

Why? The Pre-increment of b is done before the addition, but a's post increment is not executed until after c has been totalled.

John

 

[sleipnir214]

But as a stylistic appendix to my last two posts, using [post|pre][increment|decrement] operators as parts of larger statements is, in my mind, generally a bad idea.

The examples I gave earlier and the one jbarnett just provided are difficult to read and thus degrade maintainability. As a general rule, in place of the line jbarnett has posted, I would code it as:

b++;
c = a + b;
a++;

Although the two code snippets are functionally identical, I think my rewrite is more explicit in what is going on, and thus is more readable, and thus is more maintainable.

Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!!

 

[lionelhill]

I think my problem with the whole "++" thing is it reminds me of the problem of functions that change global variables in pascal (and other languages).

Problem: if you have a function that changes variables other than through it's proper returning of a value, then it is extremely hard to trace errors, particularly in boolean expressions, where the function may or may not get called according to whether preceding terms in the expression were true.
e.g. (pseudocode)
dosomething if (myfunction == true) and (myotherfunction == true)
Above will normally only call myotherfunction if the first test is passed. And if myotherfunction is responsible for some drastic feature of the program (opening the file that dosomething will analyse...) then everything goes horribly wrong.

Kludge-solution: OK, OK, a function call is supposed to return a value, but we might use it to do something too, so lets just make sure that all the functions always get called. Turn off optimisation of boolean expressions...(option in turbo pascal etc.)

Proper Solution: make sure that while you are evaluating things, no things are allowed to change, and nothing is done! Evaluate the expression, and then do whatever is necessary based on that, in a SEPERATE statement (new line of code, or after the THEN of an IF)

C-solution: tell everyone C is only for proper programmers, and only provide functions, so everything has to be done by functions, half of which are voids that don't return anything. Anyone with brain-cells can tell what's going on. Ergo, anyone who's confused is just too thick for C and should take up VB instead.

So, for what little it's worth, I feel that it was a mistake in C to lump procedures and functions together. They are very different beasts. And expressions like i++ are basically mini-procedures (even if they are not coded as a call) in that they are bits of code that do something. They are also (worse!) mini-procedures that are just sitting there, tempting you to put them in long hairy expressions whose evaluation now becomes a nice little puzzle for programming students.

 

[MasterRacker]

This is getting fun.

C is easy to pick on. I never tried to calim it's the "best" language, just that I like it's terseness. I'm a quick reader but I just find other lanugages overly verbose. C's flexibility can certainly let you get yourself in trouble in a hurry. (Although I've never run into a problem through gross misuse of a pointer..[cough][cough] [can't say that and look 'em in the eyes...])

I'm going to throw out a new target: namely VB.NET's AndAlso and OrElse logical "short circuit" comparisons. Why do these things exist? I'm just learning VB.NET so I could be wrong, but to my knowledge, you can't do assignments inside a logical comparison so why would you ever need separate operators? Why not just build the quicker code into Or and And?


Jeff
If your mind is too open your brains will fall out...

 

[sleipnir214]

lionelhill:
The only salient difference between a function and a procedure is that a function returns a value and a procedure doesn't. Since any function can be treated as a procedure by simply discarding the return, it seems reasonable to me that only functions are really necessary. A lot of language developers seem to agree with this philosophy.

Nikolas Wirth, however, created Pascal to be a B&D pedagogical language, so forcing the programmer to explicitly program functions and procedures differently is actually a goal of the language. It's not a necessary feature.


Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!!

 

[Breadcrust]

i used to program a bit in qbasic, but now i program in tcl/tk. i find the syntax of tcl/tk and c to be so much easier to program with than shitty basics.

Breadcrust (aka J@red)

Web -

http://www.bcwebnet.tk

E-mail - net-head@softhome.net
Linux Reg. Number - 307180

 

[KornGeek]

I do a lot of coding in VB/VBA and derived languages currently, but my first language was Pascal, and most of my training was in C. Consequently, when I write pseudocode, I often combine elements of these languages.

I hate the way VB uses = for both comparison and assignment. C is slightly better by using = for assignment and == for comparison, but this is less than intuitive. I prefer Pascals solution of using = for comparison and := for assignment.

I personally prefer using
a++
instead of
a = a + 1 or a := a + 1
It gets to the point without wasting my time.

I also prefer the style of using {/} for begin and end (just a personal preference), and I like viewing everything as functions (even if they return a void). However, VB code tends to be easier to read and follow. Also, string handling is much easier in VB.

C has some nice features such as being able to use a variable as different data types (character once, then integer later) without running a conversion function. However, this opens up the possibility of undetected errors. Similarly, you can write VB code without explicitly defining your variables. This can be useful, but because I make frequent typos, it can also open up the possibility of undetected errors.

I think I generally prefer C, but each language has its own strong and weak points.

As an interesting (to me) side note, in the above discussion about the comparison of For loops, I realized that in the past 5 or so (at least) applications I have written, I have not used a single For loop. I use While loops instead. In my first programming class, we were discussing For, While, and Repeat/Until (Do/Until) loops, and on a quiz, the teacher asked which type of loop was the most versatile. In the discussion following, he showed us how the While loop can be used to do the same function as either of the other loops easily. Over the years, I guess my brain has adjusted and I almost exclusively use While loops.

 

[AndyWatt]

> I hate the way VB uses = for both comparison and assignment.

I agree. For example:

cmdOK.Enabled = strX = strY

I'd prefer

cmdOK.Enabled = strX == strY

or

cmdOK.Enabled := strX = strY

Simply because it looks a lot less like a typo. Mind you, after nearly ten years I'm more than used to it!

Andy
"Logic is invincible because in order to combat logic it is necessary to use logic." -- Pierre Boutroux
"A computer program does what you tell it to do, not what you want it to do." -- Greer's Third Law

 

[sleipnir214]

There can be downsides to having separate symbols. It really depends on what symbols are used in the language and how the selection can trip up programmers.

The operator symbols used by c-language are a good example. Think about how many times have you seen an inexperienced programmer get nailed using the wrong symbol:

if (a = 3)   when he meant   if (a == 3)

or 

if (a & b)   when he meant   if (a && b)

Most programmers don't need to get bitten more than once or twice to unconsciously use the appropriate operator. But this is the very reason why in Pascal, the single-character operator is comparison and the two-character operator assignment.

Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!!

 

[lionelhill]

Various comments on various things from previous posts:

MasterRacker,
I agree with you about OrElse and other such things. Someone once suggested to me that in any new language one should ignore all the special instructions that don't have analogues in other languages. They merely make it harder to port the code if you ever have to, and obviously aren't necessary, because other languages survive without them. It's probably good advice.

Korngeek,
Yes about For loops. Nine times out of ten there could be a case where running the loop at all would be a disaster (user has just asked to process variable length data but currently hasn't specified any data at all). "While" loops are just so nice cos you don't need any special case for running the loop zero times. No idea why for loops get taught first and so strongly. Probably history of Basic.

Sleipnir,
I still have problems with the difference between a function and a procedure.
(1) Blatantly pedantic point. There is no obvious reason to me why an operating system should necessarily accept a value (one value, no more!) from an exitting program. How would you implement C's main function on an operating system that does not accept a closing value from a process? I don't think languages should be written with a syntax that limits them wrt what operating system/machine they use (ideally).
(2) Functions are usually called in expressions to evaluate something else. Procedures stand alone. Calls in expressions/evaluations can happen in an order at the convenience of the compiler, or not at all if the compiler feels it knows the answer already. Therefore it is unwise to use a function to do something (apart from the returning of its proper value) that has to be accomplished in a particular order (or on whose accomplishment you later rely). So just to avoid errors and confusion, I like to keep the two separate in my mind even if the syntax overlaps. How many postings have you seen by people confused about cout'ing something with loads of ++'s and --'s? But that's a personal thing...

Thanks for interesting comments!

 

[Tarwn]

AndOr, OrElse:
These are not new. Perhaps the names are new, but the functionality is not new. Many languages will drop out of a boolean evaluation as soon as it becomes obvious what the results will be, thus saving precious execution cycles. For Instance:
If MyComplexFunction1() And MyComplexFunction2() Then...

If MyComplexFunction1 returns false in VB then it will still go ahead and waste time executing and evaluting MyComplexFunction2. There is no need for this because no matter what value returns for MyComplexFunction2, the reult is still going to be false.

If IsNumeric(txtBox1.Text) AndAlso cDbl(txtBox1.Text) = 42.5 Then

In this situation (perhaps its an entry validation) the short circuit allows us to put our two conditions in one statement rather than creating two statements (first check if it is numeric, then check if it's value is correct).

Off the top of my head I can't seem to remember which languages "short-circuit" on thjeir And's and Or's, but I do know that several do, so while the syntax is slightly differant from other languages (new words) the general functionality is not new.



[sub]01000111 01101111 01110100 00100000 01000011 01101111 01100110 01100110 01100101 01100101 00111111[/sub]
The never-completed website:

http://www.tiernok.com/

 

[sleipnir214]

lionelhill:
As I said before, just because something returns a value doesn't mean you have to do any thing with it. If I'm writing a c-language program on an OS that can't accept a return from an app when it exits, I have two choices: return a value, keeping in mind that the OS is going to ignore it; or code my main function to return void. Either way, a c-language program will work just fine. BTW, do you know of any OSes that can't accept a return from an application? I don't.

So you like to keep functions and procedures separate in your mind. Fine. This does not change the fact that a procedure is merely a function that doesn't return a value. Pascal (and probably Wirth's Modula family of languages, too, but I can't speak from experience) is explicit in differentiating between the two solely to teach programming students that there is a difference between the two. There is no universally compelling need for the differentiation.


Tarwn:
Are you saying that without the use of these oddball operators, VB is going to evaluate both sides of a logical operator, even if evaluating the second operand isn't necessary?

Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!!

 

[MasterRacker]

In the example Tarwn gave, using AND VB will continue the evaluation if the first condition is false and using ANDALSO it will stop as soon as it sees a false. That's my question - why have a separate operator? Why not just build themore efficient evaluation into AND and be done with it? When would you ever use AND in place of ANDALSO?

In C you can do assignments and comparisons all together in one big mess, so you may have to conclude the evaluation, however, why would you ever need to do it in VB?


Jeff
If your mind is too open your brains will fall out...

 

[CajunCenturion]

But, the issue that is being discussed has nothing to do with the language. Such optimizations are totally encapsulated in the efficiency of the compiler (or interpreter)

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[lionelhill]

MasterRacker, agree, that's the better way to do it.

Cajun, disagree, if the efficiency of the interpreter is such that new words get drafted into the language, it becomes a language issue. Also if efficiency of compiler influences whether the code works (i.e. without optimisation you will get a crash if first test checks that 2nd test is possible as in this case). But it's interesting: when does a different compiler become a different language??

Sleipnir, OK, OK, you're right! And no, I don't know an OS that can't accept a value, but nor do I know many cases where the value is used to do anything. Just one of those things, I suppose...