is it a good idea to use Goto statement?

[bd139]

 Or a catch block 

[hamster_nz]

We all know where this leads:

https://medium.com/swlh/stop-using-if-else-statements-f4d2323e6e4

You’ve watched countless tutorials using If-Else statements. You’ve probably also read programming books promoting the use of If-Else as the de facto branching technique.

It’s perhaps even your default mode to use If-Else. But, let’s put an end to that right now, by replacing If-Else with the state objects.

 

[SilverSolder]

We all know where this leads:

https://medium.com/swlh/stop-using-if-else-statements-f4d2323e6e4

You’ve watched countless tutorials using If-Else statements. You’ve probably also read programming books promoting the use of If-Else as the de facto branching technique.

It’s perhaps even your default mode to use If-Else. But, let’s put an end to that right now, by replacing If-Else with the state objects.

 

That is going a little too far for my liking - the solution is even more complex than the problem! 

That whole If-Else mess used as an example in the article could be made much cleaner and maintainable...

[tggzzz]

We all know where this leads:

https://medium.com/swlh/stop-using-if-else-statements-f4d2323e6e4

You’ve watched countless tutorials using If-Else statements. You’ve probably also read programming books promoting the use of If-Else as the de facto branching technique.

It’s perhaps even your default mode to use If-Else. But, let’s put an end to that right now, by replacing If-Else with the state objects.

 

That is going a little too far for my liking - the solution is even more complex than the problem! 

That whole If-Else mess used as an example in the article could be made much cleaner and maintainable...

Let's be clear; this is w.r.t. FSMs.

For tiny FSMs with a couple of states and a couple of events, it is fine. But many FSMs aren't like that.

Frequently FSMs start out small and, as corner conditions are discovered and requirements added, they end up large. At that point it is an unmaintainable mess. I've seen them end up as 10 deep if-then-else messes. Long before then, when a bug is found, it is impossible to determine how to change the code so as to fix the bug and not introduce another bug. That mess took down a company!

With a little extra work up (i.e. using the standard GoF State Machine Design Pattern) front you have something that allows easy logging, tracing, "fixability", extendability - and visible correspondence between design specification and implementation.

Those attributes are superb when integrating your component with other company's components - they enable you to definitively point the finger at them or at the line in your code that needs fixing. (The logging enables a very fast compact mechanism for retaining the "state trajectory" to find out why something failed in an installed system.)

Those attributes are superb when performance testing your component with other company's components - point the finger at them.

All in all a great way of deflecting flak and avoiding the use of lawyers

[nctnico]

I agree. If you need to nest if-thens more than 4 deep then a switch-case is better.

[tggzzz]

I agree. If you need to nest if-thens more than 4 deep then a switch-case is better.

Well, I'm not sure that switches are superior in that context. A switch statement might directly replace
    if ( state == 1 ) {

    } else if (state == 2 ) {

    } else if (state == 3 ) {

    } //etc
but I don't regard that as being nested in the destructive ways that I have seen.

