A syntax oditty 3000

[r]

--------------------------
A C language odditty 3000
--------------------------
1. The Dawn of C (skipped)
2. The Luncy of C's syntax
3. Jupiter Mission, C in the 21st centry
4. Syntactical elegance and beyond the Infinite


void warning {
If you worship the C/++ language(s) religiously and think it is the
perfect language "as is" {then stop reading immediately because you
may get offended! }

else {if you like the C/++ languages and think it could use some
improvements {then read on my brother! For we shall bring the archaic
C into the 21st century with much glory! -- kicking and screaming if
necessary ;-)}
}

---------------------------
2.The Luncy of C's syntax
---------------------------

[ground control to major tom!]
Of the many asinine redundancies within the language called C, i find
the the syntax most disturbing. Observing from an outside perspective,
it seems that spoon feeding the compiler is more important than
readability of source code! And i cannot completely understand the
logic(or lack there of) behind this design choice.

Specifically i am referring to the redundant use of braces over
indention and the redundant declaring of variable types. Both of which
have a much more elegant solution that put the burden on your compiler
and in turn makes for much more readable code!


//-- Braces --\\

First lets talk about braces. Braces are as ugly on people as they
are in source code(just ask Ugly Betty!).

When you litter source with braces the eye has a hard time reading
the actual code. And besides, do you know anyone that writes C code
without also using indention? Well there may be a few sadomasochist
out there but i would think the vast majority uses indention even
though the language does not force it!

So, if clearly many many people see the advantage of indention over
braces, why has the language not dropped the redundant braces and
forced all to use indention to denote a block?

And why would any programmer do that which is not forced upon them?
Well because they get a good return value from such efforts --
readable code!

Ok!, Ok! for backward compatability and S&M practictioners reasons we
could do...

#include indention


//-- Variables --\\

Secondly the asinine declaration of variable types is nothing more
than a way to quickly muddy up even the most simple of code! Integers,
strings, floats, and Constants can be "typed" by the compiler, no need
to declare them. You may ask yourself...?

"""How on Gods green earth can a stupid compiler determine what a
variable type is without me declaring it first"""

....easy, you handle this at the syntactic level!

-Strings: are any repetition of any chars delimited by "
-Integers: are any repetitions of chars in the set {0123456789} and
are NOT delimited by " or '
-Floats: are in the set {integer} and have a single <period> char in
them AND are NOT delimited by " or '
-Constants: use all caps (VALUE = 10)


//-- Tribal Warfare --\\

Another problem with free form languages is this constant warring of
which free form paradigm should be followed (yes, i'll bet none of you
have experienced this before *sarcasm*)

In a "free form" language such as C you get so many personal opinions
on how braces should be styled...

Cprogrammer1: Braces should go here!
Cprogrammer2: No! they should go there!
Cprogrammer3: No! your both wrong!

Lets put an end to the madness once and for all. Force indentation or
at least give the programmer a choice between archaic redundancies and
elegant beauty.

Some say coding style and clean syntax is an art, i say it is a
necessity. Why you ask? Well so everyone can clearly and quickly
understand everyone else's code. Here are three version of a very
simple function. You decide which is easier on the eye

Currently you C programmers are like poor old major tom, just floating
aroung in a tin can, your syntax has left you blue, and you just don't
know what to do?! """Your circuit's dead, there's something wrong, can
you hear me major tom?"""


---------------------------------------
Jupiter Mission, C in the 21st centry
---------------------------------------

Here are three version of a very simple function. You decide which is
easier on the eye.

// el feo!
static void* function( obj)
{
newobj = convert(obj);
if (obj && newobj)
{
DECREF(newobj);
return obj;
} else {
if (newobj) {
DECREF(newobj);
}
ErrorClear();
return 0;
}
}
}


// el malo!
static void* function( obj) {
newobj = convert(obj);
if (obj && newobj) {
DECREF(newobj);
return obj;}
else {
if (newobj) {
DECREF(newobj);}
ErrorClear();
return 0;
}


#using indention
#using clear_syntax
#using your_brain_and_not_your_back!

// el muy bueno!
def function(obj)
newobj = convert(obj)
if obj and newobj
DECREF(newobj)
return obj
elif newobj
DECREF(newobj)


----------------------------------------
Syntax Elegance and Beyond Infinity
----------------------------------------

And now with the chains of redundancy broken a new evolutionary path
has been laid before your eyes. You are reborn as the starchild.
Master of your coding universe!

....This is Major tom to Ground Control
....I'm doing so much more!
....because I'm writing code in a most intelligent way-ah
....And the code looks very elegant tody-ah-ah!

The black monolith of evolutions next step is before you. Will you be
intelligent enough to use the knowledge contained within, or run away
with tail tucked, you be be the judge...?

 

[r]

"r" <[email protected]> ha scritto nel messaggio








the above has at last one } more

