Live data from Hacker News

What can be learned from studying long gone development practices?

shape-of-code.coding-guidelines.com

71–80 of 142 posts

Re: What can be learned from studying long gone development practices?

#71

I'm not sure you can call structured programming a fad! An awful lot of languages (I'd say all commonly used ones) use if/then/else, do..while, for..next, and so on, but I can't remember the last time I saw a program with a complicated control flow done by gotos. Such things were common in the 1970s, in fact the first professional program I ever read did it that way, and it took me ages to work out what was going on.…

> One particularly confusing technique was to goto a computed expression. Leads to all sorts of interesting bugs.

Huh. I suppose the modern-day equivalent is commonly done with higher-order functions - in particular, callbacks, CPS and returning functions. I've worked with people who find this confusing (particularly the last one - functions returning functions).

Re: What can be learned from studying long gone development practices?

#72
post #67

Earlier quoted context omitted.

State machines and actors are occasionally cited as good ideas here, and they seem like much the same kind of unstructured programming IME.

Why? You can easily emulate a state machine with a while loop, a switch case and one more level of if-branches. Abstracting those in a framework doesn't make it unstructured IMO.

> You can easily emulate a state machine with a while loop, a switch case and one more level of if-branches.

You can easily emulate GOTO much the same way.

Re: What can be learned from studying long gone development practices?

#73

I'm not sure you can call structured programming a fad! An awful lot of languages (I'd say all commonly used ones) use if/then/else, do..while, for..next, and so on, but I can't remember the last time I saw a program with a complicated control flow done by gotos. Such things were common in the 1970s, in fact the first professional program I ever read did it that way, and it took me ages to work out what was going on.…

I've been learning lua, and loops don't have a continue or a break. You can use a goto to jump out. I tried it but didn't like it. Might just be prejudices. :)

It is a prejudice. Knuth and Torvalds think goto is valuable. See https://pic.plover.com/knuth-GOTO.pdf https://news.ycombinator.com/item?id=8760518 (Somewhere on the internet is a discussion when somebody suggested to remove all gotos in the kernel with structured programming, the answers were entertaining and insightful; I cannot find it right now though)

Re: What can be learned from studying long gone development practices?

#74
post #72

Earlier quoted context omitted.

Why? You can easily emulate a state machine with a while loop, a switch case and one more level of if-branches. Abstracting those in a framework doesn't make it unstructured IMO.

> You can easily emulate a state machine with a while loop, a switch case and one more level of if-branches. You can easily emulate GOTO much the same way.

obviously, as long as the language is turing complete, but you just converted an unstructured program to a structured one.

Re: What can be learned from studying long gone development practices?

#75
post #44

> I think the best management technique for successfully developing a software system in the 1970s and 1980s (and perhaps in the following decades), is based on being lucky enough to have a few very capable people, and then providing them with what is needed to get the job done while maintaining the fiction to upper management that the agreed bureaucratic plan is being followed. Surprisingly, very little has changed.

This management practice called “programmers anarchy”. It worked very well in my professional life too.

Third this. Process doesn't really matter. Just hire good programmers and let them program.

Re: What can be learned from studying long gone development practices?

#76
post #67

I'm not sure you can call structured programming a fad! An awful lot of languages (I'd say all commonly used ones) use if/then/else, do..while, for..next, and so on, but I can't remember the last time I saw a program with a complicated control flow done by gotos. Such things were common in the 1970s, in fact the first professional program I ever read did it that way, and it took me ages to work out what was going on.…

State machines and actors are occasionally cited as good ideas here, and they seem like much the same kind of unstructured programming IME.

Indeed, GO TO is not that unstructured; it can be said to have a fairly precise semantics of "sets the continuation of the program to ; does not proceed to the next statement.". Though if you want to analyze the semantics of a GO TO-using program, it's practically a required step to endow all of your labels with appropriate COME FROM annotations, marking the branches it could be reached from - and that's a whole-program analysis, at least in principle. That's the point where you're giving up modularity!

Re: What can be learned from studying long gone development practices?

#77
post #73

Earlier quoted context omitted.

I've been learning lua, and loops don't have a continue or a break. You can use a goto to jump out. I tried it but didn't like it. Might just be prejudices. :)

It is a prejudice. Knuth and Torvalds think goto is valuable. See https://pic.plover.com/knuth-GOTO.pdf https://news.ycombinator.com/item?id=8760518 (Somewhere on the internet is a discussion when somebody suggested to remove all gotos in the kernel with structured programming, the answers were entertaining and insightful; I cannot find it right now though)

Have you read Knuth’s article? It is a bit more nuanced than a wholesale defence of GOTO in preference to structured programming. It surveys various control flow structures that are not easily expressed in terms of IF conditions and WHILE loops (what structured programming advocates of the time argued to replace GOTO with), but more easily expressed with GOTO, and it argues that, since we don’t know which of those constructs will ultimately end up the most useful, it might be prudent to keep GOTO around, at least for a while, and not confine ourselves to simple conditionals and loops just yet. But if we do find better structured control-flow primitives, perhaps we may get rid of GOTO after all. The comments under the Torvalds link kind of point it out already: GOTO is used in the Linux kernel as a crutch for the deficiencies of C, like the lack of scope-based destructors, exceptions and the ability to specify which loop a BREAK statement targets.

My favourite part of the Knuth paper is this:

    begin until error or normal end:
      if m = max then error ('symbol table full') fi;
      normal end;
    end;
    then
      error (string E) =>
        print ('unrecoverable error,'; E);
      normal end =>
        print ('computation complete');
    fi;
This is pattern-matching on a Result, in 1974. How adorable!

It’s a shame that innovation in this area has stagnated so much: most languages only feature IF, WHILE, FOR, single-level CONTINUE/BREAK, SWITCH (with fallthrough), and GOTO as an escape hatch in case the others are insufficient, just because they are so familiar. Only now languages like Python or Java are getting any form of pattern matching. Though props to the latter for at least allowing to break multiple loops by way of labelling the outermost one.

Re: What can be learned from studying long gone development practices?

#79
post #53

I disagree strongly with the authors assessment of the state of software development a few decades ago. By the late 1960s, we had realised software development was hard. We put some good brains on the problem. Discussions between leading experts brought up several very important points, that we struggle with to this day: - Naming things, - Low coupling and high cohesion, - Communication between developers, - Communic…

Honestly there is a bit more than that.

The idea of mass development with large, open ended access to code is actually a surprisingly recent idea. Plus of course Stackoverflow has significantly changed the approach.

Concurrent programming is also significantly different to its 1960s iteration. COBAL and Fortran did not even attempt to do such a thing, the handling of all those asyncs was not around.

Many many other architectural details have also been implemented that were specifically designed not to be exposed to give classically trained programmers the illusion that things under the hood have not changed. However, they have significantly. Branch prediction leaps out at me, but also many other forms of evaluation, memory and processor design.

There is more than you describe that has changed.

If you would say that compilers and parsers have not changed, that would be extremely accurate. But there's a bit more to the world on either side of the compiler.

Re: What can be learned from studying long gone development practices?

#80

The real value of studying outdated development methodologies is that it teaches you how to think about new problems. It will almost never give you a plug-and-play answer for a problem you are facing, but it will give you a new a useful way of looking at things. Brooks wrote The Mythical Man Month in the 1970s about his experience in the 1960s and it is still extremely relevant today. When I was starting my software…

The analogy of programmers as general surgeons is so timeless it's downright creepy.

Nothing has changed in Brook's book because it's a book about human beings doing creative work, and humans haven't changed at all.

Post reply on HN