On 15/04/2025 08:17, Janis Papanagnou wrote:
On 14.04.2025 17:22, bart wrote:
(It's nonsense to make up an "argument" for 'goto'.)
The fastest bytecode interpreters in C, at present rely on using 'computed goto' (although along with label pointers, an extension).
There are other uses too: C is popular as an intermediate language, and to that end, 'goto' is essential to express constructs the original language may have, but don't exist in C.
There are other applications, but I doubt that will cut any ice. Probably you personally haven't used 'goto' since 1986, and think no one else needs to use it either.
This is the kind of error I was making all the time (writing the first
line, copying it, but forgetting to convert all the variables):
>
for(i=0; i < M; ++i)
for(j=0; j < N; ++i)
That first of all means that you are obviously a sloppy programmer.
And that's the kind of remark that shows you haven't a clue about ergonomic language design. Why deliberately design a feature with so many extra, undetectable, error opportunities?
Oh, I know: why don't we just put all the blame on the programmer! They will just have to be extra careful instead on concentrating on more relevant matters.
A good thing that approach is not used on safety matters in real life.
(There's something I've heard about in the 1990's, "PSP", "Personal
Software Process"[*], that might help you increase your success rate
by reducing common errors you make.)
[*] https://en.wikipedia.org/wiki/Personal_software_process
That's brilliant, thanks. So when I'm finding it incredibly error-prone to write my applications in 100% assembly, it's nothing at all to do with the poor choice of language, I'm just incredibly sloppy, and that web-site will help me!
>
Here, it is not an advantage. I once asked David Brown how many of his
for-loops were simple iteration; I think he said 98.5%.
This number, I think, may be close to reality. - I want to remind
that N. Wirth gave such informal statistics as rationale for Pascal
only supporting for-loops with increment and decrement values of 1.
I agree with Wirth. Anything unusual can be trivially expressed with WHILE. Most languages support WHILE, and so can express anything that C's FOR loop can.
The result is that FOR is a simple, streamlined iteration feature, instead of a free-for-all which can require readers double-guessing the programmer's intention.
Now that is strange. - Before[*] you argued on a 'while' example:
"That would be a poor use of 'while'. And bizarre, to use
'while' for iteration, but 'for' for loops that are best
written as while!"
Do you understand WHY it was a poor choice? Clearly not. It was poor choice because you used WHILE to implement a simple iteration of 'i' over 'a' to b'. That is *exactly* what FOR should be used for.
There two main kinds of iterations, putting aside endless loops, and repeat-N-times with no index:
(1) Where the number of iterations is known in advance, and the
iteration is over a numerical sequence or a set of values
(2) Where the number of iterations is either not known in advance, or
the termination depends on some condition.
Here's my poser: which one of these is typically done by FOR in most languages, and which is done by WHILE?
I suspect you have got these mixed up. You showed WHILE being used for (1), and you heavily promote FOR to be used for (2).
Or maybe this everything backwards thinking is just typical of C!
There's a few properties that you have problems with that lie not
within the language but are inherent part of your personality. -
You clearly exposed two of them; above your problem of handling
your copy/paste programming errors ("PSP")
So, in your opinion, that issue I had was 100% my fault, and 0% due to poor language design?
To reiterate that C example:
for(i=0; i<M; ++i)
I had to duplicate this line and change 4 identifiers within it. In my syntax, I would duplicate this line:
for i to M do
and change only 2 identifiers. In C there is twice as much scope for the error, and there is more infrastructure for it to hide behind, but it still doesn't matter?
Suppose the loop indices are not needed inside the bodies; in my language I would just write:
to M do
to N do
Here I wouldn't copy and paste, it's easier to just type those 3 tokens! So there is no opportunity for error.
Do you still say that ergonomic language design plays no part in this AT ALL, it is always 100% Bart's fault?
>
* C needs you to specify how to increment the loop index
>
Of course; another advantage! (And this is common in many
programming languages, older and newer ones.)
>
You need to tell the computer how to count? OK!
Yes. - Either i++ or i+=2 or z*=10 or r<<=4 or ...
Even for 99.9% of loops where you increment by one? Yikes!
You say OK but you don't see the obvious applications, do you?
It's very simple:
for i := a to b do # automatically increments by 1 ...
for i := a to b by c do # ... unless told otherwise
The default should be to increment by 1. Do you have a problem with that concept? In Ada it's apparently:
for i in a .. b loop
It seems to have figured it out! Even Fortran managed it.
do 100 i = a, b # increment by 1
do 100 i = a, b, c # increment by c
This is a truely fascinating place, where black is white and every crappy misfeature is an essential must-have!
That doesn't make the crude and limited Fortran 'for' loop
any better only because it has a "100 continue" or "end do".
It is yet another advantage that C doesn't have, and which other languages have had to introduce.
In C, braces, /and the ability to not use them for one statement/ are another poor feature which can lead to often undetectable errors.
Just look at the vast number of placement syles that exist. It's all a huge headache that those languages with automatically closed blocks don't have.
Funnily enough, C's preprocessor is one of those languages:
#if
....
#endif
As I said above, this is topsy-turvy: the grown-up syntax is relegated to the preprocessor; the real language has the crappy syntax!
Having end-tags doesn't make Fortran a good language or its 'do'
loop a good syntax.
Why? It works and it's simple. You need 4 things to denote a loop header with an index variable:
(1) The name of the variable
(2) The start value
(3) The end value
(4) Some keyword to tell the compiler this is a loop statement
Plus whatever supplementary syntax the language stipulates. In modern Fortran that appears to be:
(5) '=' after the index
(6) ',' between the limits.
Total 6 elements (do i=a,b) . In mine, (2) is optional when it is 1, so it can be as little as 5 elements (for i to b do), otherwise 7.
C however needs 13 elements in all! Short and snappy.
(Note: Algol68 comments need a trailing # too.)
Yes, I know. I added that '#' for posting only. (Despite '#' is
[pairwise] usable in the Genie context I'm nonetheless using
the classical and portable CO ... CO in my programs instead.)
(Both are poor design choices. Leave off one # or CO, and everthing gets out of step. And it means you can't comment out code that contains comments. See it's not just C I can criticise.)
(Oh, right, and obviously also about your language/preferences.)
You tried to assert some superiority by describing Algol68 features, but forgot that my language was originally based on Algol68 syntax. Obviously tweaked to get bad parts out.
The whole "C" language is "primitive" (in some respects) if
compared to other HLLs.
Yes. (Why do I find it suprising to see you admit that?)
Where you think a terse DO OD is best others might prefer to see
it documented DO # nothing to do # OD and are delighted if that
"comment" is even standardized by a clear 'NOP' as in DO SKIP OD .
Huh? Empty {} blocks occur in C too; they don't need a comment. Maybe the contents are yet to be written, or are commented out.
do { quit; } else { }
Re: do { quit; } else { }