C Syntax
C# Learner
In its day, was it _really_ designed by snobby programmers to scare away
potential "n00bs"? If so, and after 50+ years of programming research,
why are programming languages still being designed with C's syntax?
These questions drive me insane. Every waking minute...
Alex Moskalyuk
In its day, was it _really_ designed by snobby linguists to scare away
potential "n00bs"? If so, and after 5000+ years of civilization,
why do Chinese people still using that funny syntax?
Eric Sosman
Mark A. Odell
news:uLRM6T2Q...@TK2MSFTNGP11.phx.gbl:
> These questions drive me insane. Every waking minute...
I would sleep more often then.
--
- Mark ->
--
Martin Ambuhl
> Why is C syntax so uneasy on the eye?
Because it's so pretty. That it is "uneasy on [your] eye" is your
problem. Not to worry; there's a solution for your problem. Jesus said
it, and it appears three times in the Gospels:
Matthew 5:29 And if thy right eye offend thee, pluck it out, and cast
it from thee: for it is profitable for thee that one of thy members
should perish, and not that thy whole body should be cast into hell.
Matthew 18:9 And if thine eye offend thee, pluck it out, and cast it
from thee: it is better for thee to enter into life with one eye, rather
than having two eyes to be cast into hell fire.
Mark 9:47 And if thine eye offend thee, pluck it out: it is better for
thee to enter into the kingdom of God with one eye, than having two eyes
to be cast into hell fire:
Default User
Go troll somebody else.
*plonk*
Brian Rodenborn
C# Learner
> Why is Chinese syntax so uneasy on the eye?
<snip>
You make a perfectly valid counter-argument.
I think we can conclude, then, that humans, in general, are a pretty
/stupid/ species. Note that this is /not/ a shallow thought.
Another example showing human stupidity, which is also related to
natural languages, is the fact that there are /so many/ natural
languages spoken by humans. Of cource, more than one natural language
is redundant, and causes problems involved with translation.
By the way, it's nice to see someone actually being able to provide a
decent counter-argument on a newsgroup without having to resort to
name-calling.
Alex Moskalyuk
C suddenly starts making perfect sense.
What's uneasy to you? Curly braces, parentheses, keywords, or something
else?
--
Alex Moskalyuk
_____________________________
http://www.techinterviews.com
"C# Learner" <csh...@learner.here> wrote in message
news:O2Jgg82Q...@TK2MSFTNGP10.phx.gbl...
Martin Dickopp
> By the way, it's nice to see someone actually being able to provide a
> decent counter-argument on a newsgroup without having to resort to
> name-calling.
While your original flamebait wasn't particularly an example of decency
on your part, at least have the decency to stop posting off-topic *now*,
please.
If you really believe that the intention of Alex' reply was to start
an elaborate discussion about the Chinese language in comp.lang.c,
I recommend that you stay off Usenet until you have learned to pick up
hints.
Off-topic, therefore Followup-To: poster.
Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/
C# Learner
> Have you ever looked into Perl or Lisp code?
>
> C suddenly starts making perfect sense.
>
> What's uneasy to you? Curly braces, parentheses, keywords, or something
> else?
One of the biggest flaws in C syntax, in my opinion, is the required
parentheses for test conditions.
Here's a very simple example:
void Foo
{
if (FooBar(Parse(Process(GetInput())))
DoSomething();
}
Imagine if, instead, we could write the following:
void Foo
{
if FooBar(Parse(Process(GetInput())):
DoSomething();
}
Python uses such a construct for test conditions.
Another nicety about Python is the fact that whitespace is used for
defining code blocks. This makes code much clearer than the equivalent
C code, which requires block being/end markers.
Here's a very simple Python code sample:
http://www.kernelthread.com/hanoi/html/py.html .
Try staring at it for one minute.
After having done so, take a look at this:
http://www.kernelthread.com/hanoi/html/c.html .
Even if one's accustomed to C syntax, the former is still clearer and
easier-to-read, don't you think?
Every time I see code that conforms to C's basic syntax, I cringe; yet I
write such code every day.
Why C? Why?!
Lew Pitcher
Hash: SHA1
I resemble that remark! :-)
FWIW, if you want a computer language that's really "uneasy on the eye", try
APL or RPG2. Even Lisp isn't very easy to read.
OTOH, I've had to read through pages of Java recently (analysis and design of
a new web component for my corporate masters, requiring review of our current
j2ee web apps), and if Java is the new "readability", then give me C any day.
Worse spaghetti code than you could find in any assembly program. I have no
doubt that C# and C++ are just as bad.
- --
Lew Pitcher
Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFAtS6VagVFX4UWr64RAi+RAKCnP8xUHTt6WJpucgZ6Aq6E1fmMoQCgndgX
eofd4o3IJyR9thmZlRXZwPg=
=PX6r
-----END PGP SIGNATURE-----
Justin Rogers
statement bounding in C to be quite nice. For me it improves readability as
my seasoned internal tokenizer is capable of finding code blocks more quickly
by using the braces and parenthesis than by scanning whitespace. Whitespace
also breaks down quite fast when you start using non fixed width fonts and
mixing tabs and spaces. Arguably you could say, don't do that, but at least
with something of the nature of C and it's explit block scoping you can easily
write a pretty printer and avoid any ambiguity that would otherwise exist.
Take the following excerpt from a Python tutorial:
Tuple syntax
From a syntax viewpoint, you create a tuple by placing a sequence of items
inside a pair of enclosing parentheses and separating them by commas. Note that
the parentheses can be omitted when such omission will not lead to ambiguity.
Note that they point out you can leave out parens only when it won't lead to
ambiguity. C doesn't make that mistake. They make sure there is no ambiguity,
and if you leave out a parens it doesn't make the statement ambiguous, it makes
it
a different or erroneous statement altogether.
--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers
"C# Learner" <csh...@learner.here> wrote in message
news:euOxH13Q...@TK2MSFTNGP10.phx.gbl...
C# Learner
Martin Dickopp wrote:
> C# Learner <csh...@learner.here> writes:
>
>>By the way, it's nice to see someone actually being able to provide a
>>decent counter-argument on a newsgroup without having to resort to
>>name-calling.
>
> While your original flamebait
My intention was /not/ to start a flame war, but to start a healthy
discussion on the subject of C and why its basic syntax is present in so
many modern programming languages.
If I had asked that question simply and directly, I doubt that many
would've given it a second thought. This is unfortunate detail to keep
in mind when posting to USENET, or other such Internet forums. There
needs to be a little spice to get a discussion going. This is what was
provided by myself in my thread-starter.
> wasn't particularly an example of decency
> on your part, at least have the decency to stop posting off-topic *now*,
> please.
Oh, now that Martin's joined the fray, we're no longer allowed to
continue a discussion which has a sub-thread which is /ever so slightly/
off-topic. Hmph.
> If you really believe that the intention of Alex' reply was to start
> an elaborate discussion about the Chinese language in comp.lang.c,
Please take the time to /read/ the messages you're replying to. My
reply only just touches on the subject of the Chinese language. My
intention was /not/ to start an elaborate discussion about the Chinese
language.
> I recommend that you stay off Usenet until you have learned to pick up
> hints.
http://www.winternet.com/~mikelr/flame12.html
> Off-topic, therefore Followup-To: poster.
I have no intention to e-mail my reply directly to you, so I disregarded
that follow-up. From the tone of your reply, it seems that had I given
you my e-mail address, I'd be harassed!
I've set follow-ups to microsoft.public.dotnet.languages.csharp, since
people in there are cool. However, my experience has shown that the
people in comp.lang.c, on the other hand, are a bunch of snobby a*******s!
I've posted in that group before and I got flamed in reply almost every
time. I also lurk in that group and notice that even regulars get
/regularly/ flamed there, for little or no reason.
Yeah, yeah, call me a troll. Whatever. This is my opinion, and you
asked for it by /flaming/ me.
Anyway, as I said, I'm not going to e-mail you, and may well proceed to
plonk you due to your heavy-handedness and your apparent snobby attitude.
Goodbye.
Lew Pitcher
Hash: SHA1
C# Learner wrote:
| Why is C syntax so uneasy on the eye?
I would disagree with that assertion; I do not find C syntax "uneasy on the eye".
| In its day, was it _really_ designed by snobby programmers to scare away
| potential "n00bs"?
"It's day" is hardly over, and the designers of C had other things on their
minds than attempting to scare away neophytes.
| If so, and after 50+ years of programming research,
| why are programming languages still being designed with C's syntax?
Perhaps because it works?
| These questions drive me insane. Every waking minute...
These are trivialities. Learn five or six computer languages (or three or four
that are entirely unrelated to each other), /then/ formulate your opinion.
Just remember, the computer doesn't care what language the program is written
in; it's all machine language to the CPU. Computer 'language' is for /human/
consumption, and is designed to meet the needs of the programmer and his/her
environment. Some languages are exceedingly suscinct (i.e. APL or RPG), and
some are very verbose (i.e. COBOL, SNOBOL, PL/I, Assembly (any processor)).
Some languages are procedural, some are OO, some are list processors, some are
macro languages. Learn a few, see what they do and where they are used.
Only then can you conduct a reasonable conversation on the topic.
- --
Lew Pitcher
Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFAtTl+agVFX4UWr64RAntoAJ9pk9dL4gzdc9Vk56pcIDMtV7yj4gCfY7k0
sTaxl6obapbLPdS7z9Hy6HI=
=jJJD
-----END PGP SIGNATURE-----
C# Learner
[...]
> | In its day, was it _really_ designed by snobby programmers to scare away
> | potential "n00bs"?
>
> "It's day" is hardly over, and the designers of C had other things on their
> minds than attempting to scare away neophytes.
By "its day" ("it's day" is grammatically incorrect, by the way), I
actually meant the days around which it was designed. I phrased it
incorrectly -- my mistake.
[...]
> | These questions drive me insane. Every waking minute...
>
> These are trivialities. Learn five or six computer languages (or three
> or four
> that are entirely unrelated to each other), /then/ formulate your opinion.
Well, I have learned BASIC, C-like languages (C and C++), Delphi
(formerly named 'Object Pascal') and Smalltalk.
So, basically, I've learned a couple of procedural languages, and a
couple of OO ones.
> Just remember, the computer doesn't care what language the program is
> written
> in; it's all machine language to the CPU. Computer 'language' is for
> /human/
> consumption, and is designed to meet the needs of the programmer and
> his/her
> environment.
Exactly -- and this is why I see high-level language syntax to be so
important.
I feel that popular, modern-day high-level languages are tainted by a
specific syntax that has carried over through decades, one which I feel
is somewhat inhibitive. I feel it's inhibitive in the sense that code
written in it needs to conform to a syntax that could be nicer, and make
for easier-to-read source code.
> Some languages are exceedingly suscinct (i.e. APL or RPG), and
> some are very verbose (i.e. COBOL, SNOBOL, PL/I, Assembly (any processor)).
> Some languages are procedural, some are OO, some are list processors,
> some are
> macro languages. Learn a few, see what they do and where they are used.
>
> Only then can you conduct a reasonable conversation on the topic.
I don't understand why I'd need to learn a few more languages to
understand that C's basic syntax could be nicer.
Kieran Simkin
> Alex Moskalyuk wrote:
>
> > Have you ever looked into Perl or Lisp code?
> >
> > C suddenly starts making perfect sense.
> >
> > What's uneasy to you? Curly braces, parentheses, keywords, or something
> > else?
>
> One of the biggest flaws in C syntax, in my opinion, is the required
> parentheses for test conditions.
I think you confuse a flaw with part of the language specification.
>
> Here's a very simple example:
>
> void Foo
> {
> if (FooBar(Parse(Process(GetInput())))
> DoSomething();
> }
>
> Imagine if, instead, we could write the following:
>
> void Foo
> {
> if FooBar(Parse(Process(GetInput())):
> DoSomething();
> }
>
I'm imagining, and I'm reminded of BASIC.
> Python uses such a construct for test conditions.
>
> Another nicety about Python is the fact that whitespace is used for
> defining code blocks. This makes code much clearer than the equivalent
> C code, which requires block being/end markers.
>
> Here's a very simple Python code sample:
> http://www.kernelthread.com/hanoi/html/py.html .
>
> Try staring at it for one minute.
>
Have just done so, this code (admittedly having never even looked at Python
before) seems completely unreadable to me. Maybe I'm just used to C syntax.
> After having done so, take a look at this:
> http://www.kernelthread.com/hanoi/html/c.html .
>
> Even if one's accustomed to C syntax, the former is still clearer and
> easier-to-read, don't you think?
No, not really. Python may be easier for you because that may be what you're
used to looking at, but C and PHP are what I do (PHP's syntax is more
similar to C's than Python's) and their syntax makes perfect sense to me. It
seems to me there may not be a "better" way; just different ways - although
it does seem to me that Python code would be prone to breaking when cnped
between things which do not preserve tab formatting for example (such as
some newsreaders).
One of the things I like about C is that whitespace most often doesn't
matter and I can control exactly how I want my program to look and read
rather than have it laid out for me by the language specification.
>
> Every time I see code that conforms to C's basic syntax, I cringe; yet I
> write such code every day.
>
> Why C? Why?!
This is the kind of question which could easily attract a lot of annoyance.
Obviously this entire post is off-topic. Python is not C, C will never be
Python and you've cross-posted to C# which is not C either.
Jack Klein
<lpit...@sympatico.ca> wrote in comp.lang.c:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Eric Sosman wrote:
> | C# Learner wrote:
> |
> |> Why is C syntax so uneasy on the eye?
> |>
> |> In its day, was it _really_ designed by snobby programmers to scare
> |> away potential "n00bs"? If so, and after 50+ years of programming
> |> research, why are programming languages still being designed with C's
> |> syntax?
> |>
> |> These questions drive me insane. Every waking minute...
> |
> |
> | If you want COBOL, you know where to find it.
> |
>
> I resemble that remark! :-)
>
> FWIW, if you want a computer language that's really "uneasy on the eye", try
> APL or RPG2. Even Lisp isn't very easy to read.
You haven't liven until you've seen badly written PL/M (note the 'M').
Their equivalent of C's switch...case still gives me nightmares after
all these years.
> OTOH, I've had to read through pages of Java recently (analysis and design of
> a new web component for my corporate masters, requiring review of our current
> j2ee web apps), and if Java is the new "readability", then give me C any day.
> Worse spaghetti code than you could find in any assembly program. I have no
> doubt that C# and C++ are just as bad.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
C# Learner
> "C# Learner" <csh...@learner.here> wrote in message
> news:euOxH13Q...@TK2MSFTNGP10.phx.gbl...
[...]
>>After having done so, take a look at this:
>>http://www.kernelthread.com/hanoi/html/c.html .
>>
>>Even if one's accustomed to C syntax, the former is still clearer and
>>easier-to-read, don't you think?
>
> No, not really. Python may be easier for you because that may be what you're
> used to looking at,
Aha, but I only saw Python code for the /first/ time yesterday. :-)
> but C and PHP are what I do (PHP's syntax is more
> similar to C's than Python's)
Cool.
> [...]
>>Every time I see code that conforms to C's basic syntax, I cringe; yet I
>>write such code every day.
>>
>>Why C? Why?!
>
> This is the kind of question which could easily attract a lot of annoyance.
Okay, I accept that. I don't mean to annoy -- it's just my style of
writing. If I've annoyed then I apologize to all those affected.
Also, I guess I'm just trying to make a point and get heard here; and,
at the same time, I want to hear what those who are more experienced
than me have to say on the matter -- especially C gurus!
For the record, I don't /hate/ this C syntax of which I talk. I just
have a feeling of disbelief, perhaps, that some badly-implemented (in my
opinion) syntactial elements of the C language have passed through to
modern programming languages.
> Obviously this entire post is off-topic. Python is not C, C will never be
> Python and you've cross-posted to C# which is not C either.
Hmm... I have to disagree. I feel that this discussion is about C's
basic syntax and its ubiquity in popular modern-day languages.
If such a discussion is off-topic for comp.lang.c, then I honestly don't
know quite where it would be /on/-topic. In fact, I even considered
renaming the subject of this post to 'Re: C Syntax', but didn't want to
enrage people by doing so.
In any case, this was also posted to
microsoft.public.dotnet.languages.csharp since I wanted to hear some
opinions from those people too, and that is also the group which I read
more.
Stephen Sprunk
> One of the biggest flaws in C syntax, in my opinion, is the required
> parentheses for test conditions.
Without the parens you would need a "then" keyword of some kind. It seems
like an even trade.
> Another nicety about Python is the fact that whitespace is used for
> defining code blocks. This makes code much clearer than the equivalent
> C code, which requires block being/end markers.
OTOH, C not using whitespace to mean anything gives programmers lots of
flexibility in how they format their source code to improve readability.
Block begin/end markers are very useful, and having such things explicit
arguably makes things easier for both the compiler and subsequent coders.
> Here's a very simple Python code sample:
> http://www.kernelthread.com/hanoi/html/py.html .
>
> Try staring at it for one minute.
>
> After having done so, take a look at this:
> http://www.kernelthread.com/hanoi/html/c.html .
>
> Even if one's accustomed to C syntax, the former is still clearer and
> easier-to-read, don't you think?
That depends on the reader; the C version is far clearer to me. You also
put error-checking into the C version that's not in the Python one, which is
unfair when considering code length.
S
--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
I. Appel
> > These are trivialities. Learn five or six computer languages (or three
> > or four
> > that are entirely unrelated to each other), /then/ formulate your
opinion.
>
> Well, I have learned BASIC, C-like languages (C and C++), Delphi
> (formerly named 'Object Pascal') and Smalltalk.
>
> So, basically, I've learned a couple of procedural languages, and a
> couple of OO ones.
And which one do seems you the best?
Which one seems to have the best syntax?
All your languages are Algol-derivative, so they share equivalent
syntactic constructs and all them are similar.
Try to learn something truly alternative. Try FORTRAN 77, the language
without any flame wars about indentation. Try LISP, the language with
syntax based on two symbols. Then come back.
When personally I met C, I already knew BASIC and Pascal and I was amused
by the expressiveness and brevity of C's syntax. I still think that
for (i=0;i<10;i++) {...}
is much better than
for i:=0 to 9 do begin ... end;
> > Some languages are exceedingly suscinct (i.e. APL or RPG), and
> > some are very verbose (i.e. COBOL, SNOBOL, PL/I, Assembly (any
processor)).
> > Some languages are procedural, some are OO, some are list processors,
> > some are
> > macro languages. Learn a few, see what they do and where they are used.
> >
> > Only then can you conduct a reasonable conversation on the topic.
>
> I don't understand why I'd need to learn a few more languages to
> understand that C's basic syntax could be nicer.
Suggest some improvements and I'll say you, why you're wrong ;-)
C# Learner
comp.lang.c police.]
I. Appel wrote:
> "C# Learner" <csh...@learner.here> wrote in message
> news:eSPUPt4Q...@TK2MSFTNGP09.phx.gbl...
>
>>>These are trivialities. Learn five or six computer languages (or three
>>>or four
>>>that are entirely unrelated to each other), /then/ formulate your
>
> opinion.
>
>>Well, I have learned BASIC, C-like languages (C and C++), Delphi
>>(formerly named 'Object Pascal') and Smalltalk.
>>
>>So, basically, I've learned a couple of procedural languages, and a
>>couple of OO ones.
>
> And which one do seems you the best?
> Which one seems to have the best syntax?
I'd say Delphi has the clearest syntax.
[...]
>>I don't understand why I'd need to learn a few more languages to
>>understand that C's basic syntax could be nicer.
>
> Suggest some improvements and I'll say you, why you're wrong ;-)
Simply:
1) Remove the need to specify parentheses for test conditions --
substitute a test condition terminator, such as Python's ':'.
2) Remove begin/end code block markers and require indentation instead.
Irrwahn Grausewitz
>[I'll do the courtesy of a reply at the risk of getting flamed by the
>comp.lang.c police.]
[No police around, only conscious people.]
>I. Appel wrote:
>
>> "C# Learner" <csh...@learner.here> wrote:
<snip>
>>>Well, I have learned BASIC, C-like languages (C and C++), Delphi
>>>(formerly named 'Object Pascal') and Smalltalk.
>>>
>>>So, basically, I've learned a couple of procedural languages, and a
>>>couple of OO ones.
<snip>
Note:
"Procedural" and "OO" are not mutually exclusive language concepts.
Smalltalk is a functional language.
>>>I don't understand why I'd need to learn a few more languages to
>>>understand that C's basic syntax could be nicer.
>>
>> Suggest some improvements and I'll say you, why you're wrong ;-)
>
>Simply:
>
>1) Remove the need to specify parentheses for test conditions --
> substitute a test condition terminator, such as Python's ':'.
>
>2) Remove begin/end code block markers and require indentation instead.
Who or what is keeping you from designing a language incorporating the
worst of BASIC/Pascal/Python/FORTRAN/etc. worlds? Not that it will
ever have a fighting chance to be used by anyone for anything but as
an example of a language with a syntax "uneasy to the eye".
"Doctor, it hurts when I look at C."
"Well, then don't."
Regards
--
Irrwahn Grausewitz (irrw...@freenet.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html
Richard Bos
> Why is C syntax so uneasy on the eye?
Beware the troll! This is cross-posted inappropriately.
Richard
Paul Hsieh
> Note that they point out you can leave out parens only when it won't lead to
> ambiguity. C doesn't make that mistake. They make sure there is no
> ambiguity, and if you leave out a parens it doesn't make the statement
> ambiguous, it makes it a different or erroneous statement altogether.
C has plenty of ambiguity:
- Braces are optional if there is only one statement for if() or for() or
while(). (But not for do ... while(), switch, or structure/union
declarations.)
- If a statement has multiple side effects, the order in which those side
effects take place can be unknown.
- The right shift operator may or may not sign extend signed integers. Its
implementation defined.
- The size of an integer is platforms specific.
- The number of bits in a bytes is platform specific.
- Try this one on for size:
char a = -1, b = -2;
unsigned short x = (1 > 0) ? a : b;
printf ("x = %d\n", x);
What do you think is printed out? Explain it.
--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
Jeremy Yallop
> "Justin Rogers" <Jus...@games4dotnet.com> wrote:
>> Note that they point out you can leave out parens only when it won't lead to
>> ambiguity. C doesn't make that mistake. They make sure there is no
>> ambiguity, and if you leave out a parens it doesn't make the statement
>> ambiguous, it makes it a different or erroneous statement altogether.
>
> C has plenty of ambiguity:
>
> - Braces are optional if there is only one statement for if() or for() or
> while(). (But not for do ... while(), switch, or structure/union
> declarations.)
The braces are also optional on switch and do-while statements:
do something(); while (not_finished());
switch (expression)
statement;
Struct or union declarations are not relevant: their components are
declarations, not statements.
None of your other examples were syntactically ambiguous.
Jeremy.
Dan Pop
>Why is C syntax so uneasy on the eye?
Uneasiness is in the eye of the beholder...
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
Grumble
> Simply:
>
> 1) Remove the need to specify parentheses for test conditions --
> substitute a test condition terminator, such as Python's ':'.
#define if if (
#define then )
int main(int argc, char **argv)
{
if argc-1 == 0 then return 666;
return 0;
}
Michael Wojcik
In article <V7atc.31023$sr3.8...@news20.bellglobal.com>, Lew Pitcher <lpit...@sympatico.ca> writes:
>
> FWIW, if you want a computer language that's really "uneasy on the eye", try
> APL or RPG2. Even Lisp isn't very easy to read.
APL?!! APL is beauty itself, manifesting as a swell set of new
keyboard caps. C'mon - just look at that cute little rho, or the
noble edifice of the dotted-quad.
Of course, few languages can produce source as readable as ETA's.[1]
> OTOH, I've had to read through pages of Java recently (analysis and design of
> a new web component for my corporate masters, requiring review of our current
> j2ee web apps), and if Java is the new "readability", then give me C any day.
> Worse spaghetti code than you could find in any assembly program. I have no
> doubt that C# and C++ are just as bad.
It's possible to write highly readable code in Java, of course, just
as it is in C, but many Java programmers for some reason seem to suffer
from a variety of common style deficiencies. I've seen a lot of Java
source which was apparently written in an editor with a 200-character
line length, for example.
As untold commentators have pointed out untold times, a talented
programmer can produce a mess in any language. There *are* languages
which make it more or less convenient to produce readable source, but
for all but the worst offenders it's possible. (The only real
counterexample I can think of would be an evil esoteric language,
even then perhaps only if it didn't permit comments. I don't think
Unlambda[2] has any provision for comments, for example. If it had
them, even an Unlambda program might be rendered readable, for
suitably small values of "unreadable".)
1. http://www.miketaylor.org.uk/tech/eta/doc/
2. http://www.eleves.ens.fr:8080/home/madore/programs/unlambda/
--
Michael Wojcik michael...@microfocus.com
Vinegar keeps more flies away than honey does.
I. Appel
> >>>These are trivialities. Learn five or six computer languages (or three
> >>>or four
> >>>that are entirely unrelated to each other), /then/ formulate your
> >
> > opinion.
> >
> >>Well, I have learned BASIC, C-like languages (C and C++), Delphi
> >>(formerly named 'Object Pascal') and Smalltalk.
> >>
> >>So, basically, I've learned a couple of procedural languages, and a
> >>couple of OO ones.
> >
> > And which one do seems you the best?
> > Which one seems to have the best syntax?
>
> I'd say Delphi has the clearest syntax.
Delphi is boring. IMO syntax of C is much more funny.
> [...]
>
> >>I don't understand why I'd need to learn a few more languages to
> >>understand that C's basic syntax could be nicer.
> >
> > Suggest some improvements and I'll say you, why you're wrong ;-)
>
> Simply:
Well, rephrasing Paul Graham, I should say "Don't wait until C will become
as
clear as Python, use Python instead".
> 1) Remove the need to specify parentheses for test conditions --
> substitute a test condition terminator, such as Python's ':'.
Actually in C it is permitted to build much more complicated conditions.
It's generally bad programming style, but that feature requires parenteses.
> 2) Remove begin/end code block markers and require indentation instead.
Block markers vs. indentation is IMO eternal flame war.
Francois Beaussier
> - Try this one on for size:
>
> char a = -1, b = -2;
> unsigned short x = (1 > 0) ? a : b;
>
> printf ("x = %d\n", x);
>
> What do you think is printed out? Explain it.
the same as in c# :
unchecked
{
char c = (char) -1;
ushort x = c;
Console.WriteLine(">> " + x);
}
>> 65535
wich is the way -1 is represented in 16 bits unsigned data ;)
what is your point ? what else where we supposed to expect ? 255 ?
--
Francois Beaussier
Fran...@3ie.org.remove
Mark McIntyre
<csh...@learner.here> wrote:
>One of the biggest flaws in C syntax, in my opinion, is the required
>parentheses for test conditions.
>
> if (FooBar(Parse(Process(GetInput())))
> DoSomething();
(he prefers)
> if FooBar(Parse(Process(GetInput())):
> DoSomething();
Okay, I'll bite. Why on earth do you consider this in any way an
improvement? What difference does it make to anything?
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Mark McIntyre
<csh...@learner.here> wrote:
>Aha, but I only saw Python code for the /first/ time yesterday. :-)
*shrug*
Me too. And C is much easier to read. YMMV.
>> Obviously this entire post is off-topic. Python is not C, C will never be
>> Python and you've cross-posted to C# which is not C either.
>
>Hmm... I have to disagree. I feel that this discussion is about C's
>basic syntax and its ubiquity in popular modern-day languages.
But the topic of CLC is the C /language/ and using it, not whether there's
a neater way to structure the language. You could try talking about that
over in comp.std.c, but I warn you, you'll get roasted in about 2 seconds.
Mark McIntyre
<csh...@learner.here> wrote:
>Aha, but I only saw Python code for the /first/ time yesterday. :-)
*shrug*
Me too. And C is much easier to read. YMMV.
>> Obviously this entire post is off-topic. Python is not C, C will never be
>> Python and you've cross-posted to C# which is not C either.
>
>Hmm... I have to disagree. I feel that this discussion is about C's
>basic syntax and its ubiquity in popular modern-day languages.
But the topic of CLC is the C /language/ and using it, not whether there's
Michael Voss
Irrwahn Grausewitz wrote:
[...snip...]
> Smalltalk is a functional language.
How do you define "functional language" ?
Alan Balmer
<kie...@digital-crocus.com> wrote:
>> Another nicety about Python is the fact that whitespace is used for
>> defining code blocks.
What you call a nicety <sic>, I call a liability.
--
Al Balmer
Balmer Consulting
removebalmerc...@att.net
Alan Balmer
wrote:
>Also, I guess I'm just trying to make a point and get heard here; and,
>at the same time, I want to hear what those who are more experienced
>than me have to say on the matter -- especially C gurus!
>
>For the record, I don't /hate/ this C syntax of which I talk. I just
>have a feeling of disbelief, perhaps, that some badly-implemented (in my
>opinion) syntactial elements of the C language have passed through to
>modern programming languages.
Forgive me if I'm wrong, but my impression is that you don't have a
deep enough understanding of the C language, and indeed of programming
languages in general, to appreciate the reasons for the syntax
features you're commenting on. Take your original example of
eliminating the deli meters around the conditional in an if statement.
Think about what this would mean for compound conditions. Combine that
with the Python-style blocking and then think about an if statement
which tests for several conditions, requiring more than one line to
write.
As you study and understand the language, you'll find that it's all
nicely consistent, and that there are good reasons for most of the
features which seem odd to you. One of the characteristics of C is
terseness, and extra parens aren't required by the language for no
reason.
Also, think about the fact that language inventors and implementers
are, by and large, a pretty bright bunch. In general, they probably
have more and wider experience in the field than you do, and some of
them might even be as smart ;-) Those features which have passed
through to modern languages have done so for a reason.
Guillaume
Delphi is Pascal with maybe a few bells and whistles.
Therefore, it's based on an older language than C, maybe that's why
it's a bit boring.
> Well, rephrasing Paul Graham, I should say "Don't wait until C will become
> as
> clear as Python, use Python instead".
If you really think Python has clearer syntax than C, well, think twice.
One terrible fact is this indentation thing in Python to delimit code
blocks. One tab or space is left behind, and the whole thing is screwed.
To me, it's an unacceptable syntax issue.
Dan Pop
>On Thu, 27 May 2004 03:40:42 +0100, "Kieran Simkin"
><kie...@digital-crocus.com> wrote:
>
>>> Another nicety about Python is the fact that whitespace is used for
>>> defining code blocks.
>
>What you call a nicety <sic>, I call a liability.
None of the programming languages assigning semantics to indentation
has ever become mainstream. There must be a reason...
Irrwahn Grausewitz
I don't - others already did. If you're interested in this subject
I suggest to Go Ogle for the comp.lang.functional FAQ - it contains
a nice explanation of functional vs. procedural programming paradigms.
Ob the portion you snipped: While both C++ and Smalltalk are OO
languages, the former is a mere procedural, the latter a mere
functional language.
C# Learner
> On Thu, 27 May 2004 04:36:24 +0100, C# Learner <csh...@learner.here>
> wrote:
[...]
> Forgive me if I'm wrong, but my impression is that you don't have a
> deep enough understanding of the C language, and indeed of programming
> languages in general, to appreciate the reasons for the syntax
> features you're commenting on.
I believe that I appreciate the reasons for these features. What I'm
saying is that I think that there are better (in terms of allowing the
user of the language to write readable code) alternatives that could
have been implemented instead.
> Take your original example of
> eliminating the deli meters around the conditional in an if statement.
> Think about what this would mean for compound conditions. Combine that
> with the Python-style blocking and then think about an if statement
> which tests for several conditions, requiring more than one line to
> write.
a) Valid C syntax:
if (foo &&
bar) {
foobar();
}
b) Similar code to the above but using my suggested syntax changes:
if foo &&
bar:
foobar();
Why wouldn't (b) be feasible here?
Everything from 'if' to ':' is considered the condition. After the
newline after ':', whitespace is required to form a code block.
> As you study and understand the language, you'll find that it's all
> nicely consistent, and that there are good reasons for most of the
> features which seem odd to you.
The only way in which they seem odd to me is that they make code much
less readable than it could be, in my opinion.
Okay, if you don't agree with the 'if'..':' idea, then how about
changing the parentheses required for test conditions for a different
pair of characters? An ideal pair would be a pair that isn't used
elsewhere in the language, for readability's sake.
> One of the characteristics of C is
> terseness, and extra parens aren't required by the language for no
> reason.
My point is that a different construct could be substituted in each case.
> Also, think about the fact that language inventors and implementers
> are, by and large, a pretty bright bunch. In general, they probably
> have more and wider experience in the field than you do, and some of
> them might even be as smart ;-)
So those who invented C's syntax are necessarily brighter than those who
invented, say, Python's syntax?
> Those features which have passed
> through to modern languages have done so for a reason.
I honestly wonder what that reason is.
Regards
C# Learner
> On Thu, 27 May 2004 00:56:59 +0100, in comp.lang.c , C# Learner
> <csh...@learner.here> wrote:
>
>
>>One of the biggest flaws in C syntax, in my opinion, is the required
>>parentheses for test conditions.
>>
>
>
>> if (FooBar(Parse(Process(GetInput())))
>> DoSomething();
>
>
> (he prefers)
>
>
>> if FooBar(Parse(Process(GetInput())):
>> DoSomething();
>
> Okay, I'll bite. Why on earth do you consider this in any way an
> improvement? What difference does it make to anything?
I believe that it'd improve code readability. Have you noticed how, in
langauges which use such syntax, people often write something like:
if ( FooBar(Parse(Process(GetInput())) )
i.e. they use spaces because of the fact that parentheses are used both
in test conditions and function calls. As far as I see, when doing so,
they're just attempting to work around a syntactical design flaw of the
language.
C# Learner
Point taken. :-)
Still, though, if others don't do this, then, when reading others' code,
the problem (as I see it) is still there.
C# Learner
[...]
>>I'd say Delphi has the clearest syntax.
>
> Delphi is boring. IMO syntax of C is much more funny.
<my opinion>
Delphi code is, in general, much more readable than C code. Therefore,
Delphi coders have an easier life than C coders.
</my opinion>
[...]
Alan Balmer
wrote:
>
>My point is that a different construct could be substituted in each case.
Making the syntax more complex, for no particular benefit that I can
see.
Parentheses, brackets and braces represent the general concept of
grouping. Even when seen in an unfamiliar context, one can get the
idea. I see no need to invent a different grouping symbology for each
use.
Everyone understands the symmetry between '(' and ')'. The symmetry
between 'if' and ':' is not nearly as intuitive. And now you propose
that each case that requires a grouping operator have a different
construct?
Of course, you say "could be substituted", which is obviously true. It
would certainly add a new dimension to the obfuscated C contests.
Mark McIntyre
<csh...@learner.here> wrote:
>Mark McIntyre wrote:
>>
>> Okay, I'll bite. Why on earth do you consider this in any way an
>> improvement? What difference does it make to anything?
>
>I believe that it'd improve code readability.
I disagree. The delimiter helps mark the ends of the various parts of the
statement. With only whitespace to work with, compound statements become
almost impossible to correctly read.
>Have you noticed how, in
>langauges which use such syntax,
....
>they use spaces because of the fact that parentheses are used both
>in test conditions and function calls. As far as I see, when doing so,
>they're just attempting to work around a syntactical design flaw of the
>language.
Gonads. This is nothing more than a style thing. French people put two
spaces after a full stop. English people don't. Same idea.
E. Robert Tisdale
> Why is C syntax so uneasy on the eye?
>
> In its day, was it _really_ designed by snobby programmers to scare away
> potential "n00bs"? If so, and after 50+ years of programming research,
> why are programming languages still being designed with C's syntax?
>
> These questions drive me insane. Every waking minute...
This is an obvious troll. Please Ignore it.
Keith Thompson
Yes, that's very clever. Please don't do it in any code that I might
ever have to maintain, or read -- or that anyone else might ever have
to maintain or read.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Keith Thompson
[...]
> C has plenty of ambiguity:
>
> - Braces are optional if there is only one statement for if() or for() or
> while(). (But not for do ... while(), switch, or structure/union
> declarations.)
That's not an ambiguity, it just means there's more than one way to
write a given program. The fact that braces are optional in many
contexts does not imply that there is any C program that can be
interpreted in any of two or more ways; the interpretation is
unambiguous in each case.
Keith Thompson
> Kieran Simkin wrote:
[...]
> > Obviously this entire post is off-topic. Python is not C, C will never be
> > Python and you've cross-posted to C# which is not C either.
>
> Hmm... I have to disagree. I feel that this discussion is about C's
> basic syntax and its ubiquity in popular modern-day languages.
>
> don't know quite where it would be /on/-topic. In fact, I even
> considered renaming the subject of this post to 'Re: C Syntax', but
> didn't want to enrage people by doing so.
Discussion of how other languages have influenced C would be topical
in comp.lang.c. Discussion of how C has influenced a hypothetical
language Foo would be topical (I presume) in comp.lang.foo. But if
you want to discuss how C has influenced other languages in general,
that's probably a good topic for comp.lang.misc.
Old Wolf
>
> None of the programming languages assigning semantics to indentation
> has ever become mainstream. There must be a reason...
The language of makefiles?
(Before you say "it isn't a language", it seems to be as much
a language as Prolog is)
Joona I Palaste
> On Thu, 27 May 2004 21:11:28 +0100, in comp.lang.c , C# Learner
> <csh...@learner.here> wrote:
>>Mark McIntyre wrote:
>>> Okay, I'll bite. Why on earth do you consider this in any way an
>>> improvement? What difference does it make to anything?
>>
>>I believe that it'd improve code readability.
> I disagree. The delimiter helps mark the ends of the various parts of the
> statement. With only whitespace to work with, compound statements become
> almost impossible to correctly read.
>>Have you noticed how, in
>>langauges which use such syntax,
> ....
>>they use spaces because of the fact that parentheses are used both
>>in test conditions and function calls. As far as I see, when doing so,
>>they're just attempting to work around a syntactical design flaw of the
>>language.
> Gonads. This is nothing more than a style thing. French people put two
> spaces after a full stop. English people don't. Same idea.
I've seen plenty of English-speakers (at least USAns) write two spaces
atfer a full stop. Now the French, they put a space before an
exclamation or question mark. Like this: "Regardez moi ! Je suis
français !". What's with that, then?
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Hasta la Vista, Abie!"
- Bart Simpson
Keith Thompson
I'm beginning to think your argument boils down to
I like Python.
I don't like C.
If you'd stated it that way, I'm sure everyone here would be in
complete agreement with you. We all agree that you like Python, and
we all agree that you don't like C.
Yes, I'm oversimplifying your argument and having a little fun at your
expense.
I think there's a valid point in here somewhere. Perhaps what you're
really looking for is a language with something like C's relatively
low-level semantics, but with Python's <OPINION>superior</OPINION>
syntax. I'm not aware that any such language exists. If it did, I
might prefer it to C myself. But of course it would be off-topic
here.
Another valid question is why C's <OPINION>ugly</OPINION> syntax has
had such an effect on later languages. As I mentioned elsethread,
that's probably a good topic for comp.lang.misc; you might check the
Google archives of that newsgroup.
Significant changes to C's syntax are not possible due to the need to
accomodate existing code. And such changes would be considered
undesirable by most C programmers, who either have gotten used to C's
quirks or actually like them. There are certainly some things I would
do differently if I were designing C from scratch today, but that's
probably very different from the set of changes someone else would
want to make.
Keith Thompson
[...]
> a) Valid C syntax:
>
> if (foo &&
> bar) {
> foobar();
> }
>
> b) Similar code to the above but using my suggested syntax changes:
>
> if foo &&
> bar:
> foobar();
>
> Why wouldn't (b) be feasible here?
I don't believe that Python has the ?: operator. C does. I don't
know whether it would cause any genuine ambiguities for the proposed
"if ... :" syntax, but it could certainly cause confusion.
If I were going to propose such a change (I'm not), I might suggest
dropping the parentheses and making the braces around the controlled
statement mandatory. For example:
if foo &&
bar
{
foobar();
}
I think similar changes could consistently be made for other compound
statements.
Of course, it's never going to happen.
C# Learner
> [...] There are certainly some things I would
> do differently if I were designing C from scratch today, [...]
This is basically what I've had set in my mind while participating in
this thread.
I think I've finally found someone who's tuned into my wavelength,
perhaps; in any case, someone who truly understands my motive.
:-)
Justin Rogers
news:%23f322iH...@TK2MSFTNGP09.phx.gbl...
While Keith points out there are some things he would do differently, C#
is in essence the attempt at an entirely new language, and yet they kept all
of the older syntax. Anders was a Pascal guy, and yet he chose the
constructs he did in his custom tailored language why? Well, because he
thought they provided the most power for the language without denying users
access to some commonly used programming tools.
The first tool is debugging and error assessment. The strict language
guidelines
of C# make it very easy to discover the root of a lexical or parsing error. At
the same time they make it easy to point out and find common programming
mistakes.
Verbosity or the lack thereof as a tool:
Take language constructs like begin...end to designate blocks... They
are verbose, why not just type { and }, after all this is much shorter. Why do
I need to separate my code by all that whitespace:
if something:
foobar
When I could easily write it on one line without all of that crappy whitespace
if ( something ) { foobar; }
What about intellisense and other features users have grown to love? Are they
easier,
faster, more efficient when written against a C type language? Does the explict
bounding of statement/expression/block scopes help the underlying intellisense
processor
to more accurately understand what the user is doing? Does it remove levels of
ambiguity
that would otherwise exist? When does whitespace become important, when is it
not,
does tabs to spaces or spaces to tabs affect the compilation of your
application? What
happens to whitespace nested blocks when I use two spaces per indent, but
convert to
tabs that are 4 to 8 spaces per indent? Does my code resize properly or do all
of my 2/4/6
spaces get turned into a single tab. Does a tab count as a single indention
character or
multiple? For instance, does a single space or a single tab have the same
nesting depth?
There are so many more aspects to programming today than loading up your
favorite
text editor and hacking away in the most efficient form that you can manage.
Code generators,
intellisense, auto-complete, are all tools taking up precious processor time
trying to figure
out what you want to do, and I think the trade-off between some extra semantics
versus
confusing the hell out of the computer that is making my life a bit easier, is
something I'm quite
happy with.
--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers
Michael Voss
Irrwahn Grausewitz wrote:
> "Michael Voss" <michae...@lvrREMOVE.deCAPS> wrote:
> >
> >Irrwahn Grausewitz wrote:
> >[...snip...]
> >> Smalltalk is a functional language.
> >
> >How do you define "functional language" ?
>
> I don't - others already did. If you're interested in this subject
> I suggest to Go Ogle for the comp.lang.functional FAQ - it contains
> a nice explanation of functional vs. procedural programming paradigms.
<COMPLETELY OFF TOPIC EXCEPT FOR C.L.F>
My Google search revealed nothing except that other people are searching the
c.l.f FAQ, too. Any hint where I could find them ?
</COMPLETELY OFF TOPIC EXCEPT FOR C.L.F>
> Ob the portion you snipped: While both C++ and Smalltalk are OO
> languages, the former is a mere procedural, the latter a mere
> functional language.
If a functional language is defined as:
--"The idea of functional languages is that functions are
--completely determined by their parameters. If you put
--the same parameters to a function, then you must get the
--same return values. So a function which does not take any
--parameters should always return the same result."
(Christian Szegedy (sze...@nospam.or.uni-bonn.de) in comp.lang.functional
at 2004-03-19 07:19:21 PST),
In my eyes and regarding the above definition, Smalltalk is not a functional
language.
Since I crossposted this to comp.lang.smalltalk and comp.lang.functional:
What do you think ? Is Smalltalk an object-oriented "mere functional"
language ?
Since this is completely off-topic for c.l.c and m.p.d.l.c, and my
newsreader does not support a proper followup-to (blush): Please followup to
comp.lang.smalltalk and comp.lang.functional. Please remove the C /
C#-groups.
Thanks,
Michael
Richard Bos
> a) Valid C syntax:
>
> if (foo &&
> bar) {
> foobar();
> }
>
> b) Similar code to the above but using my suggested syntax changes:
>
> if foo &&
> bar:
> foobar();
>
> Why wouldn't (b) be feasible here?
Because it is _not C_. If you want to design your own language, fair
enough. Hundreds if not thousands of people have done so before. Hey,
why don't you try to get M$ to change their Stolen-Java-with-an-
inappropriate-name syntax to include your pet love? At least then you
wouldn't have to convince so many people to change code that's been
working correctly for years or even decades.
> > As you study and understand the language, you'll find that it's all
> > nicely consistent, and that there are good reasons for most of the
> > features which seem odd to you.
>
> The only way in which they seem odd to me is that they make code much
> less readable than it could be, in my opinion.
_Your_ opinion does not count for much (any more than mine) against an
existing language with probably tens (if we count all hobbyists,
hundreds) of thousands of users all over the world.
> Okay, if you don't agree with the 'if'..':' idea, then how about
> changing the parentheses required for test conditions for a different
> pair of characters?
No.
> An ideal pair would be a pair that isn't used
> elsewhere in the language, for readability's sake.
Name one.
> > Also, think about the fact that language inventors and implementers
> > are, by and large, a pretty bright bunch. In general, they probably
> > have more and wider experience in the field than you do, and some of
> > them might even be as smart ;-)
>
> So those who invented C's syntax are necessarily brighter than those who
> invented, say, Python's syntax?
Not necessarily, though I must say I find Python's forced indentation a
veritable pain in the butt, and it is one of the main reasons why I
don't use the language.
> > Those features which have passed
> > through to modern languages have done so for a reason.
>
> I honestly wonder what that reason is.
People found them useful. Better programmers than you found them useful.
Richard
Richard Bos
> Keith Thompson wrote:
>
> > [...] There are certainly some things I would
> > do differently if I were designing C from scratch today, [...]
>
> This is basically what I've had set in my mind while participating in
> this thread.
Then I suggest you bloody well _do_ so, instead of bothering the users
of two existing languages, only related to eachother in name, about it.
If your language really does turn out to be superior to the existing
candidates, I'm sure you'll have no problems getting people to program
in it.
Richard
The Real Andy
<lpit...@sympatico.ca> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>C# Learner wrote:
>| Why is C syntax so uneasy on the eye?
%<
I am a former embedded programmer. I started programming with
assembler. C was a godsend. If you think the C syntax is uneasy on the
eye, then try learning 10 different assembler languages and using them
on a day to day basis. Try then to go back a year to maintain the
flavour of assembler from that period.
C# Learner
> While Keith points out there are some things he would do differently, C#
> is in essence the attempt at an entirely new language, and yet they kept all
> of the older syntax. Anders was a Pascal guy, and yet he chose the
> constructs he did in his custom tailored language why?
Good question! :-)
> Well, because he
> thought they provided the most power for the language without denying users
> access to some commonly used programming tools.
I also wonder to what extent he was required to keep the language
looking like C++/Java, and therefore attractive to current C++/Java
programmers. This is pure speculation on my part, of course; but I see
signs of it in the language, with an example being the 'switch'
construct. The syntax of 'switch' constructs is very different to that
of other syntactical elements of C#, and it seems to stick out like a
sore thumb. It appears that it was copied straight from C (although
with a difference in that C#'s version doesn't allow implicit fall-through).
<snip>
Dmitry Zamotkin
> --completely determined by their parameters. If you put
> --the same parameters to a function, then you must get the
> --same return values.
>So a function which does not take any
> --parameters should always return the same result."
he-he.
C is not functional too.
Try rand() function.
--
Dmitry Zamotkin
Justin Rogers
to IL compiler written before C# made it's first test runs, so I can't see
Java being the *look*. Managed C++, while syntactically appearing to
be a hack, was powerful enough to handle the C++ style syntax.
The reason for the way the switch statement in C# is works is the manner
in which the underlying IL construct works. In IL a switch is nothing more
than a simple jump table. They don't provide fall through because that
would require automatic generation of goto statements within the case
statement body. In most cases fall-through in C led to unexpected results
as users failed to close the syntax when that is what they meant to do.
As for the strange look of a switch, it is a balance of verbosity and function.
You might say that each case statement could indeed be it's own block and
should use french braces the way the rest of the language does, but that
doesn't allow for any form of fall-through.
case 10 { block } case 20 { block }
Where do you fall through in the above block? How do you have the
equivalent limited fall through syntax that C# does allow?
case 10:
case 20:
break;
Note, you are also building from the concepts of a label, each case
statement is terminated by a colon, something you don't find anywhere
else in C#, yet it is there. Each case statement semantically becomes a
label of some sort, a jump table label if you will. No different from having
an OUTER: label within a loop so that you can break out of the internal
loop and continue processing the outer loop.
What I'd highly recommend is write a lexer/parser that targets C# and then
change the language the way you'd like to see it changed. See how hard/easy
it is to format the code in your new manner and see how scalable that is for
adding new features. Would, for instance, you changes to the language have
affected the almost transparent addition of generics? What about namespace
aliasing and anonymous delegates? The future of the language is just as
important
as it's past, and C# is quickly becoming a very unique and promising language in
many ways.
--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers
Irrwahn Grausewitz
><COMPLETELY OFF TOPIC EXCEPT FOR C.L.F>
>My Google search revealed nothing except that other people are searching the
>c.l.f FAQ, too. Any hint where I could find them ?
The first hit googling for "functional language faq"
(without the quotes) is:
http://www.cs.nott.ac.uk/~gmh//faq.html
See section 2.1
></COMPLETELY OFF TOPIC EXCEPT FOR C.L.F>
>Since this is completely off-topic for c.l.c and m.p.d.l.c, and my
>newsreader does not support a proper followup-to (blush): Please followup to
>comp.lang.smalltalk and comp.lang.functional. Please remove the C /
>C#-groups.
Done.
Mabden
news:c95osc$al4$2...@nntp1.jpl.nasa.gov...
This is an obvious troll-responder. Please ignore it. ;-)
C# Learner
<snip>
> Would, for instance, you changes to the language have
> affected the almost transparent addition of generics? What about namespace
> aliasing and anonymous delegates?
Well, I'm not really thinking /that/ much into it -- I'm just thinking
about very basic syntax.
In any case, I look forward to generics, which I feel will make for
slightly more readable code, and perhaps more efficient code.
Anonymous delegates look nice too -- I read an article awhile back about
the ability to use them in an elegant fashion to marshall calls from a
worker thread onto the UI thread.
> The future of the language is just as
> important
> as it's past, and C# is quickly becoming a very unique and promising language in
> many ways.
Yeah, definitely. These are exciting times for programmers.
Dan Pop
>Mark McIntyre <markmc...@spamcop.net> scribbled the following:
>
>> Gonads. This is nothing more than a style thing. French people put two
>> spaces after a full stop. English people don't. Same idea.
>
>I've seen plenty of English-speakers (at least USAns) write two spaces
>atfer a full stop.
It has nothing to do with the language. It's a common (albeit not
universal) typographic convention to leave more space after the
punctuation sign terminating a sentence then after punctuation signs
inside a sentence. Examine a few printed books carefully and you may
notice it (it's not twice as much, so it's not immediately obvious).
The only way to follow this convention in a plain text document is by
using two spaces instead of one. This is what I'm consistently doing,
no matter in which of the three languages I'm familiar with I'm writing.
>Now the French, they put a space before an
>exclamation or question mark. Like this: "Regardez moi ! Je suis
>français !". What's with that, then?
Yet another bogus generalisation coming from Joona. Quoting from a post
from a French mailing list:
ton enfant ? quel age?
:-)
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
Dan Pop
>Dan...@cern.ch (Dan Pop) wrote:
>>
>> None of the programming languages assigning semantics to indentation
>> has ever become mainstream. There must be a reason...
>
>The language of makefiles?
Indentation per se is meaningless there. It's just that the language
syntax requires a TAB character as the first character on a line in
certain contexts.
I. Appel
Well, yes. But Python or Visual Basic code is IMO even more readable.
I. Appel
> Therefore, it's based on an older language than C, maybe that's why
> it's a bit boring.
Pascal and C are of the same age almost. Pascal maybe 2-3 years older than
C, not more
> > Well, rephrasing Paul Graham, I should say "Don't wait until C will
become
> > as
> > clear as Python, use Python instead".
>
> If you really think Python has clearer syntax than C, well, think twice.
> One terrible fact is this indentation thing in Python to delimit code
> blocks. One tab or space is left behind, and the whole thing is screwed.
> To me, it's an unacceptable syntax issue.
Python programs are easier to read and understand, that's what I understand
as "clear". And I had never such problems as leaving behind tabs or spaces,
it's generally no problem with good text editor.
Joe Wright
> In <843a4f78.04052...@posting.google.com> old...@inspire.net.nz (Old Wolf) writes:
>
>
>>Dan...@cern.ch (Dan Pop) wrote:
>>
>>>None of the programming languages assigning semantics to indentation
>>>has ever become mainstream. There must be a reason...
>>
>>The language of makefiles?
>
>
> Indentation per se is meaningless there. It's just that the language
> syntax requires a TAB character as the first character on a line in
> certain contexts.
>
> Dan
Usually the Rule starts at the left margin and the Command is on the
next line indented with the TAB character. I always found this TAB a
nuisance because my editor puts spaces out when I press Tab key.
Imagine my joy upon reading that GNU make (if not others) also
allows separating Rule from Command with semicolon.
# Use GNU make to build an executable for testing GE.
cc=gcc
obj=ge.o main.o
exe=main.exe
opt=-W -Wall -ansi -pedantic -O2 -c
# Note that semicolon (not TAB) separates Rule from Command on a line.
$(exe) : $(obj) ; $(cc) -s $(obj) -o $(exe)
ge.o : ge.c ; $(cc) $(opt) ge.c
main.o : main.c ge.h ; $(cc) $(opt) main.c
--
Joe Wright mailto:joeww...@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Goran Larsson
Joe Wright <joeww...@comcast.net> wrote:
> Imagine my joy upon reading that GNU make (if not others) also
> allows separating Rule from Command with semicolon.
This is a standard make feature. In a way it is the fundamental
method to separate the dependency list from the commands. The
lines startong with TABs are just continuation lines for the commands.
--
Göran Larsson http://www.mitt-eget.com/
James Kanze
|> Alan Balmer wrote:
|> > On Thu, 27 May 2004 04:36:24 +0100, C# Learner <csh...@learner.here>
|> > wrote:
|> [...]
|> > Forgive me if I'm wrong, but my impression is that you don't have
|> > a deep enough understanding of the C language, and indeed of
|> > programming languages in general, to appreciate the reasons for
|> > the syntax features you're commenting on.
|> I believe that I appreciate the reasons for these features. What I'm
|> saying is that I think that there are better (in terms of allowing
|> the user of the language to write readable code) alternatives that
|> could have been implemented instead.
|> > Take your original example of eliminating the deli meters around
|> > the conditional in an if statement. Think about what this would
|> > mean for compound conditions. Combine that with the Python-style
|> > blocking and then think about an if statement which tests for
|> > several conditions, requiring more than one line to write.
|> a) Valid C syntax:
|> if (foo &&
|> bar) {
|> foobar();
|> }
|> b) Similar code to the above but using my suggested syntax changes:
|> if foo &&
|> bar:
|> foobar();
|> Why wouldn't (b) be feasible here?
|> Everything from 'if' to ':' is considered the condition.
Even if there is a ?: operator in the conditional expression?
|> After the newline after ':', whitespace is required to form a code
|> block.
Let's see, you want to overload on whitespace?
|> > As you study and understand the language, you'll find that it's
|> > all nicely consistent, and that there are good reasons for most of
|> > the features which seem odd to you.
|> The only way in which they seem odd to me is that they make code
|> much less readable than it could be, in my opinion.
Things like C's declaration syntax make code less readable. But you
didn't mention that. The preprocessor can be really effective in making
code less readable too, but you didn't mention that either. And of
course, all those funny characters really made code less readable back
in the days when I had to work with an ISO 646 terminal -- in the German
variant.
But you seem to be attacking areas where C basically has no serious
problems. I personally prefer something like:
if expr then
stmt_list
else
stmt_list
endif
but the alternative used by C is pretty acceptable too. (And my
preference may have been conditioned by the ISO 646 terminals above.
Things like:
if ( expr ) ä
stmt_list
ü else ä
stmt_list
ü
are not particularly readable.)
|> Okay, if you don't agree with the 'if'..':' idea, then how about
|> changing the parentheses required for test conditions for a
|> different pair of characters? An ideal pair would be a pair that
|> isn't used elsewhere in the language, for readability's sake.
|> > One of the characteristics of C is terseness, and extra parens
|> > aren't required by the language for no reason.
|> My point is that a different construct could be substituted in each
|> case.
|> > Also, think about the fact that language inventors and
|> > implementers are, by and large, a pretty bright bunch. In general,
|> > they probably have more and wider experience in the field than you
|> > do, and some of them might even be as smart ;-)
Let's not get carried away. Language designers don't work in a vacuum,
and C is like it is for a variety of historical reasons.
|> So those who invented C's syntax are necessarily brighter than those
|> who invented, say, Python's syntax?
They were certainly working in a different context. I don't know
Python, so I can't say, but from the little you've shown, my impression
is that it is something that works well for quick hacks, but doesn't
scale well.
|> > Those features which have passed through to modern languages have
|> > done so for a reason.
|> I honestly wonder what that reason is.
They work.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
James Kanze
|> In <c96ht9$4ej$2...@oravannahka.helsinki.fi> Joona I Palaste
|> <pal...@cc.helsinki.fi> writes:
|> >Mark McIntyre <markmc...@spamcop.net> scribbled the following:
|> >> Gonads. This is nothing more than a style thing. French people
|> >> put two spaces after a full stop. English people don't. Same
|> >> idea.
|> >I've seen plenty of English-speakers (at least USAns) write two
|> >spaces atfer a full stop.
|> It has nothing to do with the language. It's a common (albeit not
|> universal) typographic convention to leave more space after the
|> punctuation sign terminating a sentence then after punctuation signs
|> inside a sentence.
It is a common (albeit not universal) typographical convention in the
anglosaxon world. Look at a book printed in France or Germany.
Correctly typeset French uses three different spaces :
une espace fine insécable : about a fourth of a quad, no line break
allowed.
une espace mots insécable : about a third of a quad, no line break
allowed.
une espace justifiante : nominally about a third of a quad, but can be
stretched or shrunk, allows a line break.
Nothing larger for the end of a sentence.
|> Examine a few printed books carefully and you may notice it (it's
|> not twice as much, so it's not immediately obvious).
|> The only way to follow this convention in a plain text document is
|> by using two spaces instead of one. This is what I'm consistently
|> doing, no matter in which of the three languages I'm familiar with
|> I'm writing.
Then you're probably doing it wrong in two of them. Different
linguistic communities have different conventions. A larger space after
a sentence is definitly wrong in French or German, and I think it is
wrong in Italian. On the other hand, it would generally be considered
poor typesetting in English not to use it, although how much extra space
is debattable, and if the difference is small enough, the average reader
might miss it.
|> >Now the French, they put a space before an exclamation or question
|> >mark. Like this: "Regardez moi ! Je suis français !". What's
|> >with that, then?
|> Yet another bogus generalisation coming from Joona. Quoting from a
|> post from a French mailing list:
|> ton enfant ? quel age?
|> :-)
Doubtlessly a typo. Or simply incorrect use.
On the other hand, correct typographical use here is an espace fine
insécable, not a full space. Personally, I find the difference
between an espace fine and an espace mots pretty small, and when using a
fixed width font, use a normal espace for both. I know people, however,
who insist on the difference, and drop the espace fine, rather than use
a full space. (They're the exceptions, I think, but I've not done a
statistical analysis to prove it.)
In C, I've noticed that it is immediately obvious when a French speaker
has written the code, even if the comments are in English -- there's a
space in front of the : and the ;, which is never present in code
written by anyone else.
Mark McIntyre
<ka...@gabi-soft.fr> wrote:
>Dan...@cern.ch (Dan Pop) writes:
>
>|> In <c96ht9$4ej$2...@oravannahka.helsinki.fi> Joona I Palaste
>|> <pal...@cc.helsinki.fi> writes:
>
>|> >Now the French, they put a space before an exclamation or question
>|> >mark. Like this: "Regardez moi ! Je suis français !". What's
>|> >with that, then?
>
>|> Yet another bogus generalisation coming from Joona. Quoting from a
>|> post from a French mailing list:
>
>|> ton enfant ? quel age?
>
>Doubtlessly a typo. Or simply incorrect use.
The second is a typo. I work for a french bank, and the vast majority of
french expats use spaces before and after emphatic punctuation. Only the
anglicised french omit the space.
Remind me what this has to do with C....
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Viktor Lofgren
> Alex Moskalyuk wrote:
>
>> Have you ever looked into Perl or Lisp code?
>>
>> C suddenly starts making perfect sense.
>>
>> What's uneasy to you? Curly braces, parentheses, keywords, or something
>> else?
>
> One of the biggest flaws in C syntax, in my opinion, is the required
> parentheses for test conditions.
>
>
> void Foo
> {
> if (FooBar(Parse(Process(GetInput())))
> DoSomething();
> }
That is _very_ bad code. What if Parse, Process or GetInput fails,
how would you know what hit you?
Instead,
void Foo(void)
{
type_t a;
if(!(a=get_input()))
puts("GetInput died");
if(!(a=process(a)))
puts("process died");
if(!(a=parse(parse())
puts("Parse died");
if(foobar(a)
do_something();
}
>
> Imagine if, instead, we could write the following:
>
> void Foo
> {
> if FooBar(Parse(Process(GetInput())):
> DoSomething();
> }
This is why: it would not be consistant with the C code-style. The
style is in fact is very obvious when properly idented and highligthed,
> Another nicety about Python is the fact that whitespace is used for
> defining code blocks. This makes code much clearer than the equivalent
> C code, which requires block being/end markers.
I don't like the idea of having indentation as a part of the syntax,
very hard to write longer code on 80x25 terminals :-(
> Even if one's accustomed to C syntax, the former is still clearer and
> easier-to-read, don't you think?
Programming languages are not meant to be easy to read.
If you want easy-to-read, comment your code.
> Why C? Why?!
Here's why: It works and is perfectly balanced between levels. It is not
gibberish like LISP or Assembly (no offense, but it is kinda hard to see what
(+ 2 (* 8 (expt 25 (/ 5 2)))) does). And you still consistent (unlike BASIC)
and doesent require you to write a smaller novel (unlike COBOL) to get your
app to do something. Python may be an OK language, but it still doesent
have the maturity of C.
--
Viktor Lofgren, Umea, Sweden
Mainly self-eductated UNIX programmer, running Slackware-current.
CBFalconer
That is still foul and faulty code. Assuming there is an error
value 0, try:
void Foo(void)
{
type_t a;
if (!(a = get_input())) puts("GetInput died");
else if (!(a = process(a))) puts("process died");
else if (!(a = parse(a()) puts("Parse died");
else if (foobar(a) do_something();
/* else donothing */
}
If there is no such error value, the original is much clearer.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Dr Chaos
> Why is C syntax so uneasy on the eye?
>
> In its day, was it _really_ designed by snobby programmers to scare away
> potential "n00bs"?
No, but the programmers who designed it didn't care about "n00bs";
their target audience was people who worked at Bell Labs. They were
all very very smart. And it was in the days where actually printing
programs and typing them in was physically expensive and difficult
(literal paper-oriented terminals and tty inputs). So severely
limiting characters was a desirable major goal then. It isn't now.
> If so, and after 50+ years of programming research,
> why are programming languages still being designed with C's syntax?
Profound anti-intellectualism among practitioners, and cargo-cult
imitation. This spurious idea being that "gee, C was popular; so why
don't we make our language with Cish syntax so we might be popular
too."
Yes, these things have been tested empirically (though that field
is woefully underfunded) and yes the answer comes back that other
syntaxes are less error prone.
In particular the Fortran 90 and Ada typical syntaxes come out on
top.
> These questions drive me insane. Every waking minute...
The answers are easy. But depressing.
August Derleth
> he-he.
> C is not functional too.
> Try rand() function.
rand() works right. You are broken.
--
yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
To email me, rot13 and convert spelled-out numbers to numeric form.
"Makes hackers smile" makes hackers smile.
red floyd
> None of the programming languages assigning semantics to indentation
> has ever become mainstream. There must be a reason...
Not true. You're living in the present. In the past, when punch card
input was the norm, indentation had a meaning. In particular, FORTRAN
IV required input to begin in column 7 (or was it 8?), with a '*' in
column 6(7) as continuation...
DISCLAIMER: It's been nigh onto 25 years since I've done FORTRAN IV.
My info on the specific columns may be incorrect.
C# Learner
the "Followup-To" header in your message) unless I also posted to
microsoft.public.dotnet.languages.csharp. I'm not certain why. In any
case, I've restored that "Followup-To" header.]
Dr Chaos wrote:
<snipped some interesting stuff>
>>These questions drive me insane. Every waking minute...
>
> The answers are easy. But depressing.
I'm glad you understand. :-)
I. Appel
news:pan.2004.05.30....@sig.now...
> > he-he.
> > C is not functional too.
> > Try rand() function.
>
> rand() works right. You are broken.
>
Actually, rand() has some side-effects - changing the seeds of pseudo-random
generator.
So, such function is not pure-fuctional-programming-language-function.
I. Appel
news:pan.2004.05.30....@sig.now...
> > C is not functional too.
> > Try rand() function.
>
> rand() works right. You are broken.
>
Actually, rand() has some side-effects - changing the seeds of pseudo-random
I. Appel
news:tk2uc.702$dx3....@newsb.telia.net...
>
> Here's why: It works and is perfectly balanced between levels. It is not
> gibberish like LISP or Assembly (no offense, but it is kinda hard to see
what
> (+ 2 (* 8 (expt 25 (/ 5 2)))) does).
To start understand such stuff you need to write code in LISP for a few
days, not more. After that it may become even _simpler_ to understand,
because it's not required to memorize order of precedence.
ozbear
Column 6 was for the continuation. Your code had to fit in columns
7 through 72. 73 through 80 was for a card sequence number, and
ignored by the compiler, IIRC.
Cobol also (originally) used column-positional syntax, Area A,
Area B, and so on.
Columns 1 through 6 (or 7) was for sequence numbers, followed by
Area A for paragraph names, and Area B for code, but its been a long
time.
At any rate, Dan is incorrect.
Oz
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
James Kanze
|> >|> Yet another bogus generalisation coming from Joona. Quoting
|> >|> from a post from a French mailing list:
|> >|> ton enfant ? quel age?
|> >Doubtlessly a typo. Or simply incorrect use.
|> The second is a typo. I work for a french bank, and the vast
|> majority of french expats use spaces before and after emphatic
|> punctuation. Only the anglicised french omit the space.
|> Remind me what this has to do with C....
The French also put spaces before the semicolons in C programs:-).
Guillaume
> french expats use spaces before and after emphatic punctuation. Only the
> anglicised french omit the space.
Well, in fact, both are wrong and right at the same time.
Typographically speaking, the kind of spacing that should be used just
before a punctuation mark such as a question mark or an exclamation mark
is NOT the same as the spacing used between two words, for instance.
It should be a "quart de cadratin", which is much less wide.
Unfortunately, plain ASCII text doesn't have much notion of typographic
spacing. It only knows of a basic space, which is as wide as can be.
Thus, I consider putting extra spaces before punctuation marks
a typo when using plain ASCII text, and more esthetically pleasing
to the eye to omit them. French or not.
I especially hate those who put a space before a period. Like this:
"This is fucked up ."
It's just confusing, ugly, and makes no typographic sense.
Richard Bos
[ Please do not snip attribution lines of people whose text you leave in
your replies. I have no idea who wrote the following: ]
> > > Well, rephrasing Paul Graham, I should say "Don't wait until C will
> > > become as clear as Python, use Python instead".
> >
> > If you really think Python has clearer syntax than C, well, think twice.
>
> Python programs are easier to read and understand, that's what I understand
> as "clear".
Pardon me: _you_ consider Python programs to be easier to read and
understand. Other people, amongst whom the twice-quoted contributer
above and myself, disagree.
Richard
Dan Pop
>On 29 May 2004 19:35:09 -0700, redfl...@yahoo.com (red floyd) wrote:
>
>>Dan...@cern.ch (Dan Pop) wrote in message news:<c956k1$p2m$4...@sunnews.cern.ch>...
>>> In <bu1cb0ltl9jqhs7pg...@4ax.com> Alan Balmer <alba...@att.net> writes:
>>
>>> None of the programming languages assigning semantics to indentation
>>> has ever become mainstream. There must be a reason...
>>
>>Not true. You're living in the present. In the past, when punch card
>>input was the norm, indentation had a meaning. In particular, FORTRAN
>>IV required input to begin in column 7 (or was it 8?), with a '*' in
>>column 6(7) as continuation...
>>
>>DISCLAIMER: It's been nigh onto 25 years since I've done FORTRAN IV.
>>My info on the specific columns may be incorrect.
>
>Column 6 was for the continuation. Your code had to fit in columns
>7 through 72. 73 through 80 was for a card sequence number, and
>ignored by the compiler, IIRC.
>
>Cobol also (originally) used column-positional syntax, Area A,
>Area B, and so on.
>
>Columns 1 through 6 (or 7) was for sequence numbers, followed by
>Area A for paragraph names, and Area B for code, but its been a long
>time.
>
>At any rate, Dan is incorrect.
Why? None of these examples count as indentation being semantically
significant. You're merely confusing the fixed format of certain
languages and indentation.
FYI: I've used both fixed format Fortran and fixed format assemblers,
but fixed format has nothing to do with *indentation* being semantically
significant.
Dave Vandervies
Paul Hsieh <q...@pobox.com> wrote:
>"Justin Rogers" <Jus...@games4dotnet.com> wrote:
>> Note that they point out you can leave out parens only when it won't lead to
>> ambiguity. C doesn't make that mistake. They make sure there is no
>> ambiguity, and if you leave out a parens it doesn't make the statement
>> ambiguous, it makes it a different or erroneous statement altogether.
>
>C has plenty of ambiguity:
I see no ambiguity here. Things that may not match what you want, yes.
If you hate C so much, why do you still use it?
>- Braces are optional if there is only one statement for if() or for() or
> while(). (But not for do ... while(), switch, or structure/union
> declarations.)
There is always precisely one statement controlled by if, for, while, or
do..while (and even switch, though it's rather useless there). That one
statement may be a simple expression statement or a compound statement;
compound statements (by definition) begin with a '{' and end with a '}'.
struct and union declarations don't involve any statements, so your
claim is meaningless when applied to that.
>- If a statement has multiple side effects, the order in which those side
> effects take place can be unknown.
If a statement has multiple side effects whose order is relevant,
it shouldn't've been written as a single statement in the first place.
If the only purpose of defining something is so that you can look at the
language definition to find out what bad code is really doing, it's not
worth defining.
>- The right shift operator may or may not sign extend signed integers. Its
> implementation defined.
Is there any reason why it should be defined in some particular way?
If you want sign extension of signed integers, use the division operator;
any self-respecting compiler will use a shift instruction for that where
it's appropriate. If you want to move the bits around without worrying
about sign bits, use unsigned integers and avoid the sign bit entirely.
>- The size of an integer is platforms specific.
So? Do you care if the machine gives you 16 more bits than you need?
>- The number of bits in a bytes is platform specific.
So? Do you care if the system gives you 2 more bits than you need?
>- Try this one on for size:
>
> char a = -1, b = -2;
> unsigned short x = (1 > 0) ? a : b;
>
> printf ("x = %d\n", x);
>
> What do you think is printed out? Explain it.
A number that, if you think about it hard enough, will give you some clue
about whether char is signed and possibly about how signed integers are
represented internally.
You're lying to printf; what did you expect, a compiler error saying
"That's not what you meant"?
dave
--
Dave Vandervies dj3v...@csclub.uwaterloo.ca
Conclusion: You are not only a masochist, but a stubborn masochist.
--Eric Sosman in comp.lang.c
Slartibartfast
>
> None of the programming languages assigning semantics to indentation
> has ever become mainstream. There must be a reason...
>
TTCN. It's mainstream if you work in telecoms, but, as your comment
implies, it's unpleasant in the extreme.
Guillaume
> C, not more
Well, technically, you're right. Pascal was officially unveiled at about
the same time as C appeared, but the whole history behind Pascal (and
Ada) is a lot older.
To me, Pascal remains the language of choice to teach a structured,
procedural language. C was originally made to be used by experienced
programmers, and (even if that will raise some eyebrows here and there)
I think this still applies nowadays.
> Python programs are easier to read and understand, that's what I understand
> as "clear". And I had never such problems as leaving behind tabs or spaces,
> it's generally no problem with good text editor.
That's a matter of taste, I guess. Many of us seem to disagree, though.
As for the indentation-oriented syntax, I strongly advise against it.
To me, it's very unnatural. In the huge majority of languages (natural
or programming ones), spaces are meant to be separators and esthetic
elements. Even if indenting has become natural for most programmers
when writing different code blocks in most languages (C, Pascal, Ada...)
I still think it's a visual improvement for readability - and shouldn't
be anything else. I really can't figure out the whole rationale behind
the Python syntax. And even if you claim that "such problems as leaving
behind tabs or spaces, it's generally no problem", it's not quite what
I have in mind in terms of "syntactic robustness".
Alan Balmer
Fortran IV had a fixed format for cards, but indentation was not
meaningful. The code area started in column 7, but you could use
whitespace any way you liked within that constraint. It did not assign
any semantics to indentation, as Python does.
BTW, your attributions are messed up - I didn't write anything you
quoted.
--
Al Balmer
Balmer Consulting
removebalmerc...@att.net
James Kanze
|> > The second is a typo. I work for a french bank, and the vast
|> > majority of french expats use spaces before and after emphatic
|> > punctuation. Only the anglicised french omit the space.
|> Well, in fact, both are wrong and right at the same time.
|> Typographically speaking, the kind of spacing that should be used
|> just before a punctuation mark such as a question mark or an
|> exclamation mark is NOT the same as the spacing used between two
|> words, for instance. It should be a "quart de cadratin", which is
|> much less wide.
Not much less. A "cadratin" is a quad in English -- originally, a
square piece of lead, whose width is the same as its height. The space
before "high" punctuation is an "espace fine", nominally a fourth of a
quad. The nominal width of a space between words is a third of a quad.
For twelve point type, we're talking about 3pt vs. 4pt. And the 4pt
interword space can be stretched OR SHRUNK somewhat to make the line
fit; on a tightly spaced line, it takes a good eye to see the difference
between an espace mot and an espace fine.
|> Unfortunately, plain ASCII text doesn't have much notion of
|> typographic spacing. It only knows of a basic space, which is as
|> wide as can be.
Agreed. It's even wider than a normal word space.
|> Thus, I consider putting extra spaces before punctuation marks a
|> typo when using plain ASCII text, and more esthetically pleasing to
|> the eye to omit them. French or not.
As someone used to reading French, I find it jarring if there isn't some
space. And the space I expect isn't that far from the normal word space
that it bothers me.
Of course, when I"m typing or reading English or German, I use different
rules.
|> I especially hate those who put a space before a period. Like this:
|> "This is fucked up ."
Quite. At least in the typographical conventions I'm familiar with:
French, German and English. Given the variety, I wouldn't really
surprise me if this were the norm for some language, however.
Keith Thompson
> > Pascal and C are of the same age almost. Pascal maybe 2-3 years older than
> > C, not more
>
> Well, technically, you're right. Pascal was officially unveiled at about
> the same time as C appeared, but the whole history behind Pascal (and
> Ada) is a lot older.
C grew out of the same history as Pascal; they're both descendents of
Algol, though C is less of a direct descendent. C's declaration
syntax, at least in its simple forms, is more Algol-like than Pascal's
is:
Algol: integer i;
C: int i;
Pascal: i: integer;
> As for the indentation-oriented syntax, I strongly advise against it.
> To me, it's very unnatural. In the huge majority of languages (natural
> or programming ones), spaces are meant to be separators and esthetic
> elements. Even if indenting has become natural for most programmers
> when writing different code blocks in most languages (C, Pascal, Ada...)
> I still think it's a visual improvement for readability - and shouldn't
> be anything else. I really can't figure out the whole rationale behind
> the Python syntax. And even if you claim that "such problems as leaving
> behind tabs or spaces, it's generally no problem", it's not quite what
> I have in mind in terms of "syntactic robustness".
(As long as we have an '[OT]' tag on this thread ...)
I haven't played with Python enough to form a strong opinion about its
indentation-oriented syntax, but I think I like it. When I program in
a language that expressions nesting with delimiters (begin/end, {/},
case/esac), I maintain strictly consistent indentation anyway. I go
to the effort of indenting my code properly, and the compiler doesn't
even warn me if I get it wrong. Python lets me omit the delimiters;
the indentation is exactly what it would have been if Python required
delimiters as well.
C's use of delimiters to denote nesting allows some flexibility that
Python doesn't, but I see no virtue in that flexibility. C allows
incorrect, or even misleading, indentation:
if (cond1)
if (cond2)
some_statement;
else
some_other_statement;
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
I. Appel
foo = lambda x, y: [str (i+j) for (i,j) in zip(x,y)]
Well, it's not very clear, but how many lines of code in C
would be required to reproduce it? Types of x and y can be
either lists of lists, lists of strings, lists of numbers
or strings. And it maybe used for all that stuff.
I don't understand, how several dozens lines of code can be
better than ONE line of code in non-esoteric language.
Read "Succinctness is Power" and "Revenge of the Nerds" by Paul
Graham, if you want more.
Ivan.
"Richard Bos" <r...@hoekstra-uitgeverij.nl> wrote in message
news:40bc41fc....@news.individual.net...
I. Appel
news:40bcaece$0$309$7a62...@news.club-internet.fr...
> > Pascal and C are of the same age almost. Pascal maybe 2-3 years older
than
> > C, not more
>
> Well, technically, you're right. Pascal was officially unveiled at about
> the same time as C appeared, but the whole history behind Pascal (and
> Ada) is a lot older.
The concepts behind them are almost the same. Maybe C is a bit more
influenced
by low-level programming and functional programming, but it's as structured
as Pascal.
> To me, Pascal remains the language of choice to teach a structured,
> procedural language. C was originally made to be used by experienced
> programmers, and (even if that will raise some eyebrows here and there)
> I think this still applies nowadays.
I can't disagree with you. When I studied programming at my university,
it was really hard for inexperienced people to code in C. I suppose, it
would be pretty simpler for them to learn Pascal first.
Some Python and Java zealots suppose their stuff to be the best learning
language instead of Pascal, but I'm not agree.
> > Python programs are easier to read and understand, that's what I
understand
> > as "clear". And I had never such problems as leaving behind tabs or
spaces,
> > it's generally no problem with good text editor.
>
> That's a matter of taste, I guess. Many of us seem to disagree, though.
I've seen code in C and Java written by several Python-haters. Most of them
don't use indents at all, so their code is pretty hard to read. See below.
> As for the indentation-oriented syntax, I strongly advise against it.
> To me, it's very unnatural. In the huge majority of languages (natural
> or programming ones), spaces are meant to be separators and esthetic
> elements. Even if indenting has become natural for most programmers
> when writing different code blocks in most languages (C, Pascal, Ada...)
> I still think it's a visual improvement for readability - and shouldn't
> be anything else. I really can't figure out the whole rationale behind
> the Python syntax. And even if you claim that "such problems as leaving
> behind tabs or spaces, it's generally no problem", it's not quite what
> I have in mind in terms of "syntactic robustness".
Well, main idea behind Python's syntax is "we use indentation anyway (most
of
us at least), so what's the reason to make syntax redundant and to use
_both_
indents and delimiters?"
Are you agree?
ozbear
Nope. "Fixed format" is just a ruse to cover up what is actually
fixed indentation. If those rules were violated you didn't even
get to what was semantically equivalent because you never got past
compilation.
If you put your Fortran continuation character in the wrong column
you could easily end up with errors.
The point is that those columns had meaning to the compiler hence one
had to indent, hence indentation had meaning.
Dik T. Winter
...
> C grew out of the same history as Pascal; they're both descendents of
> Algol, though C is less of a direct descendent.
Lessee. C if offspring from Jovial and the kind, which is offspring from
Algol 58. Pascal became because in the depelopment of Algol 68 Wirth did
not agree with the direction the committee was going.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Alan Balmer
<iap...@rol.kill.the.spammers.ru> wrote:
>Well, I had to place more IMO's, but check this:
>
>foo = lambda x, y: [str (i+j) for (i,j) in zip(x,y)]
>
>Well, it's not very clear, but how many lines of code in C
>would be required to reproduce it? Types of x and y can be
>either lists of lists, lists of strings, lists of numbers
>or strings. And it maybe used for all that stuff.
>
>I don't understand, how several dozens lines of code can be
>better than ONE line of code in non-esoteric language.
As you said, it's not very clear ;-) Actually, you'll have to define
"better" before you're qualified to offer an opinion.
Alan Balmer
<iap...@rol.kill.the.spammers.ru> wrote:
>
>I've seen code in C and Java written by several Python-haters. Most of them
>don't use indents at all, so their code is pretty hard to read. See below.
You need to expand your circle of acquaintances :-) Most C and Java
programmers (in fact, all) that I know use indents, whether or not
they hate Python.
>
>> As for the indentation-oriented syntax, I strongly advise against it.
>> To me, it's very unnatural. In the huge majority of languages (natural
>> or programming ones), spaces are meant to be separators and esthetic
>> elements. Even if indenting has become natural for most programmers
>> when writing different code blocks in most languages (C, Pascal, Ada...)
>> I still think it's a visual improvement for readability - and shouldn't
>> be anything else. I really can't figure out the whole rationale behind
>> the Python syntax. And even if you claim that "such problems as leaving
>> behind tabs or spaces, it's generally no problem", it's not quite what
>> I have in mind in terms of "syntactic robustness".
>
>Well, main idea behind Python's syntax is "we use indentation anyway (most
>of
>us at least), so what's the reason to make syntax redundant and to use
>_both_
>indents and delimiters?"
>
>Are you agree?
>
Nope.