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...

 

[dkediger]

I think VB-Style code tends to be a little more format "flexible" and verbose meaning a good code snippet can be used as an example to a non-technical person and get the intended point across. The flip side is bad VB-style is really, really horrid.

You've hit the nail on the head with C-style terseness, and less verbosity, hopefully making coding sessions more productive.

 

[AndyWatt]

I use the hungarian notation advocated by, but utterly ignored by, Microsoft in the VB programmer guide. e.g. strings start "str", booleans "bln", with prefixes for module-level, global and so on. Of course the downside of this is that it can take one several minutes to write a reasonably short routine. recently I've gone back to single letter variable names : strX rather than strStringValue. I now find it hard to read code of the "MyVal" ilk.

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

 

[lionelhill]

Terseness is good if you're a slow typist, but it doesn't always make for readable code (well, if you're a quick C-thinker and a slow, slow reader, maybe it helps!)

No other language has generated "contorted programming" contests in the way that C has. Although it shouldn't have to be hideous, even C that wasn't intended for competition purposes is sometimes less than clear to anyone but the original purpetrator; as languages go, C is very abusable.

Discussions like this tend to get partisan since we all like what suits us. I'm not sure there is a single perfect syntax.

 

[MasterRacker]

Variable names is really a separate discussino, although some languages seem to have "standard" conventinos. Personally I can't stand including data types in the name. I also don't like the VB tendency to use full words for almost everything. To me "VndFName" and "VndLName" is just as understandable and easier to read than "VendorFirstName" and "VendorLastName".

I like terseness because it gets the most information at once visible on a screen. (10 pt. text on a 1600x1200 screen is my favorite setup)

Source code is for programmers and compilers. I think readability for non-techies is irrelevant. Any language can be abused and yes, C's flexibility makes it more abusable than most. My point is that, for me, it's faster to dig out the underlying logic from well-formatted C code than other languages.

I agree there's no "perfect" syntax. This is more of a "for fun" discussion.


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

 

[dkediger]

I am the programmer (also net admin, etc) for a company. I'm currently converting an older consultant developed VFP program into .NET/SQL Server. We own the source for the VFP project.

My employer "designed" an even earlier version of this system in Paradox, so she is well somewhat acquainted with programming logic in general. In ad-hoc discussions regarding our business logic, I often find myself "diagramming" in VB-style statements, as this can be followed and discussed, but will then implement those in C-style which I would doubt would be as accessible to the type of discussions we have.

 

[CajunCenturion]

I think you bring up several issues.
With regard to syntactic differences consider the following

i++;

vs

  i=i+1

and

i+=2;

vs

  i=i+2

the C syntax certainly is preferable in my book, and is shorter, but on the other hand

for (i=1;i<=9;i++)

vs

  For i=1 To 9

I prefer the VB style, which is shorter. From a readability standpoint they is no appreciable difference. Both are substantially superior to either of the following:

COMPUTE I = I + 1

or

PERFORM VARYING i FROM 1 BY 1 UNTIL i = 9

(or somthing similar, been longer than I care to admit since writing in COBOL).
In a similar vein C requires that the conditional expression of an If statement be enclosed in parens where as VB does not (although out of habit, I always even in VB enclose conditions inside parens), but because of the requirement that C imposes, I think VB is better. I think C has better looping boundaries as in

For I = 1 To 9 ... Next I

and the

for (i=1;i<=9;i++) { ... }

because it's shorter, but also the C blocking structure provides and even tighter scope for variables and such if you're really tight on memory management issues. The downside is that due to poor programming style, it can be quite difficult at time to figure out which loop ends where when dealing with and amount of nesting. In short, each is better in some cases and worse in others, but as previously alluded to, the style of the programmer is far more of an issue, meaning proper indendation, lining up of braces, and yes, variable naming conventions.

When you said "well-formatted C code", you hit the nail on the head. The bottom line, IMHO, is that for ease of use, ease of readability, ease of maintainability, the author's style is far more important than the specific syntax of the language.

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

 

[BakeMan]

I would have to agree with CajunCenturion on the formatting issue.

Although I don't do much work in C, I do code in JavaScript quit often (which is similar in syntax style). It really doesn't matter to me if I code in JavaScript or VBScript as long as the formatting is kept consistent. I always use the same naming conventions between the two and the same spacing and indenting rules. This (to me) makes the language irrelevant. To use an analogy, writing code is like writing a story. A well written story in English is still a well written story once translated into Spanish, French, or even Japanese. But if the story is jumbled and not well thought out, it won't make sense to anyone other than the author in any language.

Just my 2 cents,

BAKEMAN

 

[dilettante]

Well, as I write this Tek-Tips went down. Maybe this is an omen?

I'll refrain from including the offending Javascript (ColdFusion) code I was handed when the site died on me when it came back up. LOL! And no, I don't think it was a coding error.


Gosh, I wish I could recall in which thread I was doing the particular whining that you refer to MasterRacker. And yes, "whining" is my word, not yours.

I can rail on about C and C-derived languages' syntaxes (and semantics) at length, from a number of different angles. But this thread has taken a particular direction already, and in the interest of time I'll try to stick fairly close to it.

One of the nastiest things about C is its basic syntax. Some of this has already been covered eloquently above by CajunCenturian along with several points regarding some really good features of C-like syntax.

A lot of what we now take for granted in C was really done as it was in order to make it easy for the compiler to generate something close to good PDP-11 machine code - without a heavy optimizing compiler. As many of us know C was an evolution from the earlier B and BCPL programming languages. More history details are available at:

http://cm.bell-labs.com/cm/cs/who/dmr/chist.html

Goofy constructs like the iteration statement syntax and the pre/post increment/decrement statement syntax are fairly clear examples. I actually like the inc/dec statements, but I wish they had been done more generally and less machine-dependently, as for example in Burroughs Algol developed in the 1960s (and still alive today by the way):

A:=A+1

Can be represented by:

A:=*+1

And:

A:=A+(B/C)

Can be represented by:

A:=*+(B/C)

The last example may seem less useful, but shows that incrementing by other than 1 is easily done as in:

A:=*+3;
A:=*-SEGLENTH


But the thing that gives me fits in C-style languages is the way compound statements are handled.

You'd almost think these Bell guys were nothing but untutored hacks. It's like they'd seen Fortran, taken a peek at Algol, and then constructed a sort of "cargo cult" copy of what they thought they'd seen.

http://www.coolth.com/cargo.htm

So they said "hey, let's have semicolons." And "hey, let's have BEGIN/END compound statements and blocks" but "I'm too freakin lazy to type, let's use {/} instead of BEGIN/END." There seemed to be a general love of obscurity among these guys, which made them feel plenty 1337 using funky characters, but this is no big deal in itself.

How is:

A[SomeIndex+2]=A[SomeIndex+2]+((SomeBool)?3:17)

Better than:

A[SOMEINDEX+2]:=*+(IF SOMEBOOL THEN 3 ELSE 17)

... I ask ya? And yes, Burroughs Algol can use mixed case, it just isn't case-sensitive. But we won't go there right now.

These Bell guys seemed to have totally missed the point that the semicolon character is a statement separator and not a statement terminator (such as Cobol's use of the period). As a result we end up with a rule in C-style languages that reads something like:

"You need a semicolon when you need one. You can't have one when you can't have one."

Things got so ugly in Netscape's Javascript, with all its hack practitioners, that when ECMA firmed up the definition of ECMAScript (the current reference for implementations such as Javascript and JScript) they put in some funny rules. ECMAScript processors must basically be built so that when the script doesn't "make sense" the processor must back up and take a stab at what the author might have meant to write if they knew the language rules.

"7.8.1 Rules of automatic semicolon insertion

"When, as the program is parsed from left to right, a token (called the offending token) is encountered that is not allowed by any production of the grammar and the parser is not currently parsing the header of a for statement, then a semicolon is automatically inserted before the offending token if one or more of the following conditions is true:

"1. The offending token is separated from the previous token by at least one LineTerminator.

"2. The offending token is }.

"When, as the program is parsed from left to right, the end of the input stream of tokens is encountered and the parser is unable to parse the input token stream as a single complete ECMAScript Program, then a semicolon is automatically inserted at the end of the input stream."
:
:

The full gory details can be seen at:

http://www.el-mundo.es/internet/ecmascript.html

But where all of it ends up is at one conclusion: C is a nasty, poorly designed, little gutter language. It is very unfortunate that newer languages were derived from it without cleaning up many of the worst little nasties C embodies.

However, C is a fact of life that is hard to ignore. Like Microsoft's dominance - we may not like it all the time, but fighting it is like... spitting... into the wind. I write a goodly amount of C, C++, Java, and Javascript/JScript myself. I'm not a big fan, but it pays the bills, right?

My complaint isn't so much with C, et al. as it is cleaning up all of the nasty, hack code people write who don't at least take the time to understand it properly, and write decently formatted and reasonable code. Maybe I'm biased because I don't deal with a lot of throwaway code. I deal with stuff that was written years ago and patched and repatched multiple times. Some examples are around a decade old (and still growing hairier in the ears as we sit here).

My real gripe with C and sons is that it lets (and encourages) people to write some really poor quality source code. And since they can't read their own code a year or two later I have to stop and help them unravel it myself because "I just can't figure out where I'm going wrong here."

I see this with Cobol, Fortran, Algol, Pascal/Delphi, VB, PL/1, Ada, various scripting languages (save me from Perl, please!) - but the biggest headaches are always with stuff done using C and sons. Thankfully APL is all but dead.

If I had to choose (and had the opportunity) I think Delphi/Kylix offers the best choice among commercial languages right now. Borland has gotten some things right. Too bad it represents such a small niche in the market.

I'll refrain from going off on a tangeant about the abuse of pointers, lack of bounds-checking, random-assed implicit type coercion, clunky explicit memory management or goofy garbage-collect schemes, and the general "drunk on objects" philosophy of so many C++/Java programmers right now.

I hope the rant was at least amusing, and even more that some of it was informative. To quote Roger Murtaugh in those Lethal Weapon movies, maybe "I'm gettin' too old for this s..."

;-)

 

[sleipnir214]

I will admit that c-language will certainly allow a programmer the latitude to shoot himself in the foot if he so desires, but the fact that programmers may not write clear code isn't a fault of the language, but rather a fault of the programmers. It sounds to me like you're saying that if a person uses a knife to murder someone, we should arrest the knife and not the murderer. Crap code is crap code, regardless of the language.

And I know that using single characters as statement-block delimiters and requiring some token to separate statements sure makes the lexer easier to write. And in terms of readability, no block-terminator token is any better than another -- it's a matter of what your wetware lexer is expecting.

BTW...
dilettante, what's the practical difference between statement terminators and statement separators, except whether one is required at the end of the last line of your source code?

CajunCenturion:
What's the VB syntax that is the equivalent of the c-syntax
&quot;for (i = 0; i <= 9; i += 2)&quot;? Is VB still shorter?

Want the best answers? Ask the best questions:

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

TANSTAAFL!!

 

[dilettante]

The main difference is one of knowing when to use the separator/terminator. In languages with a &quot;rational&quot; syntax which use statement separators and not terminators the rule is simple:

Use a separator to separate statements from each other.

C tries to use some sort of hodgepodge of the two ideas, resulting in the &quot;ya need one when ya need one&quot; strategy.

So in a clean &quot;separator&quot; language, a program with one statement has none at all. Two statements: you have one separator. But it goes further. For example an &quot;if statement&quot; can be defined as something like:

IF conditional-expression THEN statement [ELSE statement]

... where the [] indicate optional syntax.

So... in an if statement you would never have a separator (say, semicolon).

Now, if a statement is defined as:

statement | {statement[; statement][; statement]...}

... where | means &quot;or&quot; and [] indicates optional syntax and ... indicates optional repetition, and you combine it with the if statement definition above, it becomes very clear where you use semicolons.

IF A<B THEN {
C=D;
E=F
}
ELSE {
C=F;
E=D
}

Note that there is no semicolon after the end of the if statement (none is needed unless another statement follows the if statement), no semicolon after E=F or E=D, no semicolon after the } before the ELSE, and so on.

