5 ms·

Indeed, but I think we are too late for that. It's not like the usage of GOTO: someone who mattered wrote that its usage should be considered harmful, and hence

• randomdata 3y ago
  > hence nowadays GOTO has practically a niche usage. Except where it was rebranded as throw/catch. There, goto remains quite popular. All while bridled (C-style) gotos were considered acceptable by Dijstrka, but are now looked upon with disdain. Amazing what a little marketing can do.
  • gordian-not 3y ago
    Aren't you talking about break and continue? throw and catch unwind the stack and goto doesn't
    • randomdata 3y ago
      break, continue, and even goto in any language created in the last several decades cannot leave the current function. These are not what Dijkstra was talking about. Dijkstra wrote the piece when structured programming was just starting to become a thing and was urging people towards it. Think more like goto in BASIC, where there is no bridling of the operator.
      • gordian-not 3y ago
        Yes, however I am not sure if Dijkstra meant goto in the sense of jump outside of a function. I don't know enough about Algol 60 and languages of the time, but if you allow usage of goto between different functions you will have a corrupt stack in no time, so I'll be surprised if it was implemented. Going back to the original discussion, my point was that the only statements that are real gotos still in usage (except for C cleanup gotos) is break and continue, which even support labels
        • randomdata 3y ago
          Functions do not exist in the context of the "Go to statement considered harmful" paper, so there is no good analog in there. Further, he is specific that it is only about unbridled gotos. continue and break are decidedly bridled. In reality, the paper just doesn't apply to any language created in the last several decades, even those which use the goto keyword. We bought in to structured programming. Except I posit that throw/catch still suffers the same problem he speaks of. It becomes difficult to follow when and where the code will jump to an arbitrary spot. The harmful parts of goto live on. Granted, we are learning. Modern languages are abandoning the throw/catch concept.
          • gordian-not 3y ago
            I agree about the somewhat unexpectedness of exceptions, although it is much structured than gotos (you just go up the stack) virtual polymorphism for example is completely unexpected, as well as function pointers and other constructs that in my opinion are harder to track than exceptions
  • whstl 3y ago
    Almost everything is a "rebranded goto". Functions, conditions, iteration, break/continue. Doesn't mean that Dijkstra was wrong, or that they are the same as goto. Also, throw/catch do quite more than a goto, though. It's not only about stack unwinding, it's about the ergonomics of not needing code that uses throw to have any information about where catch is located. Sure you can simulate some use cases of try/catch with goto, but implementing the general case is much harder. throw/catch is exactly the kind of good goto-replacement provided by "higher level" programming languages that Dijkstra is talking about in his paper.
    • gjvc 3y ago
      > Almost everything is a "rebranded goto". Functions, conditions, iteration, break/continue. That's like saying all maths is just the application of addition.
      • ubercore 3y ago
        I think that's the point -- it's nearly as useless to call throw/catch a rebranded goto as it is anything else.
      • whstl 3y ago
        Yeah. It’s a useless pedantism that serves no purpose in most discussions. That’s what I have “rebranded goto” in quotes. And that’s what I address in the second paragraph.
        • gjvc 3y ago
          it failed to satisfy me
    • randomdata 3y ago
      > Almost everything is a "rebranded goto". Functions, conditions, iteration, break/continue. Not within the context of discussion, where goto refers to the harmful kind. Throw/catch exhibits the very problem Dijkstra was talking about, with execution jumping all over the place haphazardly. Functions, conditions, iteration, break/continue, even (C-style) goto does not exhibit the same problem. They are strictly bridled in the execution scope. There is good reason why modern languages are moving away from throw/catch. However, there is little question that it is still widely used at this time.
  • patmorgan23 3y ago
    Throw is much worse than GOTO. GOTO is explicit you always know where it goes. Throw has no idea where catch is and catch has no idea where throw is. It's hidden control flow. Go/Rust/Zig Errors as values is a much better system forcing you to explicitly deal with the error, crash or pass it on. Rather than hoping you handled all the correct exceptions/someone else will handle all of them.
    • o1y32 3y ago
      If this were a top level comment I am sure you'll get 20 people disagree with you on this
      • randomdata 3y ago
        Even Dijkstra followed up the "Go To Statement Considered Harmful" letter with the "On a Somewhat Disappointing Correspondence" letter because "20" people disagreed with him. There will always be naysayers. The above is starting to become generally accepted, though, and modern languages are moving away from the practice just as languages moved away from unbridled gotos.
• fvdessen 3y ago
  The thing is they are not harmful, they are valuable above a certain scale. To caricature, monoliths scale with O(n) and microservices O(nlogn). At some point the lines cross and microservices start to get better. The problem is there's no clear answer to where is that point as it also depends on the product being built and other company specifics. But I wouldn't see it being usually worthwhile below a hundred devs.
  • jcparkyn 3y ago
    Your analogy is backwards, nlogn > n.
    • pc86 3y ago
      They're saying that microservices scale much worse than monoliths at the beginning, and need to reach a certain scale before they're worth the effort. The debate around is usually around where that inflection point is, and to a lesser degree if there are other non-scale advances to microservices that might make it worth adopting sooner.
    • nonameiguess 3y ago
      This comment was grayed out at the time I upvoted and am commenting. Either readers don't appreciate pedantry or don't realize what the point was, but for any n > 2, n * logn is a larger number than n. I believe what the original poster meant to say was microservices grow like O(klogn) and monoliths O(n), i.e. microservices have some upfront constant cost that is large enough that, for small projects, monoliths will still perform adequately and be cheaper to develop and deploy. Once you exceed n large enough to overcome that upfront constant cost, microservices become the superior option. I'm not agreeing or disagreeing with this, by the way.
      • fvdessen 3y ago
        Indeed that's what I meant, but cannot edit my comment.
      • inkyoto 3y ago
• pjmlp 3y ago
  Thing is, contrary to GOTO, microservices help selling books, conferences and consulting services.