4 ms·

It sounds like a nice IDE is the solution then

• jodrellblank 8y ago
  If it sounds that way, then I did a bad job of turning an idea into words. Having a language with a concept of errors, and hiding them behind an IDE interface, is not the same thing as having a language without the concept of errors.
  • michaelmrose 8y ago
    The best way to avoid mismatched parens is to have the closing paren inserted automatically and have operations operate on either just contents or contents and both parens. See smartparens or paredit. Never having an error is indeed the nicest way to deal with errors but I don't know how you deal with all possible errors in the same structured way as smartparens deals with parens. Further efforts in the same vein might have value but even if we can correctly discern intent and correctness what do we do with it? In theory you could not allow someone to type foo.len() if foo doesn't have a len method or force the programmer to click a dropdown of available methods but that seems cumbersome. What if it will have such a method when you are done and the error is merely a function of the intermediate state at present? Ultimately flagging that section of the text may be the best way to allow code to be entered that will ultimately be in a correct state but isn't. Using the word error and the red squiggly line is probably if anything good UI because it correctly expresses the current state of the code and does a good job of drawing attention to the source of the problem.