This also allows for:

IF A<B THEN
C=D
ELSE
C=E

Neat and clean.

One of the biggest headaches in ECMAScript and its implementations is missing semicolons and null statements caused by the presence of semicolons where they should not be. That's why ECMA prescribes those funny rules cited above in my previous diatribe: to make sure all of these common errors in C-style syntaxed languages are processed in a consistent manner between implementations.

C, Java, and the like are a minefield of &quot;unterminated statement&quot; syntax errors because the &quot;rules&quot; are complex, erratic, and inconsistent. But the rules are there, it only looks like chaos.

The rules are something very like &quot;terminate every statement with a semicolon... except when we say otherwise, and other places where we say not to.&quot; So about all you can do is pull out your copy of K&R, stare at the (hopefully correct) code snippets, and &quot;trust the Force, Luke&quot; until you grok it in its entirety. Frighteningly, once you do &quot;get it&quot; it all eerily seems to make sense to you. Try describing it to a newbie who can't get his code to compile though. Many just &quot;bash it with the semicolon hammer&quot; until it does compile - and then hope it does what they thought they had described. This is why kludges such as lint were born.


I understand the knife analogy made above, but I think a chainsaw analogy might be better. C is a chainsaw with no guards, cutoff switches, or safety precautions of any kind. If you're darned careful you don't lose a finger or a leg.

