Hi,

I have read in the Linux Kernel malling list some emails, and I found
some points made by Linus Torvalds about Pasca;

http://idkn.wordpress.com/2008/04/15/the-reason-why-linus-torvalds-hate-pascal/

Ido

Who is Linus Torvalds?

Op dinsdag 15-04-2008 om 10:18 uur [tijdzone +0300], schreef ik:

Your statement in the blog-posting is not entirely true. What Linus does in this thread is arguing why goto's could be meaningfull sometimes. Apparently he thinks that the idea that goto's are evil in all cases comes from Nikolaus Wirth. To prove that he (Wirth) was wrong, he points at some weaknesses of the language that Wirth had developed. And that was indeed this old pascal version. This language didn't had any goto's but that didn't make it more readable. It would even be more readable if it had support for goto. (That's Linus statement)

Linus also put (traditional) before pascal, just to make this clear. So I don't see this as a 'rant on pascal', but just arguing with some examples of older languages that goto's could be good in some cases.

Joost.

Ah....the old goto arguing....how many beers have gone with it! Linus is just right, since everyday the purists of the OO languages still can't live without writing a GOTO; they just call it in another "politically correct" way:

raise Exception.Create("TA-DA!")

R#

2008/4/15, Joost van der Sluis :

There is a fundamental difference. You don't know where exactly this will end up (jump and destination are decoupled), and that destination can differ depending on calling sequence.

http://en.wikipedia.org/wiki/Linus_Torvalds

(it had support, just only numerical labels. Modula2 didn't have goto's. That came later (D2?), and same with break and continue)

Linus also put (traditional) before pascal, just to make this clear. So I don't see this as a 'rant on pascal', but just arguing with some examples of older languages that goto's could be good in some cases.

I do see it as a rant if you raves on how it is used to torture students etc. A point could have been made more sec.

However it shows again the image problem of pascal, cause by people making assumptions on old compilers during their student years, and keep comparing it to later ones forever.

If even reasonably intelligent people can't escape from it, maybe we are doomed.

Yeah, so did my reply was a joke ...

Op dinsdag 15-04-2008 om 10:21 uur [tijdzone +0200], schreef Marco van de Voort:

That's also what Linus says:

"(Yeah, yeah, most _practical_ versions of Pascal ended up having all the stuff necessary to break structure, but as you may be able to tell, I was one of the unwashed masses who had to write in "standard Pascal" in my youth. I'm scarred for life)."

If even reasonably intelligent people can't escape from it, maybe we are doomed.

Those people are getting older and older, we just need a younger audience. ;)

Joost.

Which is not surprised. Unless you are convinced that GOTO can't be abused :-)

Which, in some cases art least, makes "doing it the right way" even worse. :D

Vinzent.

Exceptions sometimes remind me of the COME FROM statement of INTERCAL: http://en.wikipedia.org/wiki/INTERCAL
I think even Wirth called exceptions even worse than come from.

The original text about this matter.

Go To Statement Considered Harmful
Edsger W. Dijkstra

http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html

I use GO TO when teaching pascal, but after all i ask them to not use it, it just a bridge to learning the logic of programming language.

There is another word i hate to use it it is EXIT.

Hello, Joost,

On Tuesday, April 15, 2008, 12:48:46 PM you wrote:

JvdS> Those people are getting older and older, we just need a younger JvdS> audience. ;)

It's sad you mentioned it.

I started using Pascal in University because of ACM-ICPC (while I studied C++ in the school). I participated only once and my team got the 7th place in my region, we didn't get to the next stage (they selected 7 teams, but with a non-trivial algorithm; probably none of us participated next years because of this), but nowadays the most notable result for me is that I like Pascal.

This particular way is impassable for youth nowadays: http://icpc.baylor.edu/systems/finals/ --- C/C++ and Java (both under Eclipse of course, because it's IBM).

There was (Free)Pascal some time ago. It was dropped from 2006, if I get it right (and in 2005 it had limited status).

I also understand EXIT as a bad programming practice, it makes life harder for code readers.

I don't ;-) Even Ada has an "Exit" instruction which one is better than the Pascal one because, with Ada, "Exit" is a keyword.

Using "Exit" is not of a bad programming practice. Suppose one has to write a big procedure, say 150 lines of code. Suppose now that, instead of writing

   if X = 0 then Exit;

at the beginning of the procedure, one writes

   if X  0 then
   begin
     ...

