a rest - GLODING PROGRAMMING (Programming upwards diagonally)

<b>a rest</b> - GLODING PROGRAMMING (Programming upwards diagonally)

 Music by Shov



               Department of MIS



              G L O R I N G



          P R O G R A M M I N G


(Programming upwards diagonally)
description of the programming GLOP


        Programmer's Guide


              Moscow 1983



  "... Then it is sufficient to encode:

   g l of p

   and you can be sure that all

   actions will be executed bezoshi
   erroneously and effectively. "

      E. Yoda, President

      jordon Inc.., N.Y.



     "Is the Lord God to write about
      gram, which he can not otla
      dit? "



         Unmistakable encoder

         VZYSK SYSTEM LAV.MEMVER, MISN.



     In recent years, the capitalist west, like mushrooms after 
a rain are developed all sorts of "theories" programming 
"designed, ostensibly, easier to write, debug and maintain 
large software systems. It is obvious that being a product of 
bourgeois ideology, and expressing the interests of the ruling 
class, these theories are designed to distract the masses of 
programmers from their true interests. Unfortunately, we have 
some friends came under the influence of pernicious theories of 
"structural", "modular", "top-down or bottom-up programming, 
forgetting that the longer a programmer debugs

program to accurately and efficiently
it ever will work. Therefore,
long overdue need to confront these lzheteoriyam our home, 
homemade, suffered and labored techniques. Experience of this 
technique and suggests to the reader. We named our method 
"Gloping programming" or "bottom-up obliquely (IOS). Main idea 
method EHV best conveys the ancient Eastern wisdom: "If 
anything can be done in two ways, do not take efforts and 
create a third ". 



            I. Where to start.



     Many Western programmers argue that before you begin to 
write program, you need time to think of the algorithm, and 
some are even calling penetrate into essence of the problem, 
which will be addressed. Categorically not be interested in 
formulation of the problem until obtaining obektnogo program 
module. Remember that programming is an art - so any extra 
knowledge only restrict your imagination. Start writing the 
program text before how you will formulate technical

