Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
A case for unstructured programming (250bpm.com)
13 points by rumcajz on July 18, 2015 | hide | past | favorite | 13 comments


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.


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.


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.


It's a dirty little secret. Officially, of course, we are all using structured programming. But in private, everybody does break and continue!


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.


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.


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.


And here's its fully structured counterpart:

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


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


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.


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.


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.


Looks like a use case for a monad or try!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: