Re: First Free Format

Jim Langston wrote:
> Personally, I found the C style switch statement kinda limiting, with the 
>Pascal/RPG giving me a lot more leeway.

It's been a while since I've programmed in Pascal (I lived and
breathed Pascal in school!), but isn't Pascal's case statement like
C's switch, in that cases must have distinct tags?

> A lot easier to say:
> Select
> When CondA = '1' And CondB = 2
>   ... do this...
> etc..
>
> Then have to code:
> Switch CondA
> Case '1':
>    If CondB = 2
>       ... do something...
> etc...
>
> The first, IMO, is easer to understand.

It all depends.  If you're selecting a code branch based on the
value of one variable, then things are easy:

if x==1:
    handle_first_case()
elseif x==2:
    handle_second_case()
elseif x==3:
    handle_third_case()
etc.

But if you're handling cases based on multiple variables with
multiple possible values each, then things get a little more
complicated.  Then, you have potentially m x n cases to handle. How
you structure the code depends very much on what cases are to be
handled by each combination of values.  In many cases, nested if
statements may well be easier to code and clearer to read.

Looking at your particular code fragments, I know from my own
experience that the first style of coding is very often tricky to
read since it's not quite as clear what the distinct variations are,
and how they relate to the variables being tested.  Your latter
example makes the variations easier to see.  Plus, the latter style
can make maintenance easier when a subsidiary variable gets a new
value added to its domain.

>
> You are right, though, I think that compiler design decisions are not as much 
>influenced by speed of execution but by becoming as high level as possible.  
>Everyone knows (or should) that Objects are no wear near optimized for speed.

Indeed!  In fact, look at the rise in popularity of interpreted
languages.  The fact that a program is interpreted is nowhere near
the bottleneck it once was. Even in apps coded in interpreted
languages, the bottleneck is often the database, or network
latencies.  These days, the priority is (or should be) designing
components that can easily be reused in the hopes of improving
programmer productivity.

Cheers! Hans