A user on Foxite posted this response. Here is my reply:
----- > > I am creating a new structured flow control mechanism for Visual FreePro. > > I had originally wanted to call it "flow controller" or FLOWER for short, > > but my wife said it was too "girly" and that nobody would take me seriously. > > :-) So, I've changed the name to ROPE..ENDROPE.
Note: After speaking with several developers, and hearing one similar comment on UniversalThread, I have since changed it back to FLOWER. :-) For the sake of explanation I will refer to it in this reply as ROPE..ENDROPE.
> You appear to be promoting having the option to go back to GO TO type coding.
Thank you for your reply, Paul. I wanted to convey my thinking regarding your comments.
I think that this new feature is not the same as the GO TO command for a few reasons. However, know also that Visual FreePro also supports the GOTO command using the syntax:
lnI = 0DOWHILE lnI < 20
GOTOLABELname * This line of code will never be executed:
lnI = lnI + 1ENDDO
:LABELname* Code execution continues here
----- Specifically, in the case of the ROPE..ENDROPE block, the SWING TO command moves to a particular location which continues forward until it reaches the ENDROPE command, or until the start of another PLATFORM definition, at which points it will automatically exit the ROPE..ENDROPE block and continue thereafter. In that way, it is like calling a function, where flow control goes to a new, known location (which contains its own parameters, return variables, and discrete code), yet without returning afterward.
In addition, the SWING command operates only within the ROPE..ENDROPE block, thereby allowing a finite area of code which must be examined by the developer to determine flow patterns. And to aid in this, Visual FreePro provides within its IDE mechanisms to highlight information about the flow in graphical ways, which also makes them more easily visualized.
I consider that we (mankind in general, but software developers specifically) are not moving toward text-based forms, nor will we maintain text-only forms of computing. At the very least those text-based forms will be augmented in a visual wrapper, something that utilizes the other portions of our brains not related to interpreting text, but rather to identifying groups, patterns, colors, sizes, etc. In fact, while the text-only form must exist (for therein we convey the mechanical rules of syntax expression), that text form represents only the mechanics of the operation, and not its use, design, or even applied expression. A lengthy set of text-based commands can create a visual form with graphics and interaction which makes it possible to achieve, through text, "wielded things". It should be the same in our source code.
In the future (as with Visual FreePro and ultimately other tools as well), it will be an IDE refactoring of that text-only form, changing it into something human beings can more easily manipulate (than raw source code which), and it will be these kind of presentation mechanisms that will begin to dominate -- and it is toward that end I am moving.
I do not want to write code just by writing commands -- a most limiting aspect when you have a complex expression to convey rapidly. Instead, I want to design systems, and then come in behind and fill in the blanks with requisites. This will require a different way to write code, and one which conveys both the mechanics of the language, and the visual representation of the language, yet in similar ways.
As such, the Visual FreePro IDE will pull these seemingly disparate items together and present them in a very similar way (in time, and as per the design I have in my mind) to where the developer is elevated to something like an orchestral conductor, guiding the many instrument sections so as to bring out their fullness, their richness.
And one other thought ... this is all new to everybody, myself included. I have a vivid picture in my mind of how this operates, yet I also think there is much which I must demonstrate in final form before many of the ideas I espouse will be seen to have any merit, and before it is realized what I am trying to do here with Visual FreePro's design.
> IMO that would be a backward step. Obviously you are adding this as an option > so it wouldn't be imperative to use those structures but the problem with GO TO > type structures is that it allowed coders to be lazy and messy and easily write > spaghetti code without realising it and that's why a lot of languages were > subsequently developed without those kind of structures.
As I believe it is wrong to mandate "m." prefix usage on every non-assignment memory variable reference throughout an entire application because some developers may not adhere to a proper naming convention, or to categorically banish the use of PUBLIC variables because some developers might use them badly, I believe it is also wrong to tie a good developer's hands and prevent them from using any mechanical feature which may exist to create elegant code simply because there are some who may use them improperly.
----- We should not design for the limitations of the foolish and ignorant, but rather we should provide what's possible, giving everyone the opportunity to achieve by looking to those who are in the position of being teachers. This of course also mandates that those people who are in the position of being teachers actually teach, and that those who are in the position of needing learning do actually offer themselves up for learning. But again, this is true in all things.
> Obviously it's your language and your choice what you do with it but I'd rather > not use a language where other coders in the team were able to write code in a > GO TO style.
What I offer will be available should you choose to try or use it. If not, no hard feelings.