I don't buy the &quot;newbie&quot; argument so much. Even pros don't disable all of the safety devices on their chainsaws, and they don't buy black market chainsaws without safety devices.

 

[CajunCenturion]

for (i = 0; i <= 9; i += 2)
for i = 0 to 9 step 2

Yes VB still shorter (unless you remove all of the spaces from the C statement). But that is rather inconsequential. More importantly, and expounding on some of dilettante's thoughts on the semi-colon, consider the following:

for (i = 0; i <= 9; i += 2);
for i = 0 to 9 step 2;

One will result in a compile time syntax error, and the other I've seen programmers take hours to find the bug. But I'm not a C-basher; I like C, and wish that I could do more work in C/C++. I really miss not having pointers and unions, among some other things.

But my business clients are more interested in Rapid Development (read less development cost and time) and couldn't care less about the language, and although it might make for a good debate for another thread, my experience has shown that VB generally is a less-expensive development language than C.

I sigh when I hear professional programmers call VB a &quot;toy language&quot;, because such comments are not in the best interests of the profession, but also the language, whatever language, is only a tool, just like the chainsaw or the knife. The language doesn't matter, it what the programmer can do with it, and how it's done. That's where the professionalism comes in. I remember seeing on &quot;Junkyard Wars&quot;, an individual make an airplane prop out of a fence board using a chainsaw. Or some of the magnificent ice sculptures build using chainsaws. I have no doubt that either of these artists could do the same with a reciprocating saw as well. The magic is not in the saw.

And the same thing is true with programming languages. The language does make a difference, but what really matters is the skill, logic, organization, and the professionalism of the programmer in applying that language to solving the problem at hand.

Based on some of the posts (not too many) I've seen in the programming language forums, including C, C++, and VB, I think the Texas Chainsaw Massacre would be rated “K”.

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

 

[dilettante]

Well, none of this is really worth getting too excited about - but it sure is easy!

One of the greatest things we have going for us is that we do still have some diversity left in our choices of programming languages. &quot;One size fits all&quot; is probably a pipedream, despite Sun's delusions of grandeur.

I think we tend to get into trouble most often when we see forced convergences between approaches. The clearest example of this in recent years is what happened to VB.Net, which has not (yet at least) become a very big hit.

There have been other attempts too, such as PL/1 that tried to mix together syntax concepts from Fortran, Cobol, and Algol in the 60s. While the result had some advantages it never really took off either.

Give me a bag of tools any day over some übertool approach.

 

[sleipnir214]

dilettante:
I'm sorry you had to spend so much time to grok c-language statement termination. I still don't understand what you're talking about about the difference between statement separation and statement termination -- you seem to be splitting hairs I can't even see. I didn't have to spend any time to grok c's statement syntax -- it was instantly and completely intuitive to me.


It seems to me that a good part of your problem with c-language is that you expect K&R's book to explain anything. There are two reasons I find this expectation unrealistic.

First, the K&R book, to be honest, is a very badly written one -- it's not well-organized, explanations, when they appear, tend to wander. If you were to go to your favorite bookstore and search the stacks for a good c-language guide to buy, without knowing anything about the history of the language, K&R would probably not be the book you'd pick. I'm convinced K&R's appearance on a programmer's bookshelf is roughly eqivalent to a sheriff's badge -- a symbol of station.

Second, the K&R book describes pre-ANSI c-language. The relationship of K&R C to ANSI C is roughly equivalent to Middle English's relationship to modern English. And I don't read Chaucer for tips on grammar and syntax.


BTW, you're not bad-mouthing PL/1 in front of CC, are you? He's got a soft spot in his heart for the language which dates back to his Multics days in college.

Want the best answers? Ask the best questions:

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

TANSTAAFL!!

 

[CajunCenturion]

Not just Multics, but PL/C before that on the IBM 360 at Chapel Hill, NC.

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

 

[dilettante]

