D
Dmitry Zamotkin
--"The idea of functional languages is that functions are
he-he.
C is not functional too.
Try rand() function.
he-he.
C is not functional too.
Try rand() function.
J
Justin Rogers
I'll actually bite on the below since I have some input. There was a Java
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.
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.
I
Irrwahn Grausewitz
Michael Voss said:
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
Done.
Regards
M
Mabden
E. Robert Tisdale said:
This is an obvious troll-responder. Please ignore it. ;-)
C
C# Learner
Justin Rogers wrote:
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.
Yeah, definitely. These are exciting times for programmers.
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.
Yeah, definitely. These are exciting times for programmers.
D
Dan Pop
In said:
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.
Yet another bogus generalisation coming from Joona. Quoting from a post
from a French mailing list:
ton enfant ? quel age?
Dan
D
Dan Pop
In said:
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
I
I. Appel
Delphi is Pascal with maybe a few bells and whistles.
Pascal and C are of the same age almost. Pascal maybe 2-3 years older than
C, not more
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.
Pascal and C are of the same age almost. Pascal maybe 2-3 years older than
C, not more
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.
I
I. Appel
I'd say Delphi has the clearest syntax.
Well, yes. But Python or Visual Basic code is IMO even more readable.
Well, yes. But Python or Visual Basic code is IMO even more readable.
J
Joe Wright
Dan said:
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
G
Goran Larsson
Joe Wright said:
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.
J
James Kanze
|> Alan Balmer wrote:
|> > On Thu, 27 May 2004 04:36:24 +0100, C# Learner <[email protected]>
|> > 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.
|> > On Thu, 27 May 2004 04:36:24 +0100, C# Learner <[email protected]>
|> > 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.
J
James Kanze
(e-mail address removed) (Dan Pop) writes:
|> In <[email protected]> Joona I Palaste
|> >Mark McIntyre <[email protected]> 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.
|> In <[email protected]> Joona I Palaste
|> >Mark McIntyre <[email protected]> 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.
M
Mark McIntyre
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....
V
Viktor Lofgren
That is _very_ bad code. What if Parse, Process or GetInput fails,In comp.lang.c C# Learner said:
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();
}
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,
I don't like the idea of having indentation as a part of the syntax,
very hard to write longer code on 80x25 terminals :-(
Programming languages are not meant to be easy to read.
If you want easy-to-read, comment your code.
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.
C
CBFalconer
Viktor said:
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.
D
Dr Chaos
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.
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.
The answers are easy. But depressing.
A
August Derleth
rand() works right. You are broken.
R
red floyd
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
C# Learner
[Note: I was unable to post a message to comp.lang.c (as specified in
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:
I'm glad you understand.
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:
I'm glad you understand.