I
I. Appel
August Derleth said: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.
August Derleth said:rand() works right. You are broken.
August Derleth said:rand() works right. You are broken.
Viktor Lofgren said: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).
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.
french expats use spaces before and after emphatic punctuation. Only the
anglicised french omit the space.
Python programs are easier to read and understand, that's what I understand
as "clear".
Richard Bos said:[ Please do not snip attribution lines of people whose text you leave in
your replies. I have no idea who wrote the following: ]
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
In said: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.
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.
None of the programming languages assigning semantics to indentation
has ever become mainstream. There must be a reason...
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.
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.
Guillaume said: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.
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".
Guillaume said: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.
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".
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.
C grew out of the same history as Pascal; they're both descendents of
Algol, though C is less of a direct descendent.
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.
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.
Nope.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?
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.