Does a reader immediately see that, when X = 0, the procedure does nothing? No. They have to read all the code, to search for the "end" that closes the "begin" in order to get sure there are no instructions after this "end". In such a case, with the "Exit" instruction the procedure is much easier to read.

mm
----
http://www.ellipsa.net/

150 lines of code in procedure, should be move into smaller parts of code imho.

But I believe in the motto of "die fast". As soon as you know that your code should not handle something, go away, don't continue your code, so exit have it uses. I think that every part of programming tools, have their use, the problem is the abusing of such tool, and using them even where there is no real use for it.

I have to agree, and can give an even better example. In the software I write, many times there are several conditions which need to be checked. If any of these conditions apply, then an appropriate result code should be set and the rest of the routine should not be executed. An example:

if ( payments per year  12 ) then begin
   Result := 1;
   exit;
end;
if ( rate = 0 ) then begin
   Result := 2;
   exit;
end;

... add 10 more checks

' ok - we have made it through all the validation checks, so now lets do some actual work
' relevant code goes here

The above is *so* much clearer than implementing 12 nested levels of if..then..else.

Alan

mm wrote

Rodrigo Palhano a écrit : > On Tue, 15 Apr 2008 19:39:37 -0300, Zaher Dirkey

Careful. Ada's "exit" is not Pascal's "exit", it's much more like Pascals "break" (and thus shares the same deficiences when it comes to the possibility of obfuscated control structures, but can be even worse).

What Pascal programmers know as "exit" is called "return" in Ada and in functions it always comes with the result, which makes it equivalent to FPC's "exit (ReturnValue);". Which is actually a quite good feature, because it usually leads to less uninitialized function results and an

|   exit (SOME_FAILURE_CODE);

clarifies the intention to the reader a bit better than

|if We_Are_Screwed then
|begin
|   Result := SOME_FAILURE_CODE;
|   exit;
|end {if};

or the usual shortcut:

|Result := SOME_FAILURE_CODE;
|
[... code ...]
|
|if We_Are_Screwed then
| exit; // Result should still be SOME_FAILURE_CODE, | // but did you really check?
|
[... more code ...]
|
|Result := EVERYTHING_WENT_WELL;

So "exit" is not that bad and IMO can't be abused too much. But YMMV, of course.

But with the former "break" you can write *really* obfuscated code.

(Pascal's) "Exit" is "exit" and there's no guessing where that leads to. With "break" you always have to check the code surrounding the statement.

Vinzent.

When you use it at the begining it may be arguably ok. But when it is used in the
middle of procedure code it may be hard to notice.

this

is better than this ?

if ( payments per year  12 ) then begin
   Result := 1
Else if ( rate = 0 ) then
   Result := 2;

or even this ?

begin
  If not CheckPayments (Result) Then
     CheckRates(Result);
end;

Well, i guess that´s particular, i am just not a huge fan o EXITing code in any
unpredictable place.

In my opinion, yes.

First of all, you would need to append an else clause to your example that the code following my block would need to be placed in.

e.g.

if ( payments per year  12 ) then begin
  Result := 1;
end else if ( rate = 0 ) then begin
  Result := 2;
end else begin
  .. lots o' code here
end; // end if - else if - else

From a code readability standpoint, if I am someone trying to understand the above code and I want to know what happens when the rate is zero, I see that a result code is set. I then need to parse down to the end of the multiple if-else if-else code to see if anything else happens after that block of code.

With the code I prefer (at the top of the email), it is clear that a result code is set, and then BAM! (as Emeril Lagasse would say), I am done. It also reduces another level of indentation, which I like.

Finally, during code maintenance, some other person working on the code might append new code at the end of the routine, but not place it inside the "end else begin" block, not thinking about what might happen with the result-code generating (and more exceptional) cases.

These are just my preferences, I'm not saying they are the best or are THE correct way of doing things. In my experience, I have found that this method works well for *me*.

Alan

I think "exit" and "goto" have their uses. Here is an example:

for a := 0 to x do
  for b := 0 to y do
    for c := 0 to z do
       if (...) then
       begin
           // Do something and then exit all loops
           exit;  // Or maybe: goto OutSideOfLoops;
       end;

In Pascal I can't change the 'a' and 'b' values to force the end of the loop. So what other GOOD option do I have but to use exit or goto?

Andreas

The problem of GOTO is that C doesn't have one. If C had one, and Pascal didn't have a GOTO, they would blame Pascal for not having it. In assembler GOTOs make a lot of sense (i.e. JMP and Jxx), and it's weird C doesn't have one, after all C tries to be the lowest level of the highest level languages. It's great Pascal have both high and low level features.

In my opinion nested functions are a more structured way of creating a program, that's something you don't have in C.

And when you have to write something like:

int x, int y, int z, int w, int a, int b, int c...

Instead of the faster, more elegant and more readable Pascal way:

x, y, z, w, a, b, c: Integer

I don't understand why people say that C is a faster language... neither the compiler beats Pascal.

Also, what's the advantage of having a return, it forces to quit the function, and that's lack of freedom. If you wanted to keep working with the value, you would have to create a temporal variable, which is less readable, especially if you are already working with other temps.

C does have goto.

cheers
Wayne

Use a while or repeat loop. The whole point of a for-loop is exactly to have the compiler ensure (to the best of its abilities) that you do not accidentally modify the loop variables.

Jonas

Well, if you think an exit is ugly, image changing this code into while loops. May as well use assembly.

OT: The only things I dislike about pascal is that the value of a variable at the end of a for loop is undefined. It should remain at the value it had when exiting the loop.

Andreas

Yes, of course :-) Now, I don't quite agree with you with what you call obfuscated control structures. I find the Ada "Break" (which is called "exit") very handy. In order to do the same with Pascal, not taking in account some sub-optimal Standard Pascal fanatic method, one has to use a goto.

For instance, the Ada code

   for i in imin .. imax loop
     J_LOOP:
     for j in jmin .. jmax loop
       for k in kmin .. kmax loop
         exit J_LOOP when <some test>;
         DoSomething;
       end loop;
     end loop J_LOOP;
   end loop;

is equivalent to

   for i := imin to imax do
   begin
     for j := jmin to jmax do
       for k := kmin to kmax do
       begin
         if <some test> then goto EndJLoop;
         DoSomething;
       end;
     EndJLoop:
   end;

but I prefer the Ada code.

mm
----
http://www.ellipsa.net/

Hi!

GCC and almost all the other C implementations have the goto statement. It is just ugly and dangerous use it many times in a program. But IMHO any compiled language should have goto because many times we need to do unstructured code to run fast (in complex search code for example). So goto is not a matter of principles about the language, it is just a "dirty and ugly" approach to solve problems that many times are useful.

Anyway in my oppinion a very complex program in a structured language with more than a dozen gotos should not be considered a good pratice (except for kernel internals and things like this -- that many times would be a lot more complex without the gotos).

Ric.

I hate exit when i try to improve a procedure

 some code
if (b) then
exit;
 some code

for long procedures i cant notice exit here and add some resource or memory uses

AnObject := TAnObject.Create;
try

some code

 if (b) then
   exit;

some code

finally
  AnObject.Free;
end;

Now Exit leave the procedure without freeing "AnObject". We need a new Exit keyword to jump to Finally section (I do not think Abort is useful here).

But AnObject is freed. If ever Exit had the behaviour you describe, we would have a big problem.

mm
----
http://www.ellipsa.net/

Lets hear what the old fathers told us...
when Linus Torvalds was still running around the Christmas tree....

Niklaus Wirth,

Algorithms and Data Structures 1985 (Oberon version: August 2004, afaik first published 1975 in German)

(Regarding pointers and goto statements..)
...This phenomenon of power and flexibility being intimately coupled with the danger of misuse is well known in programming, and it particularly recalls the GOTO statement. Indeed, if the analogy between program structures and data structures is to be extended, the purely recursive data structure could well be placed at the level corresponding with the procedure, whereas the introduction of pointers is comparable to the use of GOTO statements. For, as the GOTO statement allows the construction of any kind of program pattern (including loops), so do pointers allow for the composition of any kind of data structure (including rings).

Kernighan , Ritchie, The C Programming Language 1978 page 62

C provides the infinitely-abusable goto statement, and labels to branch to. Formally the goto is never necessary and in practice it is almost always easy to write code without it. We have not used goto in this book. Nonetheless , we will suggest a few situations where goto's may find a place. The most common use is to abandon processing in some deeply nested structure, such as breaking out of two break statement cannot be used directly since it leaves only the innermost loop....
.....
Although we are not dogmatic about a matter, it does seem that goto statements should be used sparingly, freundlichen Grüßen

