in reply to block-based programming...

I'm of two (or more) minds about this. Firstly, this is not some radical new style. This is a form of imperative programming without subroutines, similar to some older languages (like Apple Basic and the like). You are, essentially, programming with goto.

Now, you did say that this is a small program. In a way, so long as your stuff is well-named and well laid out, it almost doesn't matter what way you program this. Heck, your program seems to be simple enough that, if the hooks were there, you could program this in Parrot! (I don't reccomend it, but it could be interesting ...)

Now, you talk about a state machine. If you think about this being a state machine and you don't use CPAN code, you're (probably) reinventing the wheel. The standard distribution for handling state machines in Perl is POE*. It's a bit of a learning curve, but I would definitely suggest looking there if you consider this a state machine.

As for my feelings on block-driven programming in general ... I guess I would say that it's a neat idea, so long as your codebase remains very very small. This doesn't scale in any meaningful way. *shrugs*

*CGI::Application can be considered as another state machine distribution, but it is both domain-specific to web applications and doesn't really have built-in support.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

Replies are listed 'Best First'.
Re: Re: block-based programming...
by flyingmoose (Priest) on Apr 22, 2004 at 13:20 UTC
    If you think about this being a state machine and you don't use CPAN code, you're (probably) reinventing the wheel. The standard distribution for handling state machines in Perl is POE*.
    But it's big and clunky and doesn't read like normal Perl code. For a simple FSM, there is absolutely no reason to use POE, as POE tends to make your app into a "POE application", transmogrifing it. Reinventing your own will result in something a lot more concise. POE is cool, but it is *much* more than just a state machine, and I really doubt everytime someone recommends it that they have actually used it for that purpose. Implementation of basic state machines WITHOUT goto's is basic CS1, and those that use goto's to do this are doing really shoddy programming.

    Gotos (and their P.C. cousins "abused exceptions") must die. They lead to poorly maintainable code that is both hard to read and trace.

    A simple state machine without gotos (pardon the syntax errors): 

    $state = 'foo'; 
$running = 1;
while($running) {
   if ($state eq 'foo') {
        # do stuff
        $nextstate = 'bar';
   }
   elsif ($state eq 'bar') {
        # do stuff 
        $nextstate = 'baz';
   }
   elsif ($state eq 'baz') {
        # do stuff
        $running = 0;
   }
   $state = $nextstate;
}

    [download]
[reply]
[d/l]
      Gotos (and their P.C. cousins "abused exceptions") must die. They lead to poorly maintainable code that is both hard to read and trace.
      There's no reason they lead to poorly maintainable code. They only lead to poorly maintainable code if they are misused. But it isn't too difficult to write spaghetti code using OO and no gotos - but that isn't a reason to say that OO must die. Perhaps you should read Knuth's paper "Structured programming with Go Tos", where he shows that if used appropriately, use of gotos is fine.

      Quoting from my own work, part of a C program I modified last week: 

        __close1:
    if (close (soc) < 0) {
        if (errno == EINTR) {
            goto __close1;
        }
        perror ("close");
        exit (1);
    }

      [download]
      I don't think this is less maintainable than writing a loop.

      Abigail

[reply]
[d/l]
        Gotos are almost as controversial as what constitutes good OO style. But they shouldn't be, since every construct that can be written with a goto can be written more clearly without one. I definitely agree both gotos and messy OO can obfuscate flow-control, so gotos are not the only evil. Here's how I would have done it: 

        # keep trying to close socket until we succeed
while (close(soc) < 0) {
   if (errno != EINTR) {
      # wasn't interrupted, this is some other failure, bail!
      perror("close"); 
      exit 1;
   }  
}

        [download]

        Your example is certaintly not less maintainble (yet), but this "block based" stuff above is an abomination when higher-level languages have more advanced constructs. That block based idea is fine for assembler or BASIC. Still, use of gotos encourages further use of gotos, and your particular use of goto and if's is logically a loop ... so just use the loop!

[reply]
[d/l]
[reply]
        ...but not his algorithms.

        As it wouldn't be wise to program all with plain sentences, Dijkstra's saying shouldn't be understood as a commandment.

        I see it as an algorithm to provide a good direction on everyone's programs.

        While I could do nearly everything programming in Basic, I could see the wisdom of thinking ahead a little and structuring the code before writting it. I personally saw it like growing up.

        {\('v')/}
        _`(___)' __________________________
[reply]

In Section Meditations