Today let's talk a bit about programming, or rather about the life stages of any program. Fans of "computer pop" can safely skip this section. This time my story will be short, but next time...
As I mentioned during our first meeting ("ОБЕРОН" No1), programmers are not born; it’s a diagnosis after five years of suffering in university. One of the important aspects of training a programmer is instilling the stages that their program MUST go through.
There are eight such stages or life phases of a program.
1. Defining the necessary technical requirements for the system configuration.
At this stage, the technical requirements for the hardware on which the program will operate are determined (usually by the client). If there is no client, the programmer defines these requirements themselves. All further development will be carried out in accordance with them.
For SPECTRUM, when starting the development of your program, you must determine:
- whether a disk drive is necessary for the program to work;
- the version and type of DOS (Is-DOS, TR-DOS, CP/M);
- the minimum memory size for operation: try to fit into 48K, if not, then into 128K, and in the most extreme case, more than 128K, while determining the type of computer with these "more than 128K" (SCORPION, ATM-TURBO, PROFI, or better yet, all at once);
- the presence of a music coprocessor;
- compatibility issues: whether to use the mythical #FD port or the normal #7FFD; whether to use the attribute port #FF (if possible, it’s better to do without it); whether to use a vector table for the 2nd interrupt mode (for operation on all computers), or to set the vector with two bytes (it will only work on computers with a stable data bus).
2. Task formulation.
In theory, this should be done by a task setter (there is such a position at the VЦ), but more and more often it is done by the programmers themselves. At this stage, a phrase like: "I need a program for payroll accounting," is translated into phrases: "create a program that allows (a) to fill in information about employees, (b) to delete information about employees, (c) to correct information about employees, (d) to view information, (e) to search for information based on specified criteria." In short, at this stage, the capabilities and functions of the future program begin to take shape.
3. Creating a conceptual model.
One of the most responsible stages. First, you must answer one tricky but essential question: IS YOUR program needed by USERS, performing the functions defined in the previous stage? And if no (not needed), then either further work on this program is abandoned, or points 1 and 2 are revisited. If the program is deemed necessary, a conceptual model of the future program's behavior is created - what and when it will do, what information to input and output, and when... The structure and type of control and monitoring of its operation are also defined here (control keys, systems and hierarchy of menus, types and amounts of input and output information, in short, the user interface). The time-criticality of the entire program and individual modules is determined.
For games, the rules and laws of the game are defined here, all characters involved in the game, their behavior, and interaction with each other... A description of each character is determined and created so that later the program can manage this character.
At the end of this stage, you should have a balanced model of the program, an understanding of the situations that may arise during the program's operation and ways to resolve them.
4. Creating an algorithm.
Taking into account the results of points 1 - 3, the program's algorithm is created. Both a general algorithm (what each procedure does and what it is associated with) and the algorithm for each procedure are created.
It is very convenient and useful to draw algorithm schemes (what is colloquially called flowcharts).
5. Choosing a language and programming the algorithm.
As you may have noticed, not a single line of code has been written so far! It is still not clear what language the program will be written in!
Now, having the algorithm, you must decide which language to use? And this decision should not be based on the principle of "which language I know better, I will write in that," but on the principle of "which language will allow for effective implementation of the algorithm." Once you choose a language, you can start programming and debugging the program.
As you can see, this is the fifth, not the first and only point! Nods to experienced programmers - "they, you know, start programming right away" do not correspond to reality. Despite everything, even an experienced programmer cannot program without an algorithm! The difference is that they come up with it on the fly and take it straight from their head. But that’s what makes them experienced.
Just as an experienced mechanic can diagnose an engine by its noise, an experienced programmer performs much of the above "in their head" (but they do!), only resorting to a piece of paper and a pen in the most tangled and complex places. When they were inexperienced and "starting out," they drew everything and wrote it down on paper. And there’s nothing "demeaning" about it - a person calculating complex integrals in their head once didn't even know the simplest multiplication table.
And it’s not a problem if they started programming without a drawn algorithm - they will draw it later (at least for checking the program’s correctness and for debugging it).
6. Thorough testing of the program (another name - trial operation).
As a result, errors that inevitably exist in any program are identified and corrected as much as possible (an old "programmer's" axiom: in any program, no matter how well thought out it is, there are at least two serious errors that can only be identified during operation). This is precisely the stage that many either skip entirely or pass superficially, which is a pity.
7. Creating accompanying documentation.
The final stage during which you must describe how your program works, how to work with it, and on which computers it should work, can work...
8. Starting distribution.
Now, and only now, the program is properly formatted and tested, and you can begin its distribution.
I won't hesitate to repeat that ANY program must go through these stages, even if it’s a hacker version!
If it has not gone through at least one stage, or this stage has turned out to be "rushed," it means one of two things:
1. This is a program for "purely home use among family" and releasing it for sale is an act of deep disrespect to users (i.e., to those who will buy it). Personally, I have several such programs of mine; they do not have a good interface (why should I make them fancy if no one else will see them?), are designed to work primarily only on SCORPION with a shadow service monitor (I still haven't created "glitchy" disk operation algorithms for myself when they are already "embedded" in the ROM of my SCORPION!), and have virtually no documentation (I remember why I made them and how to work with them).
Now imagine that I started distributing one of these programs! Your emotions about this? Yet "beginning programmers," "ИНФОРКОМ" (and "SPECTROFON" it seems too) consider the distribution of such programs to be a matter of course.
2. This is still a commercial program, but terribly flawed, if it even works at all. Examples? There are many. The games VIRUS and VIRUS-2: numerous "oversights" at stage 3 (creating a conceptual model), resulting in incorrect virus handling, unclear rules for changing virus behavior when its parameters change, stage 7 (creating accompanying documentation) - the amount of information provided by the author cannot be called merely acceptable, let alone sufficient.
The game "Land of Myths": a program that could well have been implemented on 128K (even with loading, it's not the first time), only works on 256K (stage 1, hardware requirements), the army constantly degrades, and there can be no talk of searching for the Rune Staff (stage 3, creating a conceptual model).
The game "SOLDIER OF THE FUTURE": at the beginning of the battle, robots must be positioned relative to each other (either all outside the building or all inside one building) no further than a certain distance; otherwise, they won't have enough energy to find each other (stage 3), the arrangement of robots before the battle occurs "blindly," as the map will be displayed on the screen later (the same stage 3). I hope it’s not necessary to continue further.
So, dear program developers, please distribute only those programs that are made "scientifically." Respect the buyer (who is also the user).
That's all for today; first, "digest" this information, and then I will "feed" you more. And seriously, very soon (but not before you understand that programming is one of the forms of art, with the addition of mathematical logic) we will approach the description of Assembly language and programming techniques in it.
Until we meet again.
(C) PAUL ATRIDES
Contents of the publication: Oberon #02
- Introduction
Introduction to the second issue of Oberon magazine, with insights into its delays and team expansion. The editorial team acknowledges past misunderstandings and introduces the new issue's contributors. Details on distribution, contributions, and user interaction features are provided.
- Scroll - Alex Noman
Game manual for 'Peking', detailing controls, menu options, and gameplay strategy, involving matching pairs of crates under time constraints.
- Scroll
Empire 128 is a strategic space game where players act as merchants dealing with an alien invasion. Gameplay involves trading, mission completion, and space exploration. The game requires 128K memory and offers both disk and RAM save options.
- Scroll
Description of various space ships, including their specifications, weapon systems, and purposes. Each model differs in speed, armament, and functionality. Includes notes on origins and uses.
- Review
Review of ZX Spectrum games and tools: Double Xinox 128 offers a modern twist on Xonix with 80 levels and new challenges. UFO 2: Terror in the Deep has multiple versions with improvements and issues noted. Shadow Dancer for ZX Spectrum shows graphical evolution but maintains classic gameplay elements.
- Review - Unbeliever
Analysis of the 1996 ENLIGHT demo competition in St. Petersburg, evaluating participants and results across platforms. Highlights the achievements and critiques of notable entries. Provides insights into the dynamics of the competition and perspectives on the ZX Spectrum demos.
- Our Response
Reader feedback and editor's response regarding magazine content, the need for more graphics, and the state of local Samara software distribution.
- About Everything
Critique of Sinclair software quality, concerns about poor programming affecting computer lifespan, and commentary on CODE BUSTERS group's practices.
- Educational Program - Paul Atrides
An in-depth examination of the eight essential stages of software development, from defining technical requirements to testing and distribution. The article provides insights into the necessity of each stage and critiques poorly executed examples. It emphasizes the importance of systematic programming for both commercial and personal software projects.
- Hardware
The article discusses synchronization issues in various Spectrum models and provides a circuit solution to correct INT signal delays for improved graphics performance.
- Announcement - M.M.A
Introduction of new column highlighting Samara programmers' works, detailing projects like ZX-WINWORD, UNRECOGNIZED FORMATTING OBJECT, and DESIGNER ANALYSIS FUNCTIONS. ZX-WINWORD aims to be a publishing system for Spectrum, while U.F.O. offers advanced disk copying. DESIGNER ANALYSIS FUNCTIONS aids in mathematical graphing and function analysis.
- Programming - Unbeliever
A humorous narrative featuring Stirlitz, a fictional intelligence officer, in absurd and surreal situations involving Gestapo, programming, and secret plans.
- Pogurammim - Unbeliever
A humorous and fictional narrative involving Shtrilitz's spy adventures during a covert operation with many unexpected turns and satire.
- Advertisement
Advertisement for electronics and components store offering used equipment, software, and literature.
