

A case for unstructured programming - rumcajz
http://250bpm.com/blog:53

======
tel
Here's the point in time where we return to how monads are great.

What Sustrik asks for here is an imperative context where failure is a native
operation. Obviously, this is most useful in a delimited way and this is
_exactly_ a maybe monad.

------
PaulHoule
People had this argument in the late 1970s and your viewpoint won, although
nobody seems to have noticed. Of course you need break or return or something
like that to write a linear search that doesn't have a confusing condition
variable.

~~~
tel
That's plenty structured, though. It's just getting a hold of your
continuations. The sin of GOTO is doing it with names and not scopes.

------
TheLoneWolfling
I once (briefly) tried to collaborate with someone who would not use `else if`
statements, and used braces always even if they were optional.

    
    
        if (foo) {
            <whatever>
        } else {
            if (bar) {
            <whatever>
            } else {
                if (baz) {
                <whatever>
                } else {
                    if (spam) {
                        <whatever>
                    } else {
                        ...
                        <etc>
                    }
                }
            } 
        }
    

It didn't end well.

He also wouldn't use break or continue or multiple returns.

As this article says, it led to really really annoying-to-read code.

~~~
agumonkey
Pardon me lisping, but I just read your code as pseudo linearization of
trees...

    
    
        (cons a
              (cons b
    		(cons c
    		      (cons d . nil))))
        
        (list
         a
         b
         c
         d)
    

a,... being condition/reaction pairs.

~~~
TheLoneWolfling
Effectively.

It's one of the reasons why I wish more languages had a generalized switch
statement (i.e. one that accepted arbitrary code as conditions, not just
constants compared to a single value), preferably with a way to (explicitly,
preferably) code a fall-through.

It means that you cannot necessarily translate it into a jump table, true. But
it means that you can write code much more concisely, on the flip side. And it
remains slightly readable.

------
jonsen
_And here 's its fully structured counterpart:_

    
    
      do_stuff1();
      while (!condition()) {
        do_stuff2(); 
        do_stuff1(); 
      }

~~~
rumcajz
do_stuff1() is a shorthand. It can be a block of code tens of lines long.

~~~
jonsen
It is a part of the structured programming idea to make modules callable by a
"shorthand". It is not in the spirit of structured programming to make use of
flow control flag variables.

~~~
rumcajz
But if you extract each piece of code that doesn't fit the structured syntax
into a separate function you'll end up with zillions of small functions witch
have no clear semantics by themselves (only when considered within the context
of the calling function). That's probably the most unreadable coding style
I've seen in my career.

~~~
jonsen
I did not say it was recommendable. I just said that _that_ was the structured
counterpart. Your counterpart is not. Also I believe most structured
programming advocates have no problem considering leaving a loop in the middle
as a valid programming structure.

------
asdfjklajskjdf
Looks like a use case for a monad or try!

