Hacker News Reader

  > These problems are more typo/syntax-based rather than logic-based.

This!

I was hoping for a list of logic and organization / structure errors.

On the idea of editor feedback, one thing I find frustrating is that hardly anyone teaches how to read error messages and stack traces. That’s the most important thing because as a beginner you make tons of errors and you see them a lot! Books and tutorials don’t show any errors, so when you inevitably make one it’s hard to figure out what exactly you did wrong.

This is novice programmers. They aren't writing big enough programs for organization/structure errors to matter much. They could have logic errors, but this kind of stuff is the fluff you have to get out of the way before you can start showing them the logic errors.

There's kind of a sequence:

  - You didn't say what you meant (this kind of error)
  - You said what you meant, but you meant the wrong thing (logic errors)
  - You said the right thing, but in the wrong place (organization/structure).

With a novice, you might need to work through them in approximately that order.

I’m not sure what “novice” means. I certainly know when I was beginning I glossed over stack traces because they were a giant information dump and I didn’t know how to read them. They tell you exactly what’s happened, the call, what line it broke, what the local variables are, how it got there, etc. But it’s like reading a foreign language and is intimidating for a beginner.

IDEs help a lot but once you know how to read a stack trace it’s easy to understand if you made a typo:

   AttributeError: Person object type has no attribute “helo”

…or have a bug:

  AttributeError: None type has no attribute “hello”

> I’m not sure what “novice” means.

It took me 15 years to convince myself I was no longer a novice. I've been at it for 40 years now, and I still don't think I'm anything like a master of the craft, nor ever will be.

> > Confusing short-circuit logical operators > Using == instead of .equals to compare strings.

> These problems are more typo/syntax-based rather than logic-based.

Sure, but you can also see why it could take absolutely ages for a novice to work out what's wrong, right? The bitwise operators will work for evaluating logic like this in some cases, but not all. And the student knows it's something like "&" for "AND" and "|" for "OR". Could be a really tricky bug if you've been introduced to logical operations, but not bitwise ones, and don't therefore realise they could exist & be confused.

> These problems are more typo/syntax-based rather than logic-based.

Interestingly enough, syntax-based mistakes are often the first hurdles students encounter in programming, as described in Altadmri's paper. They also go on to observe that these mistakes do subside as the semester progresses as students "get used" to syntax, while logic-based errors will persist.

While editors can provide some benefit to these issues, they can also be rather complex; often designed for industry rather than education. However these issues persist even with BlueJ, the IDE used in Altadmri's paper, which is an education-focused development environment.

My current research on the topic encourages the use of lower-level exercises (even typing exercises) with CS examples to help students get familiar with coding's syntactic structures without problem solving [1]. As a result, students are struggling on correctly solving the coding problem while struggling to correctly implement the syntax necessary. My recommendation is to rather provide additional practice opportunities that isolate these lower level skills so students aren't trying to problem solving AND refine their skills at the same time. In addition, these lower level exercises can provide students with additional examples that can be more beneficial that simply showing them code snippets [2]. These examples can help serve as 'templates' that students can refer to when they encounter similar problems.

[1] https://dl.acm.org/doi/pdf/10.1145/3373165.3373177

[2] https://educationaldatamining.org/EDM2021/virtual/static/pdf...

The typing exercises remind me of 80s/90s computer magazines having basic/asm code for interesting programs or games. You had to retype them to run them.

It was slightly before my time, but I suspect a large number of people got through the "learn the tooling" stage simply by retyping, looking for the mis-type when they got it wrong, and learning how to understand the feedback.

The natural next thing to do is to try to change some values and see what happens. All of a sudden you're learning how the whole program and environment work together and can always go back to a known good state by retyping what the paper says.

> The typing exercises remind me of 80s/90s computer magazines

YUP! I've been collecting the old Usbourne and Micro Adventure books and typically bring them along when I give presentations to say "This is how they did it in the old days! Let's do it again!" I then compare it to other "technical" skills like playing an instrument, acting, and martial arts. Each one has a "you gotta memorize/drill this" phase that is imperative to higher level performance, creativity, or problem solving.

> The natural next thing to do is to try to change some values and see what happens.

There is some work out of the UK known as PRIMM that uses this as one of their initial steps [1]. I spoke with Sue Sentance at SIGCSE in 2017 when she presented her studies and it sounds like another cool way to present coding practice without problem solving. John Edwards out of Utah is also doing "simple syntax exercises" [2] for his style of drilling where you have students do 20-30 exercises on a concept without very minor changes like "make the loop go 3 times; now 4; now go backwards from 4 to 0; etc.".

[1] https://blogs.kcl.ac.uk/cser/2017/09/01/primm-a-structured-a...

[2] https://dl.acm.org/doi/pdf/10.1145/3372782.3406259

> (I wish java had `[[nodiscard]]` but alas).

Try Google's Error Prone:

https://errorprone.info/bugpattern/CheckReturnValue

Or @CheckResult in Android-flavor Java

>> Ignoring the return value from a non-void method.

Beginners might also write a method/function with a return parameter they don't care about (or that they sometimes don't care about) but that has some desirable side-effect.

A common issue I've seen is more the return is replaced with a print statement. As a result, their code "appears" to working because they're still seeing the right values appear in their console when they run the code. If the function's returned value doesn't get used somewhere else, then they don't see where the issue is until points are deducted.