Markus Greim

True, the object is freed and the procedure exited. Now it would be nice to jump to the finally clause and continue in the procedure. Sigh, wishfull thinking.

Andreas

I agree, the goto should only be used to IMPROVE code readability.

About break. I would like to see an implementation of Break(x) where x is the number of loops to break out of.
Correction: I would not like this, I would LOVE it.

Andreas

I am not like break(x) it also make improvement my procedure was sensitive, i must count how many loop i have in, and i must care if i added a new loop around the code that looped (hmm bad english).

Andreas Berger wrote

About break. I would like to see an implementation of Break(x) where x is the number of loops to break out of. Correction: I would not like this, I would LOVE it.

Oh, another Adaism trying to creep into Pascal...? :D

But let me revisit your proposal: Of course, break with such a "number of level" argument breaks your code (hence the name?), once you add another loop somewhere around it.

In that case I'd rather go with goto. At least there's a label and a definite target to jump to.

The alternative is the named loop as in Ada, which makes it possible to break out of more than just one loop, but wouldn't have the hassles of a "where does this 'break (3)' lead us?". At least you name the loop you want to abandon at the point of "exit" and you can look up the label in the code, instead of counting the number of levels (and maybe even missing one).

Sorry, but as much as you might think, you'd love this; if you really need something like that, rather use "goto" or throw a bloody exception.

Vinzent.

Greetings:

Running the code below we can see that the Finally works correctly with the exit statement:

Program Test;
{$mode objfpc}{$H+}
Procedure x(i :Integer);
Begin
   Try
   Begin
     WriteLn('Running Try');
     if (i=2) then exit;
     WriteLn('After if(i=2)');
   End;
   Finally
     WriteLn('Finally reached');
   End;
End;
// Main program
Begin
   WriteLn('Ini');
   x(2);
   WriteLn('End.');
End.

One example of label/goto and de-structuring code is below (in C). The statement "return(res)" in C returns immediately the value of res.

/* This func return an integer number or -1 if error */
int do_something(void)
{
/* vars */
  int ret;
  resourceA *resA;
  resourceB *resB;
  resourceC *resC;
  resourceD *resD;
/* code */
res =  -1; // Error
// Alloc resources
  resA=alloc_resourceA();
/* This funcs return a pointer or NULL (0) if error. */
  if (! resA) return(-1); // Error. There are no resources to alloc resA.
  resB=alloc_resourceB();
  if (! resB) goto puke;
  resC=alloc_resourceC();
  if (! resC) goto vom;
  resD=alloc_resourceD();
  if (resD) goto throwout;

// Do things
........ code .......
........ code .......
......... put some value in res to return .....

// Free resources on error area
throwout:
  free_resourceD(resD);
vom:
  free_resourceC(resC);
puke:
  free_resourceB(resB);
// return
  return(res);
}

The labels say my oppinion of indiscriminate use of goto.

The correctly structured code goes below:

/* This func return an integer number or -1 if error */
int do_something(void)
{
/* vars */
  int ret;
  resourceA *resA;
  resourceB *resB;
  resourceC *resC;
  resourceD *resD;
/* code */
  res = -1; // Error
  resA=alloc_resourceA();
/* This funcs return a pointer or NULL (0) if error. */
  if (resA)
    {
      resB=alloc_resourceB();
      if (resB)
          {
              resC=alloc_resourceC();
              if (! resC)
                  {
                      resD=alloc_resourceD();
                      if (resD)
                          {
                             // Do things.
                              ........ code .......
                              ........ code .......
                              ......... put some value in res to return .....
                              free_resourceD(resD);
                          };
                        free_resourceC(resC);
                  };
              free_resourceB(resB);
          };
      free_resourceA(resA);
    };
   return(res);
};

Well, bad organized (no sections), the resources are scatteres around (more dificult to debug) and a lot recursive "if"s (make it dificult to firgure at the first what the code is doing). . But it is a beautiful piece of code.

The two codes above will generate very close asm code, so they will have almost the same performance.

So you can choose: Simple, ugly and mantainable or elegant and and dificult to understand. All supposing you know how to use correctly the labels not doing some nasty thing with it.

Imagine now the code above with 30 or 40 resources. At least in my oppinion it justify the use of some gotos.

But everyone can choose the best way to program. The two ways work very well after some debugging. It is just a matter of choice.

Ric.