* Concrete Programming. Because it lacks abstraction.
* Ballistic Programming.
Or just Imperative Programming. Imperative means commanding/expressive: you tell the interpreter what to do directly, without abstracting it into subs and telling indirectly. Imperative programming is programming where the program logic and the way it's handled are combined in the same code.
Most other code forms are aimed at abstracting those two things: have a part that just controls, and have a part with routines to be controlled.
The easiest is to rip it apart to subs and have procedural or functional programming. A greater abstraction is object oriented programming. The worst abstraction i've seen so far is flow-based programming: complete abstraction of control, data and what actually happens. I think too much abstraction is not good, because I think code should tell you what it does, without comments.
Imperative programming (what Ovid called "Linear programming") is NOT bad, imnsho. It can be bad. In the example Ovid gave, I think imperative programming is the way to go, and very maintainable. I don't see how the other example, with the parts wrapped in subs, is easier to maintain: someone will only have to read more to find out what happens. For simple scripts like this, imperative programming is my favourite style.
BTW, _all_ scripts have imperative parts, because otherwise you wouldn't be telling the interpreter everything ;) The term "imperative programming" is related to your main (controlling) code.