Hacker News new | comments | show | ask | jobs | submit login
GOTO.js (archive.org)
91 points by reimertz 6 days ago | hide | past | web | 29 comments | favorite





Funny script, though I can't help but point out a flaw: it doesn't play well with unbracketed conditionals. For example:

    if (num > 5) goto foo;
will not behave as expected, because "goto foo;" is replaced by two separate statements, the second of which is outside the scope of the conditional and will always be called. Maybe they could fix this by tying the statements together with a comma instead of separating with semicolons? (EDIT: I don't think a comma will work, but adding brackets around the two statements should do the trick. JS doesn't seem to mind redundant blocks.)

Still funny though.


I really wish JavaScript had goto statements, because it would make it less of a hassle to make code generators that target it.

Before the new block scoping constructs (which I assume would make implementing goto more complicated), was there anything preventing JavaScript from having gotos, other than an authoritarian "we know better than you"?

At least JavaScript has labeled blocks that you can break out of!


I wrote one of these in 2014 after my boss called goto a mistake.

Goto is a beautiful structured programming construct, the fundamental structure it represents is a skyscraper made of wet spaghetti.


Great advice: "If you are seriously considering using this script, please don't."

Goto can already be functionally achieved with labels, https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Good hint! However, JavaScript labels via break/continue have subtle differences to classic GOTO statements.

From the MDN site examples:

    var itemsPassed = 0;
    var i, j;
    
    top:
    for (i = 0; i < items.length; i++) {
      for (j = 0; j < tests.length; j++) {
        if (!tests[j].pass(items[i])) {
          continue top;
        }
      }
    
      itemsPassed++;
    }
The statement "continue top" does not really jump to top, because it only increases "i" and rechecks the loop condition.

In contrast "GOTO top" would re-initialize the loop ("i = 0") and effectively restart it from the very beginning.


Well sure, but you're just doing it wrong. Here's the goto equivalent.

    var itemsPassed = 0;
    var i, j;
    
    top:
    do {
      for (i = 0; i < items.length; i++) {
        for (j = 0; j < tests.length; j++) {
          if (!tests[j].pass(items[i])) {
            continue top;
          }
        }
    
        itemsPassed++;
      }
      break;
    } while(1);
Not a great pattern but there you go.

You can just pass 0 to while, and ditch the break. ;- )

No you can't.

Try it if you don't believe me


Oh, forgot the weird label behaviour in JS, you're right. Funny to have the label up top, but the branching condition somehow in its way.

You can use labels to jump backwards, but not forwards.

So they get you part of the way to GOTO, but not all the way!




While I fully agree that GOTO can lead to unmaintainable spaghetti (and is rather more likely to do so than other constructs), I wonder if it is actually more understandable than function calls for someone approaching programming for the very first time? I know I cut my teeth using GOTO before discovering GOSUB in BASIC.

Does anyone know of any research on whether some programming constructs are more easily approachable for beginnings and can serve as a tool to understand further concepts (scope, functions, etc.)?


You can do a lot of interesting stuff by parsing the code before running it. For example implementing ES6+ features in runtime's that only support ES5. The possibilities are limitless! It can be really fun when the parsed code itself gets parsed, like a dream within a dream.

I guess this is also what made Lisp and Smalltalk so powerful, right?

callCC is my favorite goto weirdness.

    import Control.Monad.Cont
    import Data.Function (fix)

    main = for 0 (<3) (+1) $ \i -> do
        liftIO (print i)

    for z p s body = do
        (jmp, i) <- label z
        when (p i) $ do
            body i
            jmp (s i)

    label start = callCC (\cont -> return (fix $ \jmp cur -> cont (jmp, cur), start))
Guess you could do this in javascript via trampolining?

BASIC is dope. Maybe hipsters will start using it to build WebApps in a few years, and it will dethrone JavaScript as the hipster language de jour.

No matter how inefficient, JS has made webdev available to order of magnitude more people than it was before.

We're not in 1995 anymore...

JavaScript can hardly be called the language de jour when has been pretty much the only serious frontend language in the (short) history of the web.

I was talking about server-side JavaScript.

Actually 30+ years is almost half of computer history...

How did you arrive at 30+ years?

Does it still work?

There is nothing special about this code. I guess it should still work (but please don't use it ;-) )

Incidentally, I just released https://github.com/pygy/gosub for the cases where you want to use pkg.scripts and either npm or yarn as a task runner, but don't want to force your users to depend on one of these tools at the expense of the other.

`gosub` will run subtasks with the binary you've used to launch the main task.

What does it have over npm-run-all? It passes parameters to subtasks. That's all. It doesn't take any options and can't run tasks in parallel unlike npm-run-all.


Wait, wrong thread?

Not really, but people didn't get the reference.

In Basic, GOSUB is GOTO's younger, smarter's brother. Basically a function call.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: