4 ms·

Most of these errors are not really interesting. Almost all of them are simple typos or syntax errors. I get that this is the errors that are simple to analyze

Most of these errors are not really interesting. Almost all of them are simple typos or syntax errors. I get that this is the errors that are simple to analyze. Reference/value confusion would for instance be more interesting, but I guess that's harder to autodetect.

kelukelugames 10y ago
I agree the errors are uninteresting to experienced engineers. I think give this data to newcomers can help them debug faster, build confidence, etc.
achamayou 10y ago
Aren't they? The fact that confusion between = and == is 4th most frequent is quite interesting for example. It's possible to disallow assignments in places where comparisons are most likely (expressions that are known to coerce to a boolean), Python does it, with presumed significant productivity benefits (lots of time isn't spent dealing with that common mistake). D can arguably be mitigated by differentiating bitwise operators more them from their logical counterparts (for example by having the logical operators in plain English). Many more are better handled at the editor/IDE level, but this seems like a really interesting read for anyone involved in PL design.
- TheOtherHobbes 10y ago
  The Alto thread posted a ref to BCPL, and it was interesting that the original symbols for the comparison operators were text: eq, ne, gt, lt. C broke BCPL syntax that was clear, memorable, and consistent and replaced it with a math-like syntax that must have wasted millions of person hours of debugging time in the decades since - for no good reason. Similarly &(pointer address) and &&(logical and) are too close and too easy to typo. Language design really should have considered human factors much more than it did.
  - dsp1234 10y ago
    Interestingly, Powershell uses eq, ne, gt, lt, etc for its comparison operators.
    - 13of40 10y ago
      The historical reason behind that is the > and | symbols were used as redirection operators to follow shell conventions so they used -gt and -bor. All of the other operators followed for consistency. There was also a big kerfuffle about statements like "$a = 1" or "$a++" not being able to return values like in C because if they were used stand-alone the return value would be printed out by the host.
    - mkesper 10y ago
      Yes, this always gets me. I don't like perl-style at all. Compare the cognitive load of distinguishing -lt and -le vs. < and <=.
  - groovy2shoes 10y ago
    > Similarly &(pointer address) and &&(logical and) are too close and too easy to typo. Not to mention &(bitwise and).
- danso 10y ago
  I loved doing this in Ruby: if (x = y) x += 10 end (assign y to x and operate on x if x is truthy ) The optional parens reminds me that this is a deliberate assignment. But as someone who now teaches Python, I thank the Python gods who disallowed such syntactic sugar. I've found it impossible to overestimate how difficult it is for beginners to grok "a = b"...and can you blame them, after years for math instruction telling them that that equals sign means something else? (Never mind the clusterfuck that occurs when trying to teach SQL -- which also uses singal equals sign for equality -- in tandem with a scripting language. The cognitive difficulty is so high that I've considered switching to teaching R, which at least has the optional arrow operator, "a <- b"
  - jacquesm 10y ago
    That would not pass review with me. Code should be as obvious and simple to read as possible. It doesn't matter whether or not the reader is a beginner or not, what matters is that it reads like it could be a typo. So there is more cognitive overhead than strictly necessary, and quite possible there are bugs hidden in those 'clever' bit that you love so much.
- bbcbasic 10y ago
  Haskell has a neat solution. There is no assignment operator. (Let bindings are a different thing)
rwmj 10y ago
Isn't that very interesting? It means the IDE / environment they are using allows them to make typos and syntax errors. Why weren't those corrected and/or highlighted as they typed? The first programming language I used had magic keys which produced whole keywords (eg. pressing "P" produced "PRINT"). Typos were impossible! If you still managed to type a line with a syntax error, the cursor changed to a flashing $ over the error and you literally couldn't submit the line of code until you'd fixed it. And that was on a machine with 1 kilobyte of RAM and a < 4 MHz processor!
- rtpg 10y ago
  Yeah, I am pretty excited about the idea of IDEs just presenting ASTs instead of text (of course can always save as text). There's a haskell structured mode that tries to do a similar thing. It might seem silly, but the biggest impediment I can think of is copy-pasting code from elsewhere. If your variable names are different, the IDE should reject the code (since you shouldn't be able to commit variables that don't exist), but then what do you do? Open it in Notepad and "fix" it? EDIT: structured haskell mode, complete with GIFs showing how it works https://github.com/chrisdone/structured-haskell-mode#features https://github.com/chrisdone/structured-haskell-mode#feature...
  - merijnv 10y ago
    Are you familiar with Lamdu? http://www.lamdu.org/ http://www.lamdu.org/
  - e12e 10y ago
    Brings to mind Smalltalk's concept of images (which comes from lisp, I believe) and Forth. Of course in Smalltalk, you do work with code-as-text, but then it becomes code-as-program (technically byte-code, with among other things a text representation). Does seem more reasonable than the anachronistic insistence on text->parse-to-AST->(whatever magic, and however many transforms the actual compile-part is). Then again, we all know what a rich editor is. It's MS Word. And MS Word eats documents and depricates file formats. On the other hand, I think Emacs Org-mode, Gimp images and the literate editor in Python, Leo[l] are examples of more pleasant "rich format" editors. It is a bit odd that what we take for granted for image files (edit history, binary format++) we fear in our IDEs. [l] http://leoeditor.com/ http://leoeditor.com/

kelukelugames 10y ago

I agree the errors are uninteresting to experienced engineers. I think give this data to newcomers can help them debug faster, build confidence, etc.

achamayou 10y ago

Aren't they? The fact that confusion between = and == is 4th most frequent is quite interesting for example. It's possible to disallow assignments in places where comparisons are most likely (expressions that are known to coerce to a boolean), Python does it, with presumed significant productivity benefits (lots of time isn't spent dealing with that common mistake). D can arguably be mitigated by differentiating bitwise operators more them from their logical counterparts (for example by having the logical operators in plain English). Many more are better handled at the editor/IDE level, but this seems like a really interesting read for anyone involved in PL design.

TheOtherHobbes 10y ago
The Alto thread posted a ref to BCPL, and it was interesting that the original symbols for the comparison operators were text: eq, ne, gt, lt. C broke BCPL syntax that was clear, memorable, and consistent and replaced it with a math-like syntax that must have wasted millions of person hours of debugging time in the decades since - for no good reason. Similarly &(pointer address) and &&(logical and) are too close and too easy to typo. Language design really should have considered human factors much more than it did.
- dsp1234 10y ago
  Interestingly, Powershell uses eq, ne, gt, lt, etc for its comparison operators.
  - 13of40 10y ago
    The historical reason behind that is the > and | symbols were used as redirection operators to follow shell conventions so they used -gt and -bor. All of the other operators followed for consistency. There was also a big kerfuffle about statements like "$a = 1" or "$a++" not being able to return values like in C because if they were used stand-alone the return value would be printed out by the host.
  - mkesper 10y ago
    Yes, this always gets me. I don't like perl-style at all. Compare the cognitive load of distinguishing -lt and -le vs. < and <=.
- groovy2shoes 10y ago
  > Similarly &(pointer address) and &&(logical and) are too close and too easy to typo. Not to mention &(bitwise and).
danso 10y ago
I loved doing this in Ruby: if (x = y) x += 10 end (assign y to x and operate on x if x is truthy ) The optional parens reminds me that this is a deliberate assignment. But as someone who now teaches Python, I thank the Python gods who disallowed such syntactic sugar. I've found it impossible to overestimate how difficult it is for beginners to grok "a = b"...and can you blame them, after years for math instruction telling them that that equals sign means something else? (Never mind the clusterfuck that occurs when trying to teach SQL -- which also uses singal equals sign for equality -- in tandem with a scripting language. The cognitive difficulty is so high that I've considered switching to teaching R, which at least has the optional arrow operator, "a <- b"
- jacquesm 10y ago
  That would not pass review with me. Code should be as obvious and simple to read as possible. It doesn't matter whether or not the reader is a beginner or not, what matters is that it reads like it could be a typo. So there is more cognitive overhead than strictly necessary, and quite possible there are bugs hidden in those 'clever' bit that you love so much.
bbcbasic 10y ago
Haskell has a neat solution. There is no assignment operator. (Let bindings are a different thing)

rwmj 10y ago

Isn't that very interesting? It means the IDE / environment they are using allows them to make typos and syntax errors. Why weren't those corrected and/or highlighted as they typed? The first programming language I used had magic keys which produced whole keywords (eg. pressing "P" produced "PRINT"). Typos were impossible! If you still managed to type a line with a syntax error, the cursor changed to a flashing $ over the error and you literally couldn't submit the line of code until you'd fixed it. And that was on a machine with 1 kilobyte of RAM and a < 4 MHz processor!

rtpg 10y ago
Yeah, I am pretty excited about the idea of IDEs just presenting ASTs instead of text (of course can always save as text). There's a haskell structured mode that tries to do a similar thing. It might seem silly, but the biggest impediment I can think of is copy-pasting code from elsewhere. If your variable names are different, the IDE should reject the code (since you shouldn't be able to commit variables that don't exist), but then what do you do? Open it in Notepad and "fix" it? EDIT: structured haskell mode, complete with GIFs showing how it works https://github.com/chrisdone/structured-haskell-mode#features https://github.com/chrisdone/structured-haskell-mode#feature...
- merijnv 10y ago
  Are you familiar with Lamdu? http://www.lamdu.org/ http://www.lamdu.org/
- e12e 10y ago
  Brings to mind Smalltalk's concept of images (which comes from lisp, I believe) and Forth. Of course in Smalltalk, you do work with code-as-text, but then it becomes code-as-program (technically byte-code, with among other things a text representation). Does seem more reasonable than the anachronistic insistence on text->parse-to-AST->(whatever magic, and however many transforms the actual compile-part is). Then again, we all know what a rich editor is. It's MS Word. And MS Word eats documents and depricates file formats. On the other hand, I think Emacs Org-mode, Gimp images and the literate editor in Python, Leo[l] are examples of more pleasant "rich format" editors. It is a bit odd that what we take for granted for image files (edit history, binary format++) we fear in our IDEs. [l] http://leoeditor.com/ http://leoeditor.com/