job, and you get a great opportunity to make the life of your 
manager (And his) are much more diverse and interesting (for 
example, when you get TK can make trouble: "Imagine

how many will now have to redo ?!").

   Never compose advance
flowchart of the program.

     Firstly, it is easier and faster to do when the program is 
already written, secondly, inadvertently left on

table block diagram will give your enemies and envious people 
the opportunity to understand what you are going to do. 
Remember that no one else has to understand your program. And 
if you just can not get rid of the bad habit of drawing 
flowchart, then hack to death on your nose: 


  The larger structure of the program consistent with its 
logic, the less you stand as a programmer.



               II. Style.



     This buzzword in many Western adherents and apologists 
give a special, almost mystical meaning. Certainly,

each programmer or there, composer
has the right to write in his manner, but given the Volumes of 
programming development, it is necessary to reckon with 
reality. Like everyone else, programming

to be thrifty!

     Spend up to 50% of punch cards and the amount
Listing (word, then some!) for comments, blanks, empty 
operators, stars and other embellishments - completely 
unacceptable waste. E-mail to Second in the 71st position in 
every possible way to avoid gaps. If the comment did not 
escape, try to write them as soon as possible concrete. For 
example: 

DO J = 1 TO N; / * SYSL RO N * /
IF J> 0 GOTO TNEN M / * REREHOD TO M * /
ELSE GOTO L; / * REREHOD K L * /
X = X +1 / * RRIVAWITH 1 TO X / * END;
M: X = X-1 / * so it is necessary Fyodor * /
IF A TNEN GOTO L;
L: / * X VOZVESTY STER. TWO * /
X = X ** 2, ... ETC


     All the variables to give names to your
friends, favorite foods, variety of ensembles, cigarettes, 
drinks, etc. It is easy see that the fragments of the type:


IF KATJA> = 18 TNEN DO;
SALL GASTRONOM;
SALL TAHI;
GOTO HUT; END;
ELSE GOTO VERA;


 GLORING SSEST

          ...
 MARINA EQU DURA

          ...

          L AH MARUSJA

          ST Un, ANJUTA

          VHLE LETS, IRINA, DRINK (AGDAM)

             / * ASSEMVLER * /


amazing grace, wit and subtle
taste.


     A close examination it is easy
reveals that bourgeois writers
books on the subject arguing that they
called "structured programming",
drowning in its own contradictions. For example, [e. Myers], 
page 63: "Modest to objectives of programs that are running 
better not regulated grandiose projects, "and on page 58: "If a 
minor addition will make your fitness program for another case, 
never neglect it. " We are ready to agree with the last 
assertion, since his skillful application will allow you to 
delay the development of program at any conceivable time.


    Moreover, the same author a few pages later, remembers the 
notorious principle of K I S S (Keep is simple, stupid -

keep it simple, stupid!). Imagine, in
One day the head says to you: "Something you really really just 
all it turns out! "


     These structural and extremist tendencies in the end, lead 
to a complete degeneration of programming as a creative 
activity. Limiting degree degradation generates methods such as 
Ashcroft manna [er. Iodine], which reduce the activity of the 
programmer to work Chaplin on the assembly line in the film 
"Modern Times." 


               III. GO TO



     The problem of unconditional jumps to
Fortunately, not yet found a definitive solution. Among Western 
youth programming is a common misconception that the use of 
goto statement is strongly discouraged. The practice of the 
lead programmers our laboratory shows that the use of 
unconditional transition operator in conjunction with arrays of 
tags increases the efficiency of programs by an average of 4.2% 
An increase in time debugging 350-400%.


     If you want to go from this point
programs should go as soon as possible
further. If we go nowhere, you should review the program.

     Very successful are the transitions in the body
cycle of DO, especially from other modules. Although 
translators usually forbid it, they can easily cheat, Using 
variables of type label. Transferring control to a subroutine 
in bypassing the title will bring you many hours of

Happy thoughts on the code completion
0S5.


     All the inserts in the program should do so: after the 
last statement Insert a new label, write text

insertion, increase the dimension of the array
marks on the 2, passes control to this
label from the desired point (or from somewhere
more), check the statement following the goto, a new label, 
feel free to change the variable label and return.


     Generally speaking the language in which you would
or write a program better if each
the operator will have its label (as
provided in Fortran). The extent of your
skills as a programmer in style
EHV, is defined by:


                   n

              sigma (v (i) + w (i))

                  i = 1

        k = ------------------
                   n
Where (1)


     n - the number of operators

     v (i) - the number of control transfers
on the i-th operator

     w (i) - the number of possible transitions
from the i-th operator.


     When k <0.5 you as a programmer, not fit anywhere. An 
acceptable rate 3 - 4, and some have superprogrammisty k is not 
less than 12. 


            IV. Modularity.



   No modularity! Generally ...



            V. Efficiency.



     Disputes over what is considered
efficient program, do not cease with those
then, when the gym has earned a computer
M-20. These days, it came before the
casuistic statements like: "The readability of the program is 
substantially its effectiveness" [d. Myers]. 

     We believe that the effectiveness of the program is 
completely objective and quantified value. Not

should spare no time or effort
the struggle for efficiency - when your
program eventually will work, all
your cost savings will pay off 15 sec
and 0.073 kb. That the programmer can advance
evaluate the effectiveness of its product,
propose a simple formula:


      e = t/t1 + i * t/t2, where (2)



     t1 - the time required sru to run your program (if the 
program still does not get in go playlist, t1 = t);


     t - the time required for output
alphanumeric PRINTER pre-prepared text, which is identical to 
the one that will print your program, when released to go 
playlist; 

     t2 - time that your program
will be satisfied when you're completely
debug.


     i = sqrt (-1)



     Effectiveness of the program, as can be seen,
value of the complex, which reflects a systematic approach to 
programming, which is characteristic for the method of ANS. 

     Thus, it follows from expression (2), the timing of 
writing and debugging program does not affect its

efficiency. Many programmers seem to intuitively come to 
understand this fact and improve its program for years, making 
it more effective for by reducing the parameter t2.


     Incidentally, one of the apologists of "structured 
programming" [d. Myers] allowed myself the following: "No one in

sound mind and memory, will not
program in assembly language. "And so on
about the preferred language of supporters EHV!
On the contrary! The study of assembly - a great way to the top 
of cognition OS EU Computer. Following this path, you get a lot 
of useful knowledge that will help you solve some major 
problems: 

     1). As a receiving voucher for one
