• hades@lemm.ee
    link
    fedilink
    arrow-up
    9
    arrow-down
    1
    ·
    17 hours ago

    The language not being compiled has nothing to do with error handling. You could have a min function that operates on dynamic arrays (e.g. std::min_element in C++ or min() in Python).

    • bss03@infosec.pub
      link
      fedilink
      English
      arrow-up
      1
      ·
      7 hours ago

      Not having a separate compilation step absolutely affects error handling. With a compilation step, you can have errors that will only be seen by and must be address by a developer prior to run time. Without one, the run time system, must assign some semantics to the source code, no matter how erroneous it is.

      No matter what advisory “signature” you imagine for a function, JS has to assign some run time semantics to that function being called incorrectly. Compiled languages do not have to provide a run time semantics to for signatures that can be statically checked.

      • BatmanAoD@programming.dev
        link
        fedilink
        arrow-up
        1
        ·
        1 hour ago

        Without one, the run time system, must assign some semantics to the source code, no matter how erroneous it is.

        That’s just not true; as the comment above points out, Python also has no separate compilation step and yet it did not adopt this philosophy. Interpeted languages were common before JavaScript; in fact, most LISP variants are interpreted, and LISP is older than C.

        Moreover, even JavaScript does sometimes throw errors, because sometimes code is simply not valid syntactically, or has no valid semantics even in a language as permissive as JavaScript.

        So Eich et al. absolutely could have made more things invalid, despite the risk that end-users would see the resulting error.