// el feo!
static void* function( obj)
{
    newobj = convert(obj);
    if (obj && newobj)
       {DECREF(newobj); return obj;}
    else {if (newobj) {DECREF(newobj);}
          ErrorClear();
          return 0;
         }



}
}

That just shows that even experienced C hackers like your self suffer
the unreadability of braces. Humans are not parsers. And C is not the
worse by far. Lisp is the holy grail of unreadability. But there is no
hope for lisp anyway. However there *is* hope for C/++ if you guys
crusade for change.

Indention will always win over braces as far as readability counts,
because it is elegant! The "and" && "or" verses "&&" and "||" is a
preference, i prefer "and/or" but i would be happy with either one.
But with all the warring and unreadability of braces, i just can't
understand why there is no crusade for the entrance of C/++ into the
21st century of readability?

Change must come eventually get to C, or evolution shall stamp it out
utterly.

 

[Thad Smith]

void warning {
If you worship the C/++ language(s) religiously and think it is the
perfect language "as is" {then stop reading immediately because you
may get offended! }

else {if you like the C/++ languages and think it could use some
improvements {then read on my brother! For we shall bring the archaic
C into the 21st century with much glory! -- kicking and screaming if
necessary ;-)}
}

You list potential advantages to alternate syntax to C and at least some
have validity for ease of use. I don't see them as a compatible
modification of C.

You have my best wishes for your new language.

 

[Seebs]

(I could have the attributions wrong; I can't figure out how you're
indicating attributions.)

#it is not a preference, they are better readable

I would consider it a preference; I actually find &&/|| more readable.

i prefer "and/or" but i would be happy with either one.
But with all the warring and unreadability of braces, i just can't
understand why there is no crusade for the entrance of C/++ into the
21st century of readability?

Because I've used languages that try to be "very readable", such as
AppleScript, and they are a ton more work to write, read, and maintain.

Efficient use of symbols is also a kind of readability.

Change must come eventually get to C, or evolution shall stamp it out
utterly.

Could be. If something genuinely better comes along, I'm all for it. But
honestly, your proposed alternative strikes me as worse.

Well-chosen symbols are a good design for a language. Try taking this
same crusade to mathematics; push for the elimination of cryptic sigils
such as "+" and "=" in favor of "plus" and "equals", and see how far
you get.

-s

 

[Nick Keighley]

 The Luncy of C's syntax

 Of the many [] redundancies within the language called C, i find
the the syntax most disturbing.

 Specifically i am referring to the redundant use of braces over
indention

if you want python you know where to find it

<snip>

 

[bartc]

Here are three version of a very simple function. You decide which is
easier on the eye.

// el feo!
static void* function( obj) ....
ErrorClear();
return 0;

#using indention
#using clear_syntax
#using your_brain_and_not_your_back!

// el muy bueno!
def function(obj)
newobj = convert(obj)
if obj and newobj
DECREF(newobj)
return obj
elif newobj
DECREF(newobj)

If this is supposed to be Python-style then you seem to have missed out some
colons. And a couple of lines of code present in the other versions.

And, 'function' is a really bad name for a function especially when you are
introducing new syntax where, for all we know, 'function' could be a
keyword.

(One problem with this syntax: try temporarily wrapping the body of the
function in another statement, using an editor that cannot indent a whole
block at once. And if you have such an editor, what happens when you
accidently add or remove indents and most of the logical structure of your
program disappears?)

 

[r]

(One problem with this syntax: try temporarily wrapping the body of the
function in another statement, using an editor that cannot indent a whole
block at once. And if you have such an editor, what happens when you
accidently add or remove indents and most of the logical structure of your
program disappears?)

er... i wrote an editor in less than a thousnad lines of code that
does all i need, try to use something more intelligent than M$
notepad, and your life will be much easier. ;-)

Did someone blubber the words AppleScript? Maybe I'll reply to *that*
post as soon as i can stop uncontrolably laughing.

 

[bartc]

er... i wrote an editor in less than a thousnad lines of code that
does all i need, try to use something more intelligent than M$
notepad, and your life will be much easier. ;-)

Relying on a character or two of white space at the beginning of a line is
still a more fragile way of defining structure than other schemes which are
more likely to raise syntax errors when something is amiss.

Anyway, if you actually *need* the benefits of C, you will either need to
write C syntax, or to write another thousand lines of code (probably a lot
less) to translate your indented-format into standard C.

 

[Nick Keighley]

Relying on a character or two of white space at the beginning of a line is
still a more fragile way of defining structure than other schemes which are
more likely to raise syntax errors when something is amiss.

actually in practice it seems to work quite well. But then I'm
convinced that the guy who designed python stole my pseudo-code.
I also use a reasonable competant editor

<snip>

 

[Tom St Denis]

//-- Braces --\\

 First lets talk about braces. Braces are as ugly on people as they
are in source code(just ask Ugly Betty!).

 When you litter source with braces the eye has a hard time reading
