http://www.perlmonks.org?node_id=153963


in reply to Re: Linear programming is bad
in thread Linear programming is bad

Aack! I just knew that was going to happen. It just seemed like the most straightforward description. I'm open for suggestions. A free, random ++ to the first monk to come up with a better name :)

It bugs me because there is a better name and I know I've seen it somewhere; I just can't remember ... grr!

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Replies are listed 'Best First'.
Re: (Ovid) Re(2): Linear programming is bad
by Juerd (Abbot) on Mar 24, 2002 at 23:24 UTC

    I'm open for suggestions. A free, random ++ to the first monk to come up with a better name :) It bugs me because there is a better name and I know I've seen it somewhere; I just can't remember ... grr!

    Imperative programming.

    U28geW91IGNhbiBhbGwgcm90MTMgY
    W5kIHBhY2soKS4gQnV0IGRvIHlvdS
    ByZWNvZ25pc2UgQmFzZTY0IHdoZW4
    geW91IHNlZSBpdD8gIC0tIEp1ZXJk
    

Re: (Ovid) Re(2): Linear programming is bad
by seattlejohn (Deacon) on Mar 25, 2002 at 09:29 UTC
    Can't resist:
    • Concrete Programming. Because it lacks abstraction.
    • Ballistic Programming. You launch the interpreter on its way and it sails along a simple trajectory to the end (where there might be a big kaboom).
    • Linguini Code. Like spaghetti code, only not quite as messy.

    Now you all know why I don't do stand-up comedy for a living.

      * 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.

      U28geW91IGNhbiBhbGwgcm90MTMgY
      W5kIHBhY2soKS4gQnV0IGRvIHlvdS
      ByZWNvZ25pc2UgQmFzZTY0IHdoZW4
      geW91IHNlZSBpdD8gIC0tIEp1ZXJk
      

Re: (Ovid) Re(2): Linear programming is bad
by VSarkiss (Monsignor) on Mar 25, 2002 at 00:58 UTC

    I would suggest "straight-line programming", since I usually write like this when I want to go from point A to point B as quickly as possible. ;-)

Re: (Ovid) Re(2): Linear programming is bad
by da (Friar) on Mar 25, 2002 at 03:34 UTC
    Howzabout:
    • non-procedural programming;
    • unstructured programming; 1
    • linear code
    • spaghetti code?

    --

    1. which sort of steps on the definition of structured programming but is still pretty accurate.

    ___ -DA

      * non-procedural programming;
      * unstructured programming;

      Putting "non" or "un" in front of existing ways of programming only describes what this form is not, not what it is. You could go on and say: "not object oriented", "not flow-based" and "not the real linear" :)

      * linear code

      Code is the result of coding, also programming. So linear code is the result of linear programming, and we already know that's not what this is.

      * spaghetti code?

      Not really. Spaghetti code that is unreadable, and of which you can't understand the logic unless you go step by step and see what it really does. All code with goto LABEL or goto EXPR is spaghetti code, but obfuscations are too.

      U28geW91IGNhbiBhbGwgcm90MTMgY
      W5kIHBhY2soKS4gQnV0IGRvIHlvdS
      ByZWNvZ25pc2UgQmFzZTY0IHdoZW4
      geW91IHNlZSBpdD8gIC0tIEp1ZXJk
      

Re: (Ovid) Re(2): Linear programming is bad
by patgas (Friar) on Mar 25, 2002 at 01:11 UTC

    I've occasionally referred to it as "waterfall programming", since you start at the top of the code, and write straight down to the bottom. *shrug*

    "As information travels faster in the modern age, as our days are crawling by so slowly." -- DCFC

      I've occasionally referred to it as "waterfall programming", since you start at the top of the code, and write straight down to the bottom. *shrug*

      I like that name, and have seen it before. But that was for code like this:

      %triUK = (0 + 0 + 0 => qq//.qq//.qq// => map { (my $foo) = /(\d+)/; $foo => $rev{"*1e$_"} } grep { s/^\*1e//g and /[bB]/ and $_ <= 22 } @dummy = values %parts ); sing("lalalalalah");
      Or: A statement that doesn't fit on a single line, but can be made looking awful when indented more every line, and filled up with uselessness :).

      U28geW91IGNhbiBhbGwgcm90MTMgY
      W5kIHBhY2soKS4gQnV0IGRvIHlvdS
      ByZWNvZ25pc2UgQmFzZTY0IHdoZW4
      geW91IHNlZSBpdD8gIC0tIEp1ZXJk
      

Re: (Ovid) Re(2): Linear programming is bad
by mAsterdam (Sexton) on Mar 25, 2002 at 23:01 UTC
    Ovid:

        It bugs me because there is a better name and I know I've seen it somewhere;
        I just can't remember ... grr!

    I recall a term Drop-through programming for what I think you mean with (Operational Analysis reserved word) "lineair" programming. A drop-through program is a program where the execution starts at the top of the file, drops through the code and stops at the end of the file (this is not to be named "top-down" which is also reserved allready).

    That makes sense I think - though english is not my native language. As soon as you introduce a subroutine you have to decide where to put it: on top? at the end? In the middle? Anyway somebody (the programmer or the language-programmer) has find a way to exclude it (this first subroutine) from the drop-through execution flow, so that it only gets executed when you want it executed.

    HTH,

    Danny

Re: (Ovid) Re(2): Linear programming is bad
by thpfft (Chaplain) on Mar 26, 2002 at 13:27 UTC

    narrative programming?

    for its and-then-and-then-and-then structure.

    but then i was thinking, maybe just 'programming'? most things seem to start this way and only deserve special names later when their true nature is clearer. but then i am given to 'making it up as i go along programming' . perhaps some people know what they're building :(

Re: (Ovid) Re(2): Linear programming is bad
by mojotoad (Monsignor) on Mar 25, 2002 at 21:01 UTC
    How about crow flight programming, as in "as the crow flies" ???

    Hmmm, maybe not.

    Matt

Re: (Ovid) Re(2): Linear programming is bad
by petral (Curate) on Mar 25, 2002 at 22:17 UTC
    This would seem to be a slightly refined version of what I call "programming by typing".   You start at the top and take care of each thing as it comes up until you're done.   Perfectly good idea for programs less than, oh, say five lines.

      p