I was thinking more of
    if ( state == ) {
        if ( inputA == ) {
            if (inputB == && inputC == ) {
                if (inputD == ) {

                if (inputE  == ) {

                }
            }
            if (inputE  == ) {

            }
        }
    } else if (state == ) {

    }

plus other peversions carried out to the 10th level!

Yes, I refused to look at it in detail, let alone consider modifying it. There was zero chance of spotting the line that needed to be modified to implement one use-case, while ensuring that it didn't affect other use-cases.

No, it wasn't remotely sensible, but that's the kind of thing that accretes over the years. Cancerous.

Any design pattern can be implemented badly, but at the GoF Class-per-State Pattern can neatly and directly implemented FSMs with nested states.
(Shortform features including: one abstract superstate for operation, another abstract superstate for faults, and concrete substates within a superstate for the normal operation FSM, catch all error events occurring in any substate causing a transition to the fault state, etc)

[bd139]

Or screw it all and do what I did and write a DSL and compiler for defining the state machine that generates an entire-machine interface contract and state chart and generating an optimised pattern matching based switch in a loop with transition validation which can be suspended and serialised between states safely  .

[tggzzz]

Or screw it all and do what I did and write a DSL and compiler for defining the state machine that generates an entire-machine interface contract and state chart and generating an optimised pattern matching based switch in a loop with transition validation which can be suspended and serialised between states safely  .

Did anybody else[1] ever have to look at the application written in your DSL?

Every home-grown[2] DSL I've seen ended up as an incomprehensible mess. Exactly like the DSL the FSM I referred to above, and, come to think of it, much like C++ and Perl

In my experience in almost all cases a DSLanguage was worse that a corresponding DSLibrary in a standard language. Start by considering tooling, staff training, staff retention...

[1] including yourself 12 months later
[2] I perpetrated one once, long ago; the saving grace was that it was a 2 week project and was thrown away after that. I learned my lesson, and realised Forth would have been a better starting point.

[Syntax Error]

We all know where this leads:

https://medium.com/swlh/stop-using-if-else-statements-f4d2323e6e4

So the guy's argument is that if-else makes for messy and unreadable code, okay, so instead he introduces a 'design pattern' which is a mash of internal, abstract, static and overridden classes? Hmmmm, he's obviously twigged he's the only contractor in the corporation who can figure out this over-complicated codebase.

I wonder how these gurus would deal with branching in assembler? which is if-true-jump-else-dont

[tggzzz]

We all know where this leads:

https://medium.com/swlh/stop-using-if-else-statements-f4d2323e6e4

So the guy's argument is that if-else makes for messy and unreadable code, okay, so instead he introduces a 'design pattern' which is a mash of internal, abstract, static and overridden classes? Hmmmm, he's obviously twigged he's the only contractor in the corporation who can figure out this over-complicated codebase.

I wonder how these gurus would deal with branching in assembler? which is if-true-jump-else-dont

It is a standard design pattern that is well known and understood by those skilled in the art.

I first saw it in 1987 (gulp, 33 years ago), and it became widely known after the GoF book appeared in 1994 - over quarter of a century ago. As is traditional with design patterns, the GoF were careful to state its advantages, where it was applicable, and where there are better alternatives.

I have used it to good effect, especially when compared with the absolutely horrific if-then-else mess in the previous product.

Now if an amateur uses it where not beneficial, or doesn't use it where beneficial, that can hardly be said to be a fault of the design pattern.

[SilverSolder]

The example "mess" would respond somewhat to a Case statement - e.g.

Code: [Select]

case orderState of
isPending : ...
isExpired : ...
isCancelled : ...
end;


[tggzzz]

The example "mess" would respond somewhat to a Case statement - e.g.

Code: [Select]

case orderState of
isPending : ...
isExpired : ...
isCancelled : ...
end;


As I stated earlier in this thread, that technique is perfectly suitable for small FSMs, especially those that won't have to be modified/extended over the years. I've used it myself.

The example is, of course, a deliberately simple example chosen so that the general principles can be rapidly and easily understood. For teaching and exposition purposes, it would be counterproductive to have long complex example! (The solution is important, not the problem)

For similar reasons, when I've been interviewing people I've sometimes asked them how they might design a traffic lights controller for a child's toy set. I chose that example because it is so simple that I don't have to explain what that is. That leaves precious time for finding out how they approach problems.

[bd139]

Or screw it all and do what I did and write a DSL and compiler for defining the state machine that generates an entire-machine interface contract and state chart and generating an optimised pattern matching based switch in a loop with transition validation which can be suspended and serialised between states safely  .

Did anybody else[1] ever have to look at the application written in your DSL?

Every home-grown[2] DSL I've seen ended up as an incomprehensible mess. Exactly like the DSL the FSM I referred to above, and, come to think of it, much like C++ and Perl

In my experience in almost all cases a DSLanguage was worse that a corresponding DSLibrary in a standard language. Start by considering tooling, staff training, staff retention...

[1] including yourself 12 months later
[2] I perpetrated one once, long ago; the saving grace was that it was a 2 week project and was thrown away after that. I learned my lesson, and realised Forth would have been a better starting point.

I did consider all of that when I wrote it initially, including the worry of “what hell hath I deposited on the world”. Hell was uneventful, fast and reliable in the end after a few bugs in ReaderWriterLockSlim (Microsoft’s frameworks should never be trusted) were ironed out.

I did make myself a little sick by writing a recursive descent parser in itself that could emit graphviz dot files of the state chart. It worked but I regret it. Mostly because that was the bit I crawled back to after 12 months and nearly sicked down myself.

But yes Forth is a much much better solution. When you grok it, it’s magical. When you don’t though, it’s hell. I went through the latter for quite a while.

[tggzzz]

Or screw it all and do what I did and write a DSL and compiler for defining the state machine that generates an entire-machine interface contract and state chart and generating an optimised pattern matching based switch in a loop with transition validation which can be suspended and serialised between states safely  .

Did anybody else[1] ever have to look at the application written in your DSL?

Every home-grown[2] DSL I've seen ended up as an incomprehensible mess. Exactly like the DSL the FSM I referred to above, and, come to think of it, much like C++ and Perl

In my experience in almost all cases a DSLanguage was worse that a corresponding DSLibrary in a standard language. Start by considering tooling, staff training, staff retention...

[1] including yourself 12 months later
[2] I perpetrated one once, long ago; the saving grace was that it was a 2 week project and was thrown away after that. I learned my lesson, and realised Forth would have been a better starting point.

I did consider all of that when I wrote it initially, including the worry of “what hell hath I deposited on the world”. Hell was uneventful, fast and reliable in the end after a few bugs in ReaderWriterLockSlim (Microsoft’s frameworks should never be trusted) were ironed out.

I did make myself a little sick by writing a recursive descent parser in itself that could emit graphviz dot files of the state chart. It worked but I regret it. Mostly because that was the bit I crawled back to after 12 months and nearly sicked down myself.

But yes Forth is a much much better solution. When you grok it, it’s magical. When you don’t though, it’s hell. I went through the latter for quite a while.

Forth would have been ideal for my application: testing on an 8-bit embedded processor. I managed without, but the usual "how could I have done that better with 20:20 hindsight" brought me to that conclusion about my DSL and Forth. All of the other "little domain specific scripting languages" I've seen since have convinced me I was right Principle: compilation is so damn fast and the tools so good that you migh as well use a proper language. (I suspect the "fast" bit precludes C++ )

At university I promised myself I would never write a compiler nor use a database. I've never regretted that decision. The nearest I came to it was replacing a postgres database with an in-memory distributed key-value store; the keys were a phone number, the values were money (etc).

[SilverSolder]

[...]
At university I promised myself I would never write a compiler nor use a database. I've never regretted that decision.
[...]

For my sins, I've had to learn to program Oracle, with its weird PL/SQL language, in latter years.

You can do unbelievable things like this:

begin
  S:= 'create table TEST as select * from BIG_DATA_TABLE';   --Create a string containing an arbitrary command
  execute immediate S;  --execute the string!
end

Not only that, executing "self modifying code" is the ONLY way some things can be done.  Something about the design of this thing bothers me a lot more than Goto statements! 

[tggzzz]

[...]
At university I promised myself I would never write a compiler nor use a database. I've never regretted that decision.
[...]

For my sins, I've had to learn to program Oracle, with its weird PL/SQL language, in latter years.

You can do unbelievable things like this:

begin
  S:= 'create table TEST as select * from BIG_DATA_TABLE';   --Create a string containing an arbitrary command
  execute immediate S;  --execute the string!
end

Not only that, executing "self modifying code" is the ONLY way some things can be done.  Something about the design of this thing bothers me a lot more than Goto statements! 

"Eval" in any form is liberating (in the short term at least )

But you remind me of my other lapse. I did create a database for an early (award winning!) web business, back in '98/'99. The interesting bit was the extendable, scalable, distributed, fault-resilient manufacturing process that made the orders specified by rows in the database.

[nctnico]

I agree. If you need to nest if-thens more than 4 deep then a switch-case is better.

Well, I'm not sure that switches are superior in that context. A switch statement might directly replace
    if ( state == 1 ) {

    } else if (state == 2 ) {

    } else if (state == 3 ) {

    } //etc
but I don't regard that as being nested in the destructive ways that I have seen.

I was thinking more of
    if ( state == ) {
        if ( inputA == ) {
            if (inputB == && inputC == ) {
                if (inputD == ) {

                if (inputE  == ) {

                }
            }
            if (inputE  == ) {

            }
        }
    } else if (state == ) {

    }

plus other peversions carried out to the 10th level!

Yes, I refused to look at it in detail, let alone consider modifying it. There was zero chance of spotting the line that needed to be modified to implement one use-case, while ensuring that it didn't affect other use-cases.

I was kind of implying that your second example would have to be rewritten in the form of the first using a state-machine design pattern (for which switch/case usually is a good fit). If my code starts to look like your second example I rewrite the code as a state machine. Or if I expect code to turn out like your second example I just go for a state machine approach right away. It always ends with better code.

[SilverSolder]

[...]
At university I promised myself I would never write a compiler nor use a database. I've never regretted that decision.
[...]

For my sins, I've had to learn to program Oracle, with its weird PL/SQL language, in latter years.

You can do unbelievable things like this:

begin
  S:= 'create table TEST as select * from BIG_DATA_TABLE';   --Create a string containing an arbitrary command
  execute immediate S;  --execute the string!
end

Not only that, executing "self modifying code" is the ONLY way some things can be done.  Something about the design of this thing bothers me a lot more than Goto statements! 

"Eval" in any form is liberating (in the short term at least )

...ok, I see your Eval, and raise you nested "Execute Immediate" calls - to any depth!  Can you do that with "Eval" ? 

(I misread "Eval" as "Evil" the first time.  Are you sure it is spelled correctly?   )

But you remind me of my other lapse. I did create a database for an early (award winning!) web business, back in '98/'99. The interesting bit was the extendable, scalable, distributed, fault-resilient manufacturing process that made the orders specified by rows in the database.

Sounds an interesting project!

[tggzzz]

[...]
At university I promised myself I would never write a compiler nor use a database. I've never regretted that decision.
[...]

For my sins, I've had to learn to program Oracle, with its weird PL/SQL language, in latter years.

You can do unbelievable things like this:

begin
  S:= 'create table TEST as select * from BIG_DATA_TABLE';   --Create a string containing an arbitrary command
  execute immediate S;  --execute the string!
end

Not only that, executing "self modifying code" is the ONLY way some things can be done.  Something about the design of this thing bothers me a lot more than Goto statements! 

"Eval" in any form is liberating (in the short term at least )

...ok, I see your Eval, and raise you nested "Execute Immediate" calls - to any depth!  Can you do that with "Eval" ? 

(I misread "Eval" as "Evil" the first time.  Are you sure it is spelled correctly?   )

Eval is the LISP function that evaluates an arbitrary data structure as a LISP programes. So it can do anything a LISP programes can do!

It is the heart of the REPL constructions you see in interactive environments such as interpreters and shells and... REPL is read evaluate print loop. https://en.m.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop

But you remind me of my other lapse. I did create a database for an early (award winning!) web business, back in '98/'99. The interesting bit was the extendable, scalable, distributed, fault-resilient manufacturing process that made the orders specified by rows in the database.

Sounds an interesting project!

It was. Many of mine have been; there has been little repetition

[Syntax Error]

eval (
repeat { Eat( );
               Sleep( );
               Rave( )  };
);

[bd139]

Eval is the root of all untrusted execution.

[magic]

PHP include comes close second

[tggzzz]

Eval is the root of all untrusted execution.

... Such as a von Neumann machine which doesn't have a capability as architecture. I hesitate to mention the Burroughs/Unisys machine architecture, which keeps tight control of the compiler and debugger