Recent

Author Topic: Re: language improvement suggestions (the spin off)  (Read 16994 times)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 10837
  • Debugger - SynEdit - and more
    • wiki
Re: Re: language improvement suggestions (the spin off)
« Reply #15 on: November 24, 2019, 09:51:59 pm »
ok, so it saves  a few local vars.

Or reordering into 4 big blocks, for each bool/bool variation.
It does a whole lot more than that and, I will also address the following statements of yours, all in one shot:
With the correct spacing, you achieve exactly the same.
It is just replacing each keyword by another, (and the local tmp var)
When using "if"/"else" to implement the equivalent of that EVALUATE statement, the expressions, in this case A > B and X = Z have to be retyped but, that's not the really bad part, the really bad part is that the programmer who is maintaining that code has to _read_ every statement and ensure that the conditions _match_ in every subsequent statement.   
Not, if (as suggested) the expressions are pre-evaluated (once, just once) into local vars. You even quoted that part of my answer, and then (apparently) are ignoring it?

Yes, it needs extra lines for the assignment to the local vars.
On the other hand, it makes it (by far) less likely, that in subsequent names 2 columns are switched by accident. (Especially if there are more "also" involved.
Maybe I wanted the 3rd "also" to be true, all others false. But by accident, I did put true into the 4th (keeping the total column count correct). There will be no warning, no error, no easy way to spot (it is just a long line of "also true also false also ....", with no indication which "also ..." is for which expression.)
Yet if I use local vars (i.e. give each expression a name), then this error can not happen, as I immediately on each line can see, which names should be true and which should be false. (yes slightly more typing, but so much more readable)

See the example code in this reply https://forum.lazarus.freepascal.org/index.php/topic,47498.msg340388.html#msg340388
Each "and" ("also") clearly indicates which expression is wanted as true and which is wanted as false. What in this line is less readable than in a "when" line?

Having names for elements (and close to the elements) is so important, that I have frequently seen code where those names (when the language did not need them) were added in comments. Yet here we have a feature that again intentionally omits them

Quote
  for i in TSOMERANGE do <statements here>[/code] that construct is a significant improvement over
Code: Pascal  [Select][+][-]
  1. for i := low(TSOMERANGE)..high(TSOMERANGE) do < statements here>
and the reason is because in the first case the low and high bounds of the loop are expressed in a single expression, that is, atomically; whereas in the second case the programmer has to _read_ two expressions, low() and high() - which may not necessarily refer to the same type - to determine what the bounds of the for loop are.
Please see bottom of post first.

"for in" for ranges, actually is sugar. And drops the information that it is a range/ordinal type.

"for in" is (in my opinion)  justified because it allows "for a in SomeObject", where the object implements a custom iterator. (Sure you can write loops for that without "for in", but that is a much bigger difference (IMHO).

Quote
Similarly with the EVALUATE statement, reading the EVALUATE clause tells the programmer what expressions are involved in columns 2 and 3 immediately.  There is _no_ need to read every statement and ensure that the expressions in column 2 and 3 are always the same.  That is not syntactic sugar, that is simply cleaner, much easier to understand and maintain code.
As I said, reading the (lets say) 10th "when" line (with each "when" line before, being followed by a block of code, so maybe 40 to 50 lines down from the "evaluate"), the "also true also false also false also true ...." is really not helping. (if you do not have an photographic memory, to remember the "evaluate" line.
So how is that more readable than assigning the result of each expression to a local variable (the name of which describes its content) and then using this variable in each "if" statement?


Quote
In addition to that, the conditions used in an if/else sequence are _not_ guaranteed to be stable/constant. 
Still local vars. But that got somehow ignored.

Quote
And, if all that wasn't enough, that construction makes it much easier for the compiler to generate optimal code, i.e, code that isn't evaluating the expression in column 2 and 3 again and again and again and again... yuk!
Still local vars. But that got somehow ignored.

Quote
Syntactic sugar.
This isn't syntactic sugar unless the definition of syntactic sugar includes constructs such as, for instance, "for" and "repeat/until" loops. It is a much clearer and powerful way of expressing multi-branch conditions just as "for" and "repeat/until" loops are a much cleaner and more powerful way of implementing loops without having to resort to "goto" or some other contorted way of controlling program flow.

Well yes its a fine line between sugar and other..... And one that is to an extend biased by subjective opinion.

From what I read on it sofar, the only part that is NOT sugar about it, is that it needs each expression only once, and thereby avoids re-evaluation.

However:
- without giving a name (as reference) to the result of each expression, this is actually introducing problems (its ok for small samples, but not for bigger cases)
- The same effect can be done with local vars. It is at best a shorthand for assigning those local vars (and a shorthand can be seen as sugar, but may also be more than just sugar).

As for an the 2nd line goes, it is very much like "with ... do". And the "with" statement certainly has people who would die for it, but also an equal amount of people who would prefer death over it.


Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 10837
  • Debugger - SynEdit - and more
    • wiki
Re: Re: language improvement suggestions (the spin off)
« Reply #16 on: November 24, 2019, 10:15:05 pm »
So I went the extra mile and googled: github cobol "evaluate" "also" cbl
https://github.com/Apress/beg-cobol-for-programmers/blob/master/978-1-4302-6253-4_Coughlan_Ch05/Listing5-9.cbl

A winner for "short" (as in, least amount of writing)

But the only one who will be happy is my optometrist, when I will need new glasses. This hurts my eyes.

Reading it, on each line I go: "21 throu 99" of what?
The statement takes the expression "Qty = 21 throu 99", tears it appart, puts half of it in one line, and the other half somewhere else....

I do not know, if this example is an abuse, or the desired form of use.... But it is not good.

Also found https://github.com/uwol/proleap-cobol-parser/blob/master/src/test/resources/io/proleap/cobol/ast/tandem/Evaluate.cbl
Not better. Putting each ALSO into a new line slightly helps, but...


lainz

  • Hero Member
  • *****
  • Posts: 4689
  • Web, Desktop & Android developer
    • https://lainz.github.io/
Re: Re: language improvement suggestions (the spin off)
« Reply #17 on: November 24, 2019, 10:42:06 pm »
When using "if"/"else" to implement the equivalent of that EVALUATE statement, the expressions, in this case A > B and X = Z have to be retyped but, that's not the really bad part, the really bad part is that the programmer who is maintaining that code has to _read_ every statement and ensure that the conditions _match_ in every subsequent statement.

Yes, what I do to don't repeat everything is evaluate in a variable

like C:= A > B and X = Z;

Or sometimes make a function that returns a boolean, passing the desired parameters.

But this solves only one part, as you say the calling to that function or the "and C" part must be added for all "else" / "else if". We're repeating code.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 10837
  • Debugger - SynEdit - and more
    • wiki
Re: Re: language improvement suggestions (the spin off)
« Reply #18 on: November 24, 2019, 11:11:27 pm »
But this solves only one part, as you say the calling to that function or the "and C" part must be added for all "else" / "else if". We're repeating code.
A function is diff to a local var...

repeating & local var => well that repeat is for the better.
After all Pascal is verbose. Hey, I to have done some "beautiful" short code (in perl)... I do not say though that it was the best code ever written on this earth (though naturally it was, ... not ;) )

If the evaluate was like:
Code: Pascal  [Select][+][-]
  1. evaluate a() > b() as AgB ALSO x = z as XZ ALSO ....
  2. WHEN AgB = True also XZ <> true ....
That would make it readable. But then again, where does that differ from
Code: Pascal  [Select][+][-]
  1. AgB := a() > b();
  2. XZ := x = z;
  3. if AgB   and XZ then
  4. else if  ....   ... then
  5. else if  ....   ... then
  6. else if  ....   ... then
  7. else if  ....   ... then
  8.  
You could a few lines to set the local vars. Ok a bit more typing, but not really reducing readability. And yes if the rest of your procedure has relations with spaghetti, then the scope of those vars is bigger than needed. But var scope in Pascal is generally different to some other languages.

And yes instead of "when" you have "else if". Huge diff??? I don't think so.

What else?
Yes you have the names "AgB" in each line. But I just pointed out, that should be the case in "evaluate" / "when" too. The absence of those names in "when" is a big problem (at least for me in cases as described in my previous posts).

My conclusion remains: if you want the shortest way of writing it, then eval is the way. But short is not equal to readable. Too short is even the opposite (not implicating where "too short" begins).


Of course if you have an editor that displays your "evaluate" with helplines, to make it like a spreadsheet.... Then it may be super readable. But if you need such a special editor, then it is not readable in itself. ;)


Also I do understand, if you look often enough and long enough on something it becomes familiar, and something one would not like to miss. But that does not make it in itself better (or readable for that matter).
« Last Edit: November 24, 2019, 11:13:42 pm by Martin_fr »

440bx

  • Hero Member
  • *****
  • Posts: 5010
Re: Re: language improvement suggestions (the spin off)
« Reply #19 on: November 24, 2019, 11:51:31 pm »
Not, if (as suggested) the expressions are pre-evaluated (once, just once) into local vars. You even quoted that part of my answer, and then (apparently) are ignoring it?
I didn't ignore anything.  The fact is, you use _unnecessary_ local variables _and_ even with local variables, the programmer has to carefully read the entire if/else chain to ensure that A is always compared to B (and not other variables).  As previously stated, in addition to that, using local variables leaves open the possibility of an incorrect comparison, e.g, A compared against Z, which is simply not possible when using the EVALUATE statement.

Yes, it needs extra lines for the assignment to the local vars.
And, as I just pointed above, having those additional local variables is _not_ without consequences.

On the other hand, it makes it (by far) less likely, that in subsequent names 2 columns are switched by accident. (Especially if there are more "also" involved.
Less likely, yes but, not impossible in the sequence of if/else since they are repeated.  Using the EVALUATE it simply isn't possible because their position occurs only _once_, since they aren't repeated they cannot be misplaced anywhere else.

Maybe I wanted the 3rd "also" to be true, all others false. But by accident, I did put true into the 4th (keeping the total column count correct). There will be no warning, no error, no easy way to spot (it is just a long line of "also true also false also ....", with no indication which "also ..." is for which expression.)
But with the evaluate, it is trivial to simply count the possibilities and see that the expected pattern is present, that is, (true, true), (true, false), (false, true) and (false, false).  That pattern is obscured in a chain of if/else because of the repeated presence of if/else/then (and hopefully, it's formatted reasonably well which is far from a given.)

Yet if I use local vars (i.e. give each expression a name), then this error can not happen, as I immediately on each line can see, which names should be true and which should be false. (yes slightly more typing, but so much more readable)
Using local variables will make the expression more readable, I'll give you that but, you're conveniently ignoring the fact that they may be switched in one of the many if/else statements.  You're also ignoring the fact that now the programmer has to visually determine if any of those locals are modified in any of the if statements, something which is unnecessary when using EVALUATE (since, it normally wouldn't use locals.)

See the example code in this reply https://forum.lazarus.freepascal.org/index.php/topic,47498.msg340388.html#msg340388
Each "and" ("also") clearly indicates which expression is wanted as true and which is wanted as false. What in this line is less readable than in a "when" line?
First, you only showed _one_ line, of course it's readable, it's only one line.  Second, it is almost as rare as Christ's second coming to see if/else chains formatted the way you formatted it (nice formatting, I do appreciate that.)  In contrast, an EVALUATE statement is almost always seen properly formatted (WHEN and ALSO clauses vertically aligned.)  Of course, there are occasional exceptions as you noted further down your post.

Having names for elements (and close to the elements) is so important, that I have frequently seen code where those names (when the language did not need them) were added in comments. Yet here we have a feature that again intentionally omits them
It is also important _not_ having to name them, that's why the language allows expressions most everywhere, so the programmer doesn't have to declare a variable for every expression to be used in a statement.  In this particular case, those additional variables are a clear indication of a deficiency in the language.  If the expression is complicated/long then, for clarity, it is justified but, for a simple expression such as A > B, it is _not_ justified.

"for in" for ranges, actually is sugar. And drops the information that it is a range/ordinal type.
If a construct prevents a potential error then it isn't sugar, it is practical and valuable because it prevents a possible error.

"for in" is (in my opinion)  justified because it allows "for a in SomeObject", where the object implements a custom iterator. (Sure you can write loops for that without "for in", but that is a much bigger difference (IMHO).
I agree it is justified, whether used with objects/classes or otherwise.

As I said, reading the (lets say) 10th "when" line (with each "when" line before, being followed by a block of code, so maybe 40 to 50 lines down from the "evaluate"), the "also true also false also false also true ...." is really not helping. (if you do not have an photographic memory, to remember the "evaluate" line.
It helps plenty but, it cannot be argued that a 50 line EVALUATE statement requires paying a little more attention than a 12 line EVALUATE.  That is true of any statement but, there is a whole lot less clutter getting in the way with an EVALUATE statement than what is found in the equivalent chain of if/else.  It seems you conveniently ignored that.

So how is that more readable than assigning the result of each expression to a local variable (the name of which describes its content) and then using this variable in each "if" statement?
I already mentioned the problem of having to have local variables therefore I won't repeat it but, as far as readability, the EVALUATE is much easier to read and discern patterns in than in the equivalent if/else chain.  If you doubt that, write both and compare them.

Still local vars. But that got somehow ignored.
I didn't ignore them but, you did ignore the problems they create and leave open.  See above for what those are.

And, if all that wasn't enough, that construction makes it much easier for the compiler to generate optimal code, i.e, code that isn't evaluating the expression in column 2 and 3 again and again and again and again... yuk!
Still local vars. But that got somehow ignored.
Not ignored at all and, using local variables does not enable the compiler to _easily_ generate optimized code because the compiler cannot assume that the values of the local variables are kept constant through the entire if/else chain.  In the EVALUATE statement, the compiler knows upfront that those values cannot change since they are not in variables thus making optimizing the statement much simpler.

Well yes its a fine line between sugar and other..... And one that is to an extend biased by subjective opinion.
It's subjective until you create the graph for the two constructs, which clearly shows that the EVALUATE graph is much simpler than that of the if/else chain AND, as previously stated, the EVALUATE makes it evident that the values being tested _cannot_ change in the construct something which the if/else chain cannot guarantee nor makes it visible since it is saddled with having to use local variables.

From what I read on it sofar, the only part that is NOT sugar about it, is that it needs each expression only once, and thereby avoids re-evaluation.
Yes and, that very small detail makes a BIG difference.

However:
- without giving a name (as reference) to the result of each expression, this is actually introducing problems (its ok for small samples, but not for bigger cases)
What problems does it introduce ?... name them or show an example AND it must be a problem that is _not_ present when using if/else.

- The same effect can be done with local vars.
I never said the logical construct cannot be expressed in Pascal.  What I do say is, the resulting construct is noticeably inferior in readability and maintainability than the equivalent EVALUATE statement.

It is at best a shorthand for assigning those local vars (and a shorthand can be seen as sugar, but may also be more than just sugar).
It's not a shorthand to assign local variables since it doesn't use any.  No local variables = none of the downsides of using local variables (again, see above for what they are.)


So I went the extra mile and googled: github cobol "evaluate" "also" cbl
https://github.com/Apress/beg-cobol-for-programmers/blob/master/978-1-4302-6253-4_Coughlan_Ch05/Listing5-9.cbl

A winner for "short" (as in, least amount of writing)
I appreciate your looking it up.  I won't say anything about it being "short" or otherwise but, it is a lot clearer than the equivalent in Pascal.

But the only one who will be happy is my optometrist, when I will need new glasses. This hurts my eyes.
That's not bad at all.   The same construct using if/else chains would probably result in your being blind thus requiring a white cane and a seeing dog.  Your optometrist would be _very_ unhappy.

Reading it, on each line I go: "21 throu 99" of what?
Of Qty of course.  Expression in first column applies to the item in the first column.

The statement takes the expression "Qty = 21 throu 99", tears it appart, puts half of it in one line, and the other half somewhere else....
Maybe it's your browser that's doing that.  When I look at it, everything is perfectly aligned.  Like this (added asterisks to make the logical groups even more visible):
Code: ASM  [Select][+][-]
  1. EVALUATE Qty      ALSO   TRUE     ALSO Member  
  2. **
  3.       WHEN  1 THRU 5  ALSO QP <  500  ALSO ANY  MOVE 0  TO Discount
  4. *
  5.       WHEN  1 THRU 5  ALSO QP <  2000 ALSO "Y"  MOVE 7  TO Discount
  6.       WHEN  1 THRU 5  ALSO QP <  2000 ALSO "N"  MOVE 5  TO Discount
  7.       WHEN  1 THRU 5  ALSO QP >= 2000 ALSO "Y"  MOVE 10 TO Discount
  8.       WHEN  1 THRU 5  ALSO QP >= 2000 ALSO "N"  MOVE 8  TO Discount
  9.  
  10. **    
  11.       WHEN  6 THRU 20 ALSO QP <  500  ALSO "Y"  MOVE 3  TO Discount
  12.       WHEN  6 THRU 20 ALSO QP <  500  ALSO "N"  MOVE 2  TO Discount
  13. *
  14.       WHEN  6 THRU 20 ALSO QP <  2000 ALSO "Y"  MOVE 12 TO Discount    
  15.       WHEN  6 THRU 20 ALSO QP <  2000 ALSO "N"  MOVE 10 TO Discount      
  16. *
  17.       WHEN  6 THRU 20 ALSO QP >= 2000 ALSO "Y"  MOVE 25 TO Discount      
  18.       WHEN  6 THRU 20 ALSO QP >= 2000 ALSO "N"  MOVE 15 TO Discount    
  19.  
  20. **      
  21.       WHEN 21 THRU 99 ALSO QP <  500  ALSO "Y"  MOVE 5  TO Discount
  22.       WHEN 21 THRU 99 ALSO QP <  500  ALSO "N"  MOVE 3  TO Discount  
  23. *
  24.       WHEN 21 THRU 99 ALSO QP <  2000 ALSO "Y"  MOVE 16 TO Discount
  25.       WHEN 21 THRU 99 ALSO QP <  2000 ALSO "N"  MOVE 15 TO Discount    
  26. *
  27.       WHEN 21 THRU 99 ALSO QP >= 2000 ALSO "Y"  MOVE 30 TO Discount
  28.       WHEN 21 THRU 99 ALSO QP >= 2000 ALSO "N"  MOVE 20 TO Discount
  29. END-EVALUATE
  30.  

I do not know, if this example is an abuse, or the desired form of use.... But it is not good.
I can't fault you for having reservations about the other example, it definitely leaves something to be desired.  It looks like a C++ programmer got lost in the land of COBOL and, as expected, the result are "less than desirable"... oh well, he'll eventually find his way back to home++.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 10837
  • Debugger - SynEdit - and more
    • wiki
Re: Re: language improvement suggestions (the spin off)
« Reply #20 on: November 25, 2019, 01:38:52 am »
Ok thats gonna be a long answer....
Not, if (as suggested) the expressions are pre-evaluated (once, just once) into local vars. You even quoted that part of my answer, and then (apparently) are ignoring it?
I didn't ignore anything.  The fact is, you use _unnecessary_ local variables _and_ even with local variables, the programmer has to carefully read the entire if/else chain to ensure that A is always compared to B (and not other variables).  As previously stated, in addition to that, using local variables leaves open the possibility of an incorrect comparison, e.g, A compared against Z, which is simply not possible when using the EVALUATE statement.
Ok, point for evaluate. It ensures you have all conditions in each line, as it expects a total count.
So:
- in "if" you can drop a column
- in "evaluate" you can swap two columns
  (swapping in if is possible, but does not do damage, as the order of pre-evaluated arguments in chained "and" does not affect the result)
  => more on this 2 paragraphs below....


Quote
Yes, it needs extra lines for the assignment to the local vars.
And, as I just pointed above, having those additional local variables is _not_ without consequences.
   
The consequences you pointed out, are due to the "if" does not enforce the count of expressions.

The variables make no diff. In fact a/some compiler may internally create them for an "evaluate"

   
Quote
On the other hand, it makes it (by far) less likely, that in subsequent names 2 columns are switched by accident. (Especially if there are more "also" involved.
Less likely, yes but, not impossible in the sequence of if/else since they are repeated.  Using the EVALUATE it simply isn't possible because their position occurs only _once_, since they aren't repeated they cannot be misplaced anywhere else.
   
Your answer does not seem to match my statement.
Just because "evaluate enforces the number of "also" does not mean, they can not be mis-placed.

If I want to write:
Code: Pascal  [Select][+][-]
  1. evaluate cnt also max also min also avg
  2. when 1 also 2 also 3 also 4
It can by accident happen that I write
Code: Pascal  [Select][+][-]
  1. when 1 also 3 also 2 also 4
Since when I write the 3 there is no named reference what it is... It could be "min" or "max"... Easy to spot, if the evaluate is just 1 or 2 lines above. But when I have only a handful of "when" then changes of error are very low for "evaluate" as well as for "if".
It matters with growing amount of combinations. But then you easily get 10 or 20 "when", and each has some code attached to it. So the "evaluate" may well be off screen.

If the evaluate is off screen, then it needs to be something like (and cnt,max,min are pre-evaluated:
Code: Pascal  [Select][+][-]
  1. when cnt=1 also min=2 also max=3 also avg4
(the "evaluate" could still enforce that the 4 expressions, containing the 4 values, are all present)

---
And yes.
Code: Pascal  [Select][+][-]
  1. case a of ....
also splits the expression, having the first half of it in the "case" line, and then a number of possible 2nd parts for each block.
But it is easier to stick that together, since it is only one expression that is ripped... that needs to be kept in mind.

"evaluate" can split any amount of expressions. That is not a good idea to me.

 
Quote
Maybe I wanted the 3rd "also" to be true, all others false. But by accident, I did put true into the 4th (keeping the total column count correct). There will be no warning, no error, no easy way to spot (it is just a long line of "also true also false also ....", with no indication which "also ..." is for which expression.)
But with the evaluate, it is trivial to simply count the possibilities and see that the expected pattern is present, that is, (true, true), (true, false), (false, true) and (false, false).  That pattern is obscured in a chain of if/else because of the repeated presence of if/else/then (and hopefully, it's formatted reasonably well which is far from a given.)
 
My quote was still on "when 1 also 2" could accidentally be "when 2 also 2". That is all columns, and all rows are present. But they have incorrect values.

Your answer seem to be about, all possibilities are covered. That is if 2 boolean are evaluate, there should be 4 "when". But the same there should be "4 if". No difference there.

The possibility of missing a column in one of the conditions was covered above (pro and con on both sides).
For this point therefore the comparison is only about missing an entire "when" or missing an entire "if". Both can be counted the same way.

Also counting that way is only for boolean or enum. "Evaluate" can also match integers. Then you do not know how many "when" there must be.

 
Quote
Yet if I use local vars (i.e. give each expression a name), then this error can not happen, as I immediately on each line can see, which names should be true and which should be false. (yes slightly more typing, but so much more readable)
Using local variables will make the expression more readable, I'll give you that but, you're conveniently ignoring the fact that they may be switched in one of the many if/else statements. 
 
Afaik covered above.
* IF: an entire "also" may be missing, as no enforcement for the count of sub expressions
* Eval: I may write "when 2 also 1" where I meant to write "..1 .. 2"
I guess switched refers to the 2nd?
Well, I can switch "if (min=1) and (max=2)" to "if (min = 2) and (max=1)" => but that is no immediate problem.
Switching it to "if (min=2) and (mag=1)" is far far less likely using "if with locals" than using "evaluate". It is more likely to go wrong with eval., because in eval when I type "1" I have no close-by visual reference what it is compared too. (Yes if the "evaluate line is right above, but that is for the first "when" only.)

 
Quote

You're also ignoring the fact that now the programmer has to visually determine if any of those locals are modified in any of the if statements, something which is unnecessary when using EVALUATE (since, it normally wouldn't use locals.)
 
Only one "if" should be entered (so it did ask about, how evaluate handles this)....
If only one "if" is entered, then modifications to the vars do not matter. The other "else if" will never be tested, due to the "else"

In case evaluate allows to enter more than one "when" statement....
Well Pascal has a write protected variable
Code: Pascal  [Select][+][-]
  1. for AB in TBoolArray.Create(a=b) do begin
  2.   // other vars as for in
  3.   // the if/else if/else if blocks
  4. end;
  5.  
Ok. Not serious. If evaluate can enter more than one "when", then point to you.



 
Quote
See the example code in this reply https://forum.lazarus.freepascal.org/index.php/topic,47498.msg340388.html#msg340388
Each "and" ("also") clearly indicates which expression is wanted as true and which is wanted as false. What in this line is less readable than in a "when" line?
First, you only showed _one_ line, of course it's readable, it's only one line.  Second, it is almost as rare as Christ's second coming to see if/else chains formatted the way you formatted it (nice formatting, I do appreciate that.)  In contrast, an EVALUATE statement is almost always seen properly formatted (WHEN and ALSO clauses vertically aligned.)  Of course, there are occasional exceptions as you noted further down your post.
 
If I use "if else if else if" in an "evaluate" manner, of course I have to format it the same way. And that is a feature that is available...
You havent seen this with "if", well that is not a request for a new feature, but for educating people.

Or shall I read this statement as "the (supposed) readability of evaluate, is actually not coming from the evaluate statement, but from the code formating people have adapted"?


If there are multiply "else if" lines, they will be equally readable as multiple "when" lines.
The main diff here are
1) word substitution: "when" > "else if" / "also" > "and"  / That should not affect readability, as in anycase if such a feature where to be added, keywords might be different too.
2) instead of "1 also 2 also 3 also 4" you get "(cnt = 1)   and   (min = 2)   and   (max = 3) and (avg = 4)". So you do not constantly need to scroll to the "evaluate" line. IMHO better.

btw, there is an editor macro for aligning things (on wiki pascal script macros). Not powerful enough for this, but a start.

 
Quote
Having names for elements (and close to the elements) is so important, that I have frequently seen code where those names (when the language did not need them) were added in comments. Yet here we have a feature that again intentionally omits them
It is also important _not_ having to name them, that's why the language allows expressions most everywhere, so the programmer doesn't have to declare a variable for every expression to be used in a statement.  In this particular case, those additional variables are a clear indication of a deficiency in the language.  If the expression is complicated/long then, for clarity, it is justified but, for a simple expression such as A > B, it is _not_ justified.
 
Ok, I wasn't clear enough. Having names for expression, to which you later refer again.
And yes, I am aware of "with .. do", and I made my comment about it in a previous post. (And on top, there were discussions on the forum about "with ... as X do ")

I am aware that for you, the look up, due to the position in the "grid/table" is sufficient. And I stated that for small samples that is fine. But eventually it scrolls of the screen.
And even on screen, at a certain distance it becomes harder to lookup.

Not to mention the fun...
Code: Pascal  [Select][+][-]
  1. evalute enum also enum2 also enum3
followed by 20 or more lines "when"
=> and all the lines are formatted for enum identifiers up to 15 chars, when a new enum value is added that is longer.... yeah.

 
Quote

"for in" for ranges, actually is sugar. And drops the information that it is a range/ordinal type.
If a construct prevents a potential error then it isn't sugar, it is practical and valuable because it prevents a possible error.
 
what error does it prevent?
That I write "high() to low()" ? Well yes that it does... :(
But probably there are real error that can be prevented, even though I am not aware....

Almost any change can prevent "some" error. But that does not mean that all such changes are worth even thinking about them.
And also that would mean "syntax sugar" does not exist?

Like "evaluate" can prevent errors, but also introduces new ones (see near top of this reply). So on balance.....

 
Quote
As I said, reading the (lets say) 10th "when" line (with each "when" line before, being followed by a block of code, so maybe 40 to 50 lines down from the "evaluate"), the "also true also false also false also true ...." is really not helping. (if you do not have an photographic memory, to remember the "evaluate" line.
It helps plenty but, it cannot be argued that a 50 line EVALUATE statement requires paying a little more attention than a 12 line EVALUATE.  That is true of any statement but, there is a whole lot less clutter getting in the way with an EVALUATE statement than what is found in the equivalent chain of if/else.  It seems you conveniently ignored that.
 
How is the clutter different (except for assigning local vars on top), if they otherwise are mainly word substitutions (from a readability point)

Note: the checking that all "Also" must be presence, and none can be omited is not relevant when talking about clutter (in terms of readability).

Other than replacing Also with And, each expression is to be prefixed with "localvar =" (or other operator). But when it grows to such length, this is actually helpful.

 
Quote
Well yes its a fine line between sugar and other..... And one that is to an extend biased by subjective opinion.
It's subjective until you create the graph for the two constructs, which clearly shows that the EVALUATE graph is much simpler than that of the if/else chain AND, as previously stated, the EVALUATE makes it evident that the values being tested _cannot_ change in the construct something which the if/else chain cannot guarantee nor makes it visible since it is saddled with having to use local variables.
 
answered above

 
Quote
From what I read on it sofar, the only part that is NOT sugar about it, is that it needs each expression only once, and thereby avoids re-evaluation.
Yes and, that very small detail makes a BIG difference.
 
Agreed, but already exists in todays Pascal / FPC. So no new statement needed.

As for the need of of "const local var" (one time only assignment...) that depends on the question if only one "when" can be entered, or if several can....

 
Quote

However:
- without giving a name (as reference) to the result of each expression, this is actually introducing problems (its ok for small samples, but not for bigger cases)
What problems does it introduce ?... name them or show an example AND it must be a problem that is _not_ present when using if/else.
 
That on bigger "when" lists, arguments to "when/also" can be mixed up in order. See above

 
Quote

- The same effect can be done with local vars.
I never said the logical construct cannot be expressed in Pascal.  What I do say is, the resulting construct is noticeably inferior in readability and maintainability than the equivalent EVALUATE statement.
 
It seems we have a very different view of readability.

I could see some readability improvements for some code with a different evaluate
Code: Pascal  [Select][+][-]
  1. evalute foo(x) as cnt also b as b also c=d as CeqD
So that the when statements will then refer to each value by name....

 
Quote
https://github.com/Apress/beg-cobol-for-programmers/blob/master/978-1-4302-6253-4_Coughlan_Ch05/Listing5-9.cbl
I appreciate your looking it up.  I won't say anything about it being "short" or otherwise but, it is a lot clearer than the equivalent in Pascal.
That's not bad at all.   The same construct using if/else chains would probably result in your being blind thus requiring a white cane and a seeing dog.  Your optometrist would be _very_ unhappy.
 
Comes down to the missing names. See just above this quote.

Local vars, is what currently exists in pascal, if you make this "evaluate ... as ..." then its ok...

Of course then you could instead introduce an extended "with do" (this is no real code, the alias names are crap, but it illustrates what I have in mind)
Code: Pascal  [Select][+][-]
  1. with foo(x) as cnt , b as b , c=d as CeqD do  // aliases would have to be read only, so they cannot be changed
  2.   if (cnt = 1)  and (b = 1) and (CeqD = true) then  
  3.       ....
  4.   else if (cnt = 2)  and (b = 1) and (CeqD = true) then
  5.        ....
  6.   else if (cnt = 1)  and (b = 2) and (CeqD = true) then
  7.        ....
  8.   else if (cnt = 1)  and (b = 1) and (CeqD = false) then
  9.        ....
  10.  
given proper matrix formatting, it works the same
- readable (really just diff keywords, same sentence structure, same formatting, same grid.....)
- the alias names are present in the modified evaluate too
- rows can be counted tooo
- only evaluated once
- alias can not be assigned new values

Not sure if I want to promote "with" but diff story

 
Quote
Reading it, on each line I go: "21 throu 99" of what?
Of Qty of course.  Expression in first column applies to the item in the first column.
 
I am aware. But I find it more readable if the entire comparison is in one place.
 
Quote
The statement takes the expression "Qty = 21 throu 99", tears it appart, puts half of it in one line, and the other half somewhere else....
Maybe it's your browser that's doing that.  When I look at it, everything is perfectly aligned.  Like this (added asterisks to make the logical groups even more visible)
 
No, aliment was perfect.
I am just used to (from my childhood on) to read from left to right, then a bit down back to start of line,  and from left to right..... (same as my epson p60 matrix printer)

Reading, a bit to the right, far up a bit back left, then a bit to the right, far down, a further bit to the right .....
Just not readability.....



Anyway one or two points to you....

I do stay with my statement that it needs "as" => "evaluate foo(x) as fx also ..."

Based on that (if you disagree with the above line, the below is void for you too):

I also keep to "if else if" can be exactly as readable (given the exact same formatting, it is mainly word substitution).
But it introduces "local vars" which may not be desirable.

Then that leaves a choice between "extended WITH" or "evaluate". The former can be used for other stuff too, therefore more flexible.

« Last Edit: November 25, 2019, 01:46:05 am by Martin_fr »

440bx

  • Hero Member
  • *****
  • Posts: 5010
Re: Re: language improvement suggestions (the spin off)
« Reply #21 on: November 25, 2019, 09:57:54 am »
You offered some interesting ideas in your previous post :)  and talking about long posts, this one is quite a bit longer than I thought it would be.

- in "if" you can drop a column
- in "evaluate" you can swap two columns
  (swapping in if is possible, but does not do damage, as the order of pre-evaluated arguments in chained "and" does not affect the result)
While it is possible to swap two columns by mistake in the WHEN clause of an EVALUATE statement, that is extremely unlikely to happen since the EVALUATE at the top (presuming it's visible) provides continuous visual feedback of which expression is evaluated.   It is only possible to claim that the swapping causes no harm in an "if" only when local variables (which shouldn't be necessary) are used.  Also, even in the mostly rare case of a very long series of WHEN clauses that causes the EVALUATE statement to no longer be visible, the ordering of the elements in the WHEN clauses immediately above it (which are obviously visible) provide at least some clue (due to data type and/or range) as to what is being compared. 

The variables make no diff. In fact a/some compiler may internally create them for an "evaluate"
The additional variables make a significant difference, the reason is because, if the compiler creates them, the burden is on the compiler to ensure they are used as they should be.  As far as the programmer is concerned they don't exist and he/she doesn't have to ensure they are used as they should be.

On the other hand, it makes it (by far) less likely, that in subsequent names 2 columns are switched by accident. (Especially if there are more "also" involved.
Less likely, yes but, not impossible in the sequence of if/else since they are repeated.  Using the EVALUATE it simply isn't possible because their position occurs only _once_, since they aren't repeated they cannot be misplaced anywhere else.
Your answer does not seem to match my statement.
Just because "evaluate enforces the number of "also" does not mean, they can not be mis-placed.
It doesn't match your statement in all cases but, it does match it when the data types of successive columns are different, in that case, inadvertently swapping columns would result in the compiler issuing a type mismatch.   If/else chains are much more susceptible to that problem because there is no specific column arrangement nor data type associated with the order of comparisons.

If I want to write:
Code: Pascal  [Select][+][-]
  1. evaluate cnt also max also min also avg
  2. when 1 also 2 also 3 also 4
It can by accident happen that I write
Code: Pascal  [Select][+][-]
  1. when 1 also 3 also 2 also 4
Yes, when the data types of consecutive columns are the same, it is possible to make that mistake.  However, it is a very unlikely mistake because the EVALUATE clause at the top is a constant visual reminder of what is being compared with what.  if/else chains don't have that visual reminder.

It matters with growing amount of combinations. But then you easily get 10 or 20 "when", and each has some code attached to it. So the "evaluate" may well be off screen.

If the evaluate is off screen, then it needs to be something like (and cnt,max,min are pre-evaluated:
Code: Pascal  [Select][+][-]
  1. when cnt=1 also min=2 also max=3 also avg4
[/code]
You have a point there.  Personally, in a situation where all the WHEN clauses exceed one screen full, I'd copy the EVALUATE clause as a comment before all the space is consumed on the screen.  That way I don't lose my guide.  Anyone using a chain of if/else would do well in _creating_ a comment line to serve as guide since, if/else won't take less space than a WHEN clause.

Code: Pascal  [Select][+][-]
  1. case a of ....
also splits the expression, having the first half of it in the "case" line, and then a number of possible 2nd parts for each block.
But it is easier to stick that together, since it is only one expression that is ripped... that needs to be kept in mind.

"evaluate" can split any amount of expressions. That is not a good idea to me.
I'm probably not understanding what you mean.  Neither the EVALUATE nor the WHEN clauses force a split anywhere.  If what you have in mind is the rather poorly formatted EVALUATE statement you linked to in your previous post, I agreed with you that it was rather poorly formatted.

My quote was still on "when 1 also 2" could accidentally be "when 2 also 2". That is all columns, and all rows are present. But they have incorrect values.
Possible but not very likely to occur since the EVALUATE clause serves as a constant visual guide.  It seems to me that the problem you mention there is much more likely to occur when using if/else chains since there is no visual guide.

That is if 2 boolean are evaluate, there should be 4 "when". But the same there should be "4 if". No difference there.
I mostly agree but, what you just said there presumes that all the if/then/else conditions are vertically aligned.  I cannot think even of one instance, excluding the example you presented in this thread, of a programmer vertically aligning the conditions used.  Most occurrences of nested if/then/else I've seen look more like "binary roadkill" than anything else.

The possibility of missing a column in one of the conditions was covered above (pro and con on both sides).
For this point therefore the comparison is only about missing an entire "when" or missing an entire "if". Both can be counted the same way.
True but, more likely to be difficult to establish when using nested if/then/else due to poor formatting (conditions not vertically aligned.)  This is in stark contrast with the formatting of case statements (which is basically a restricted form of "evaluate") where it is extremely common to see all the conditions vertically aligned (as they should be.)

Also counting that way is only for boolean or enum. "Evaluate" can also match integers. Then you do not know how many "when" there must be.
The following applies to both, EVALUATE and if/then/else chains, it should always be possible to determine the number of WHEN clauses and "if" statements since even in the case of integers the programmer should know the number of ranges he/she has to contend with. 

* Eval: I may write "when 2 also 1" where I meant to write "..1 .. 2"
Possible but, as previously stated, very unlikely since the EVALUATE statement present at the top serves as a constant reminder of what is being matched with what.

Well, I can switch "if (min=1) and (max=2)" to "if (min = 2) and (max=1)" => but that is no immediate problem.
I don't see how you can claim that.  Inverting the values that should be used for min and max is rather likely to cause a problem.

Switching it to "if (min=2) and (mag=1)" is far far less likely using "if with locals" than using "evaluate". It is more likely to go wrong with eval., because in eval when I type "1" I have no close-by visual reference what it is compared too. (Yes if the "evaluate line is right above, but that is for the first "when" only.)
The EVALUATE at the top is always used as reference thereby making that kind of mistake rather unlikely, though, realistically speaking it is possible.  Seems much more likely to inadvertently occur in if/then/else chains when the variables don't clearly indicate what the relative range between the variables is, unlike with variables named "min" and "max" which do provide a clue but, that is far from always being the case.

If only one "if" is entered, then modifications to the vars do not matter. The other "else if" will never be tested, due to the "else"
Only because you're using local vars, otherwise it would matter.

If evaluate can enter more than one "when", then point to you.
Yes, you can.  That's another nice feature of the EVALUATE statement, consecutive WHEN clauses are cumulative acting the same way as comma separate constants in a Pascal case statement.


If I use "if else if else if" in an "evaluate" manner, of course I have to format it the same way. And that is a feature that is available...
You havent seen this with "if", well that is not a request for a new feature, but for educating people.
The only reasonable conclusion is that quite a few people are difficult to educate because, while most "case" statements are reasonably well formatted, the formatting of nested if/then/else statements often goes from poor to downright dismal.

Or shall I read this statement as "the (supposed) readability of evaluate, is actually not coming from the evaluate statement, but from the code formating people have adapted"?
There is some of that.  Just as in Pascal, most "case" statements are reasonably well formatted while nested if/then/else are a different story altogether.  That said, the power of the EVALUATE statement does not depend on the way it's formatted but, I openly admit, it's readability does depend on proper formatting (as is the case with any statement in just about any language.)


2) instead of "1 also 2 also 3 also 4" you get "(cnt = 1)   and   (min = 2)   and   (max = 3) and (avg = 4)". So you do not constantly need to scroll to the "evaluate" line. IMHO better.
The problem with that is since the variable name is repeated, it is possible to use the wrong variable.  I consider that a problem.

btw, there is an editor macro for aligning things (on wiki pascal script macros). Not powerful enough for this, but a start.
My editor has a macro that aligns things perfectly, its programmer... good editor! :)

Ok, I wasn't clear enough. Having names for expression, to which you later refer again.
And yes, I am aware of "with .. do", and I made my comment about it in a previous post. (And on top, there were discussions on the forum about "with ... as X do ")
This is totally besides the point being addressed in this thread and post but, just as a comment, I find the "bad rep" the "with" statement has to be a bit surprising. 

And even on screen, at a certain distance it becomes harder to lookup.
As long as it is present on the screen, it's not hard.  Once it's about to go off screen, it's time to make a copy as a comment to use for the next batch of "WHEN" clauses.


Code: Pascal  [Select][+][-]
  1. evalute enum also enum2 also enum3
followed by 20 or more lines "when"
=> and all the lines are formatted for enum identifiers up to 15 chars, when a new enum value is added that is longer.... yeah.
There is a simple solution for long expressions in the ALSO clauses, simply stack them as a staircase - not a column, like that horrible example you linked to did - and vertically align the ALSO clauses as usual.  The result is a nice table where the "header" (made of "also"s) is multiline which is not uncommon in tables.  That said, since Pascal is free format, all the ALSO(s) could be on a single line (though it could be a long one.)  That reminded me of writing that PEDUMP program, some of the names and data types used in the PE specification are rather long.

(if you do not have an photographic memory, to remember the "evaluate" line.
I don't need a photographic memory.  The EVALUATE is usually right there on the screen and, in the rare case it may go off screen, I copy it in a comment.  Problem solved, I can use my digital camera for things I can't copy/comment.

How is the clutter different (except for assigning local vars on top), if they otherwise are mainly word substitutions (from a readability point)
For one thing, the nested if/then/else construct requires three (3) words, "If", "then", "else", instead of just one "when".  That's clutter.

Note: the checking that all "Also" must be presence, and none can be omited is not relevant when talking about clutter (in terms of readability).
which is why I didn't count the necessary "and"s for nested if/then/else as clutter.

From what I read on it sofar, the only part that is NOT sugar about it, is that it needs each expression only once, and thereby avoids re-evaluation.
Yes and, that very small detail makes a BIG difference.
 
Agreed, but already exists in todays Pascal / FPC. So no new statement needed.
Except that a new statement, such as evaluate, would not require unnecessary local variables, it would be easier to read (unlike an  if/then/else chain, it's a linear table) _and_ the compiler could generate better code for it.  I'll mention another reason further down.


That on bigger "when" lists, arguments to "when/also" can be mixed up in order. See above
I have to acknowledge the possibility (again) but, again, I'll point out that's rather unlikely because the EVALUATE clause serves as a reminder of the target comparison for each column.  Granted, this presumes that the statement is "rationally" formatted.

It seems we have a very different view of readability.
It would appear to be that way but, I suspect that really isn't the case.  I'll explain after responding to your comments.

I could see some readability improvements for some code with a different evaluate
Code: Pascal  [Select][+][-]
  1. evalute foo(x) as cnt also b as b also c=d as CeqD
So that the when statements will then refer to each value by name....
I suspect you "borrowed" that from SQL.  While SQL _needs_ aliases to refer to previous expressions an EVALUATE statement does not, therefore it is unnecessary therefore it is undesirable clutter but, it is an interesting idea.

I am aware. But I find it more readable if the entire comparison is in one place.
But that requires restating the name of every variable/expression in every "when" clause, database theory makes it clear that is an undesirable thing and shows why too.


I am just used to (from my childhood on) to read from left to right, then a bit down back to start of line,  and from left to right..... (same as my epson p60 matrix printer)

Reading, a bit to the right, far up a bit back left, then a bit to the right, far down, a further bit to the right .....
Just not readability.....
That's the way that most people read normal text but, many people read tables by matching rows and columns and find it very convenient.  Maybe there should be a greater emphasis on teaching children to read tables. ;)




The discussion above got way more complicated than it actually needs to be.  Time to simplify.

When people are faced with testing a variable against a known and discrete set of values, they use a "case" statement.  They don't use nested if/then/else.  I can already hear you replying that the reason is because the "case" statement offers better performance in that case (which is true) but, that isn't the reason.  The reason is because it is much easier to read a linear table of values - which is what a case statement is - than a bunch of nested if/then/else(s).

If what I just stated above was not true then there would have been no reason to enhance the "case" statement to compare against strings since that can obviously be done with nested if/then/else(s).

Knowledgeable FPC programmers who are not concerned with Delphi compatibility will chose to use a "case" when comparing against string constants instead of nested if/then/else(s) because that construct is inherently easier to read, understand and maintain, it is simply a table and it is visually identifiable as a table (an important feature.)  That cannot be said about nested if/then/else(s).

To make that visually evident, the next post includes the graphs of both, the EVALUATE statement and that of nested if/then/else(s).  In a separate post because the forum software complained about the size of the post exceeding the maximum.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

440bx

  • Hero Member
  • *****
  • Posts: 5010
Re: Re: language improvement suggestions (the spin off)
« Reply #22 on: November 25, 2019, 09:58:10 am »
Continued from previous post....

Here is the graph of an EVALUATE statement:
Quote
            WHEN statements
    V
    |     __________________      |
    |____|                  |_____|
    |    |__________________|     |
    |                             |
    |     __________________      |
    |____|                  |_____|
    |    |__________________|     |
    |                             |
    |     __________________      |
    |____|                  |_____|
    |    |__________________|     |
    |                             |
    |     __________________      |
    |____|                  |_____|
    |    |__________________|     |
    |                             |
    |     __________________      |
    |____|                  |_____|
    |    |__________________|     |
    |                             |
    |     __________________      |
    |____|                  |_____|
         |__________________|     |
                                  |
                                  |
                                  V

and here is the graph of just two (2) nested if/then/else(s), that is only 4 cases:
Quote

    only 4 cases because the graph gets unwieldy
    V            IF
    |     __________________
    |____|                  |______________________________________________________________________________________
         |__________________|  |                                                                                   |
                               |          ELSE                                                                     |
                               |     __________________                                                            |
                               |____|                  |___________________________________________________________|
                                    |__________________|  |                                                        |
                                                          |              IF                                        |
                                                          |     __________________                                 |
                                                          |____|                  |________________________________|
                                                               |__________________|  |                             |
                                                                                     |             ELSE            |
                                                                                     |     __________________      |
                                                                                     |____|                  |_____|
                                                                                          |__________________|     |
                                                                                                                   |
                                                                                                                   V

It should be evident that the first graph is inherently simpler than the second one.

ETA:

The if/then/else graph is too long horizontally and wraps around.  It's even too convoluted for the forum software to display it properly ;)


« Last Edit: November 25, 2019, 10:32:04 am by 440bx »
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 12050
  • FPC developer.
Re: Re: language improvement suggestions (the spin off)
« Reply #23 on: November 25, 2019, 10:37:54 am »
I can see the release manifest for that release

- NOW WITH NEW COBOL FEATURES !  ;) ;D

That will win us the hearts of new programmers.  >:D

Thaddy

  • Hero Member
  • *****
  • Posts: 16580
  • Kallstadt seems a good place to evict Trump to.
Re: Re: language improvement suggestions (the spin off)
« Reply #24 on: November 25, 2019, 10:43:59 am »
One of the first languages (the third after Fortran and Basic) I learned, was Forth:
I would like a{$modeswitch reversenotation}

That will shake things up a bit...
Also, I would like to see enforced escapes for non-printable characters: #13#10 bothers me: ^M^J is much more elegant.
« Last Edit: November 25, 2019, 10:49:53 am by Thaddy »
But I am sure they don't want the Trumps back...

440bx

  • Hero Member
  • *****
  • Posts: 5010
Re: Re: language improvement suggestions (the spin off)
« Reply #25 on: November 25, 2019, 11:06:56 am »
I can see the release manifest for that release

- NOW WITH NEW COBOL FEATURES !  ;) ;D
I sure got a good laugh out of that one  :D

That will win us the hearts of new programmers.  >:D
It's really unfortunate that COBOL is many programmers' wiping boy.  That language has a lot of really great features.  EVALUATE is one of them, it runs rings around Pascal's case statement and C's switch statement and, that is far from the only feature "lowly" COBOL has over Pascal and C.  COBOL is way underappreciated and, the majority of programmers who deride it, simply don't know the language well enough to evaluate it properly.

That said, I do agree that to win the hearts of new programmers, mentioning COBOL is not likely to be a winning formula.  If the EVALUATE statement were to be implemented in Pascal (rest assured, I am fully aware there is no chance of that happening) it would probably be better to present it as "Multivariate conditional branching", more powerful than C's switch, faster than chains of if statements and, able to leap over tall tables in a single statement.    Add a few scantily clad blondes and brunettes and their hearts will be just the beginning ;)

All that said, COBOL does have some rather significant shortcomings (though fewer and fewer in every new standard.)
« Last Edit: November 25, 2019, 11:09:35 am by 440bx »
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Thaddy

  • Hero Member
  • *****
  • Posts: 16580
  • Kallstadt seems a good place to evict Trump to.
Re: Re: language improvement suggestions (the spin off)
« Reply #26 on: November 25, 2019, 11:13:48 am »
(though fewer and fewer in every new standard.)
Well, I agree there: they even dropped "features".
Unlike C++ which has more problematics every new standard.
FreePascal is somewhere in between, but reasonably managed except for the almost enforced Delphi compatibility parts
But I am sure they don't want the Trumps back...

MarkMLl

  • Hero Member
  • *****
  • Posts: 8234
Re: Re: language improvement suggestions (the spin off)
« Reply #27 on: November 25, 2019, 11:29:20 am »
All that said, COBOL does have some rather significant shortcomings (though fewer and fewer in every new standard.)

It's unfortunate that long-term devotees of COBOL (and of FORTRAN etc.) are in the habit of pointing out that it's gained features like structured programming and object support fairly recently as though that fact in some way justifies its original deficiencies.

I've got enormous respect for the designers and implementers of some of the early languages. But what they actually achieved, particularly when compared with ALGOL-60, was at best an unsightly bodge and really should have been pensioned off as soon as people understood how to define elegant and unambiguous syntaxes and implement efficient compilers for them.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Logitech, TopSpeed & FTL Modula-2 on bare metal (Z80, '286 protected mode).
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Rainbow6

  • New Member
  • *
  • Posts: 25
Re: Re: language improvement suggestions (the spin off)
« Reply #28 on: November 25, 2019, 12:14:16 pm »
Wow this is an interesting and long thread. But as a long time COBOL and RPG programmer I have to add my 2ct to the discussion.

Such decision tables (I think we called it like than in the early 90's) are typical business logic for discounts, tariffs and so on. But even in the 90's we transferred most of the business logic into database tables, and every young business programmer was "tarred and feathered" if he or she dared to write such complex tables in code.

So yes, the feature is very sophisticated - and yes, there are some good uses to it - but I wouldn't add it to any modern language.

Just the discount example - who will code such decisions in hard code? The discounts and the selection criteria will get stored in a table, and one simple SQL select will give you the correct discount.

Finally I like to say, I really like COBOL and RPG - such powerful languages for business and database programming - so this is no sentiment against EVALUATE - I just didn't need it in about 25 years of mainframe and midrange programming.

Kind regards,
Daniel

lainz

  • Hero Member
  • *****
  • Posts: 4689
  • Web, Desktop & Android developer
    • https://lainz.github.io/
Re: Re: language improvement suggestions (the spin off)
« Reply #29 on: November 25, 2019, 02:04:04 pm »
Well Pascal is not Kotlin or Cobol anyways  :D
Use the original thing where it matters, and here use Pascal. Else this discussion will never end, points from one side or another never ends if you have enough imagination-

 

TinyPortal © 2005-2018