No, I was mostly suggesting that PL/1 never caught on as widely as it might have. I had great hopes for PL/1 when I started using it in 1972 on an S/370. It got in trouble much like Ada did though, trying to wean Cobol people to a more modern language. This has pretty much been shown to be a lost cause except in IBM shops that have tried a heavy hand to force Java adoption. Problem is, there is as much Cobol as ever because Java doesn't fit the Cobol problom space as well as PL/1 or Ada do.

As for K&R, that was pretty much THE standard for C back around 1978 when I first started using it. You're right though - a lot has changed since the '70s and early '80s.

My problem isn't writing C, I've written thousands of lines of it. You use the right tool for the job and sometimes C is that tool. What I detest about C/C++/Java (and Javascript) is the time spent trying to explain things to other people who can't get their code to compile (and when it compiles, can't get the results they expect). Each of them have their own quirks about something as trivial as semicolon placement - and none of it is necessary.

The problem was solved decades ago in the Algol60 spec. It's funny to see Dennis Ritchie's backpedaling and explaining it all away in later papers, many of which are still online.

But... this thread was about preferences, which is about all we can really talk about. &quot;Merits&quot; are another thing altogether, very elusive, and I think they're quite situational.

 

[sleipnir214]

dilettante:
Never having messed with Algol 60 and unable to verify of even see whatever obscure Talmudic point you're trying to make about the use of semicolons in various languages, I'm just going to interpret &quot;The problem was solved decades ago in the Algol60 spec&quot; as &quot;dilettente was happier back then&quot; and agree to disagree with you.

Want the best answers? Ask the best questions:

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

TANSTAAFL!!

 

[lionelhill]

Cajun was spot on. The quality of the code is far more important than what it's written in. I am a dyed-in-the-wool pascal friend, but when I want numerical algorithms, it is Press et al. Numerical algorithms in C that I turn to, not our library copy of the same book in Fortran DESPITE the fact that the Fortran version includes all the recipes translated into Pascal, and account of how Turbo pascal handles things that is spot on.

The reason is that the C book examples were written in C and are good. The Pascal versions in the Fortran book were machine-translated and look like it (the authors admit as much; they quite reasonably chose not to introduce new pascal-specific errors by hand coding).

I'd rather try to make sense of good C than my favourite language used &quot;poorly&quot;.
But having said that, I'd rather do almost anything than try to make sense of bad C.

(Now don't get me started on HP Chemstation macro language...)

 

[Tarwn]

I have to agree that the readability of a language has little to do with a language. Hand me a well-written piece of code in any language and I can generally read it.
The problem is that generally. No matter how well written some code is, in certain languages it just gets extremely nasty to follow.

Python is a good example of forced formating. It's very easy to follow the flow simply because the programmer is forced to indent for code blocks. Then again you'll run into people who will assign a whole group of functions to elements in an array and make things completely unreadable:

#readable
for i in range(0,10):
   print "The square of " + str(i) + " is " + str(i * i)
   print "The cube of " + str(i) + " is " + str(i * i * i)

#not so readable
def square(num):
   return "The square of " + str(num) + " is " + str(num * num)

def cube(num):
   return "The cube of " + str(num) + " is " + str (num * num * num)

flist = [square,cube]
for i in range(0,10):
   for j in range(0,2):
      print flist[j](i)

Now obviously this is probably not a good use for the second method, but you can see how it coud be written in a very confusing manner even the the structure of the code on the page is relatively pretty (forced tabs).

VB or Java can get just as ugly as C. I've been known to embed three or four (ok, 9 or 10, I admit it) function calls into a single line of code simply because I couldn't be bothered to instantiate more temporary value holders. Then again, I also find myself missing ternary statements, so maybe I'm just odd like that.

Then again, while I like i++ and i--, who came up with ++i and --i?

And comparing C++ to Java?
Java: Hah, now everything is OO! well, everything except this, and this, and that, and this, but everything is OO!
C++: Hmm, a little paint, a couple extra swipes of the chainsaw, and Look! I'm OO now...err...sorta
VB.Net: Hmm...lang.append(C++) : lang.append(VB) : lang.append(Java) : pickle(list) ... Look I'm a new OO language for VB developers!

_{01000111 01101111 01110100 00100000 01000011 01101111 01100110 01100110 01100101 01100101 00111111}
The never-completed website:

http://www.tiernok.com/

 

[lionelhill]

Oops.

&quot;Then again, while I like i++ and i--, who came up with ++i and --i?&quot;

But aren't we supposed to avoid i++ and use ++i (for reasons of avoiding holding half-way values in the middle of calculations)?