the actual code. And besides, do you know anyone that writes C code
without also using indention? Well there may be a few sadomasochist
out there but i would think the vast majority uses indention even
though the language does not force it!

So, if clearly many many people see the advantage of indention over
braces, why has the language not dropped the redundant braces and
forced all to use indention to denote a block?

Your complaint here is just from a lack of experience. That's all.

There are times where subtle violation of coding style actually makes
more sense. For example, I personally always use the style

if (expr) {
stmt;
stmt;
}

Where I indent the if'ed code with 3 spaces, put the { on the if line
and } on a newline. It makes it super easy to see what code is part
of the if block, and the {} braces means if I add more than 1 stmt I
don't have to worry about scope.

Now there are times where I have something like

if (expr) { stmt; goto error_handler; }
if (expr) { stmt; goto error_handler; }
if (expr) { stmt; goto error_handler; }
if (expr) { stmt; goto error_handler; }

Like when doing a block of bignum code. I put the { }'ed code on the
same line since most of the time it's all the same [with some minor
changes] and really just gets in the way of reading what's going on.
You can do the indented style in Python style tab indentation for
scope, but you can't do the latter. You'd have to use exception
handlers at that point.

 And why would any programmer do that which is not forced upon them?
Well because they get a good return value from such efforts --
readable code!

Don't underestimate the ability to quickly scan code.

//-- Variables --\\

Secondly the asinine declaration of variable types is nothing more
than a way to quickly muddy up even the most simple of code! Integers,
strings, floats, and Constants can be "typed" by the compiler, no need
to declare them. You may ask yourself...?

Um, I don't know what to say to this. Having to pick a data type for
my variables has never really caused any harm to any of my development
plans. Usually I use standard types in my programs like int for error
codes, unsigned long for lengths of data, unsigned char for octet data
[yeah, I know CHAR_BIT >= 8], etc.

Maybe you just need to think harder before you code?

//-- Tribal Warfare --\\

 Another problem with free form languages is this constant warring of
which free form paradigm should be followed (yes, i'll bet none of you
have experienced this before *sarcasm*)

 In a "free form" language such as C you get so many personal opinions
on how braces should be styled...

From what I've seen there is a fairly constant drift towards the
following simple rules

- put { on the same line as the stmt controlling the block flow [if,
while, do, switch, for]
- put } on a new line
- indent inside code a 'tab' or 3/4 spaces

Once you write your first buggy program with code like

if (expr)
{
stmt; } else
{
stmt;
}

or whatever random style you use, you'll appreciate the consistency of
the simple 3 step I wrote above.

<snip>

Your complaints really just smack of inexperience. Once you log your
first decade or so writing C programs you'll calm down and figure
things out. Not everything is as black and white as you mention. For
example, one of my co-workers uses the style

if (expr)
{
stmt;
}

Which I think wastes a line for the { but otherwise is just as easy to
read as putting the { on the if line. We don't fight over it.
Basically if I have to work on code he's written I change them up as I
work on blocks of code, otherwise I leave them as he wrote them.
Seems to work for us.

Same thing for a lot of other style things. Like how to deal with
'else' ...

if (expr) {
stmt;
} else {
stmt;
}

Is fairly standard and very easy to read. Most experienced developers
adopt that or some subtle variation thereof.

That all being said, like I said at the start, the flexibility of C's
tolerance to white space is very useful. Sometimes the code is
trivial or consistent and doesn't need to be as pretty to make the
rest of the code legible.

And although discussions of C syntax are on topic here, could you do
without the inflammatory introduction? I don't know of any regulars
here that are "insulted" or angry about discussion about the C syntax
in a constructive fashion. And posting anonymously under different
names is not really required, now is it spizolla?

Tom

 

[r]

(--snip--)

Now there are times where I have something like

if (expr) { stmt; goto error_handler; }
if (expr) { stmt; goto error_handler; }
if (expr) { stmt; goto error_handler; }
if (expr) { stmt; goto error_handler; }

you need to wrap that up into some reusable code structure... ick!

(--snip--)

Your complaints really just smack of inexperience.  Once you log your
first decade or so writing C programs you'll calm down and figure
things out.

Yes you could probably become accustomed to just about any form of
torture after enduring it for a decade. But the brainwashing would
have taken hold much sooner.

(--snip--)

That all being said, like I said at the start, the flexibility of C's
tolerance to white space is very useful.  Sometimes the code is
trivial or consistent and doesn't need to be as pretty to make the
rest of the code legible.

c.od..e s.h.ou.ld a.lw...ays sta.y consit...ent
l.est .it .bec..om.e ..un.readbl..e

And although discussions of C syntax are on topic here, could you do
without the inflammatory introduction?  I don't know of any regulars
here that are "insulted" or angry about discussion about the C syntax
in a constructive fashion.  And posting anonymously under different
names is not really required, now is it spizolla?

Did you not read my disclaimer? and who the heck is spizolla?