moment in the package, to seize undivided use of CPU, at least
for 1.5 hours, to eliminate the problem all other
users (eg, code s422),
lock the queue, to deprive the operator the opportunity to 
remove your job, seamlessly to get the results (not

regardless of the established limit paper consumption), and at 
the same time - all of the claims operator service OVT forward 
toward any department


     2). How to ruin (not erasing) all
strangers on your HD package 5050/5061, no
leaving traces in rrintlog?

     3). How to erase the kernel? (Or IPL?)


     Generally, there is a rich spectrum
ways to improve the effectiveness of programs. The authors are 
well and has long been familiar with one programmer who not so 
long ago won a bet a case of beer, increasing, 40

minutes of surface analysis, at least
twice the speed of the three programs
Fortran, taken at random from a trash can at one of the 
departments of Faculty "T". because this fact is absolutely not 
known management, programmers in the style of EHV

a long years of cloudless existence and happy programming.


         VI. Again the modularity.



     Still, no modularity!


     (Since the modularity can be understood differently, as 
the presence of certain built-in function. Everything else - 
from the evil one.) 

     Consider yourself inferior to others, if you
not able to write a program (if
want to call it a module) are longer than
1,000 operators. If a number of installment of the objective
reasons (they are always) you still
faced with the problem of matching, then remember one single
Rule method SVN:


     No agreement on the links!


     In particular, if we have to
dealing with the programmers of the opposite
sex.


        According to article 94

    Procedure Code

    parsing of cases of mouth
    update folder paternity proto
    count agreement on links

    taken into account along with up to
    proof together
    of farming.



     In addition, as already emphasized,
Any limitation is your imagination, as
programmer will not do anything except
reduce project development time and,
thus reducing the efficiency of end-
product.

     Treat your head, hanging over the desk a poster: 
"Programming - too complicated intellectual activity, so that 
you can hope to impose administrative ties system, which 
stifles all initiative. "[Van Tassel]. If management response 
would be more restrained than you expected to repaint the door 
of your lab green paint the most toxic color and disappear for 
three days, after turning off the home phone [b. Meyer, Boda]. 


              VII. Debugging.



     The first commandment programmer who successfully overcame 
the barrier of syntactic control - not to hurry. Remember that

poorly debugged program is always less
effective than not debugged. Not
to print more than one variable
for one run. Obtained Listings (print), immediately dispose of 
(avoid! .. See V). On the other hand, it is useful to keep in a 
single copy protocol compiler with the worst (it is not

difficult) to print quality, so that when
unscheduled appearance in the head
you could say: "You see, the conditions in which to work!" Of 
course, the diagnostic messages should be cut off, but better - 
inaccurately cut short. (For those who are programmers FORTRAN

or assembly language, we recommend purchase
some skills with scissors and
glue).


     If you store the source code for
IDS, never check cards IEBUPDTE,
and not to deprive yourself of pleasant surprises! Moreover, to 
check punching - bad taste and a sign of disrespect vile

a sweet and charming girl, spending the best years of his youth 
on punching holes in your punch cards. 

     When finished debugging, operation begins!

     No self-respecting programmer
not allow his beloved child, the fruit
his many years of work and suffering
exploited by some strangers.

     A few words about testing. No
does not know what exactly is the test that is the ultimate 
goal and what results should be obtained. In the method of EHV 
is considered to be testing completed, if the execution fails 
with return code of 0000, even if the original

data differ by at least one number
(Or all - if you maximalist).


     After completing the test phase
Destroy the source code. Only in this
If you can be absolutely sure
that your program no one no harm, and it will remain as 
effective as ever. 


            Success!
__________________________________________