The stupid question is the question not asked | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Preface: I don't claim neither that I like this kind of programming, nor that I hate it. I would just like to read some opinions I am in charge of writing a small simple application that we will use to update our DNS zones. No pressure, no timelines, no hurry, so I have some time to think about how to make it :-) The application scheme is quite simple:
Does it make sense to build this kind of application in a block-based way, like:
instead of, e.g., creating subroutines and making decisions on which to run? Does the block-based approach make sense at all? Which pro's and con's do you see for each approach? Thanks in advance for your opinions Update after Abigail's post: The pro I see in the block-based style is that it mimics the states graph (???wrong???) of the program; for example, it could be made clear from the source using labeled blocks and redos that once one enters the "EDIT_ZONE" block he could restart it any times he likes, but once he gets out, he'll never come back. On the con side, it seems to me that the source get more structured than it needs this way, and the approach seems unfeasible when the complexity of the states graph grows. Ciao! The very nature of Perl to be like natural language--inconsistant and full of dwim and special cases--makes it impossible to know it all without simply memorizing the documentation (which is not complete or totally correct anyway). In reply to block-based programming... by bronto
|
|