Журнал Витуса

This is a huge mess, a mosaic, a heap of things the authors could remember.

A good plan for a book of this kind should include - and it's the requirement number ONE - some INTERNAL LOGICAL THREAD, which is easy to follow, which makes sense, and so makes it possible to teach varied material as something coherent.

FOR EXAMPLE, a possible main logical thread might be created like this.

Programs live on a computer like animals in a forest, and the "forest" is the environment the computer forms for them. The computer itself is a dead hardware box, and it is something called OS that connects hard drives, memory, periphery into a meaningful whole.

But how can a human user interact with it? - the earlier generations of computer engineers
and OS designers standardized on something called "a shell".

Then you continue with the UNIX PHILOSOPHY, i.e. the principle that programs (runnable from command line or shell scripts) are written in such a way that

(a) they do one thing well rather than many things (all things one can think of ) in one fat executable. Examples: compression programs must know how to compress, but not archive, for that we have "archive programs", etc.

(b) but many specialized programs can be connected into processing CHAINS to combine them and achieve complex tasks
This is done thanks to special features of SHELL (piping, STDIN/STDOUT, ....)

THIS APPROACH was found to be very powerful, and it survives to this very day in PROFESSIONAL applications of computers: shells/REPL/... are built into many programs which at a later stage acquired GUIs

One of the major disadvantages of the Command Line interface to computers is that one has to KNOW before one can use the "commands"

Later people devised the GUI approach. It substitutes this need to know up front with an ability to explore menus -- but is infinitely more restrictive. Therefore to this very day GUI-based attempts at professional application (e.g. GUI-based plotting or math crunching (MathCAD)) are weaker tools than those based on CL (Mathlab).

Most of development follows the CL paradigm and this is the first environment a software engineer needs to learn

But because in today's world we use GUI/window-based environments in which many inidvidual windows (running CL or GUI apps) are living, we will use GUI tools as well.
As a rule, knowing a CL version of development tools makes one immediately understand the (simplified) GUI front-ends to them, but the reverse does not work, a GUI-literate developer will feel helpless when having to switch to CL environment

(2)
NEXT you follow a logical sequence for introducing
-- scripting
-- compilation
-- languages with REPL
-- debugging
-- version control
-- testing

The windowing environments and GUI progs are introduced as TARGETS for the students' future development efforts.

You may show the GUI world mostly as a convenience for the less computer literate and almost totally computer illiterate (from the engineering point of view) end users, who only know how to work in end user programs, and are almost disfunctional as far as the computer itself, as a system is concerned (the "forest" in which animals-progs live).

So this is a natural progression following the needs of the developer rather than an attempt to list all unrelated bits one's memory retained, without rhyme or reason.

You need a certain NARRATIVE to tell, not a mosaic of brightly coloured pieces of various shapes and sizes to dazzle - and leave helpless.