editor spoils program and deletes toplevel when saved and re-loaded
A Logo programming environment for Microsoft Windows
Brought to you by:
david_costanzo
Menu
▾
▴
1 Attachments
#561 editor spoils program and deletes toplevel when saved and re-loaded
Attached please find an example which shows how the FMSLogo main editor opened with EDALL button spoils a program in favour of the workspace. See my "aqdventure story" of it as pdf-file. Please note: I send the short experimental program as a txt-file, because if is was .lgo, a part of it might be eaten up by the workspace-oriented editor before you see it. So you can experiment with it using copy and paste.
While a program consists of a collection of procedures and a top-level part, the related workspace contains procedure definitions, variable assignments and plists. It is clear that
THE WORKSPACE IS NOT THE PROGRAM (though it may be well-formed)
THE PROGRAM IS NOT THE WORKSPACE
though they have the procedure definitions in common, which have an alphabetical order in the workspace and the order of appearance in the program.
For program development the workspace may be a helpful reference sometimes, but it cannot replace a proper program listing. Especially the variable assignments and property lists should not be visible in the program listing which they clutter and spoil, especially because they overwrite the original top-level.
The questionm is, why this conflict didn't arise before. The reason may be that
-
when kids play around with the turtle they do most of the top-level-work with the commander and can find the procedure definitions (perhaps made with the mini-editor) still in the workspace.
-
when advanced users develop a program, they use either an external editor like Notepad++ which works together very well with the remaining FMSLogo infrastructure.
-
when users who like to stick to the internal FMSLogo-editor develop an advanced program, they use no top-level at all and pack the initial management in some kind of main procedure which they call from the commander. But they have always to erase the upcoming variable assignments and their rare plists when updating their program.
All this locks Logo into the area of playful pre-forms of software development, such as the ornamental recursive turtle applications and small games, but keeps it away from advanced software development techniques.
If we succeed in giving FMSLogo an independent IDE for program development (independent of the workspace), the otherwise powerful language can become one of the leading programming languages not only for children, but also for adolescents, young adults and hobbyists. The versatile FMS logo can lead to professional techniques in other areas of software development (including front-end, middleware and back-end programming) and enable professional activities in the offline area.
Along the way, David refined a suggestion of mine that would enable an acceptable workaround. This is possible because FMSLogo has long since contained the basis and requirements for this.
If we continue to make progress on this path, pbreport can use its means and possibilities to develop and effectively disseminate teachware and curricula for it.
Sorry - 2 attachments missing in my former post- here they are.
And here comes the most important attachment -
I was in too much of a hurry