Why bilingual learners struggle with programming syntax rather than logic

A bilingual learner says, “I know what the loop should do, but I cannot write it.” It is tempting to interpret that sentence as weak programming ability. Often it describes something more specific: the learner understands the process, but must cross several linguistic and symbolic boundaries before the computer accepts their answer. Programming syntax, English-heavy documentation, technical vocabulary, and the conventions of a new development environment can all create friction around an idea the student already has.

That distinction matters because the teaching response should change. More repetition of the same syntax worksheet may not help a student who is reasoning correctly but cannot yet map “repeat this action for every item” into the exact form of a for statement. Good instruction makes the mapping visible and lets the learner practice it without confusing syntax difficulty for conceptual failure.

Separate four layers of a programming task

Many assignments blend four kinds of work together:

1. Problem meaning: What is the task asking for?
2. Algorithmic idea: What steps, conditions, or repetitions solve it?
3. Programming representation: Which language constructs express those steps?
4. Surface syntax: Where do punctuation, indentation, spelling, and types have to be exact?

A learner may be strong in the first two layers and still need support in the last two. Asking students to narrate an algorithm in a language they are comfortable using can reveal this. If they can describe the sequence and predict what should happen, the instruction can focus on representation rather than restarting from the concept itself.

Syntax carries hidden language demands

Keywords are short, but they are not culturally neutral. Words such as while, else, return, and break have everyday meanings that only partially match their programming meanings. Error messages can be even harder: “unexpected token” or “cannot convert” asks a student to decode technical English while already dealing with a failing program.

There are also directionality and punctuation demands. A learner has to notice parentheses, braces, colons, quotation marks, camelCase, and the difference between assignment and comparison. None of these are evidence that the underlying logic is difficult. They are conventions that need explicit attention.

# The algorithmic idea:
# Start at 0. Repeat while the number is below 5.
# Show the number, then add 1.

count = 0
while count < 5:
    print(count)
    count = count + 1

A teacher can discuss the algorithm before presenting the code. Then each line becomes a translation decision: where is the starting value represented, where is the condition, and which line advances the process? That moves the learner from copying syntax toward connecting a familiar idea to a new notation.

Use bilingual discussion as a cognitive resource

Allowing students to think, discuss, or annotate in more than one language does not lower the standard for code. The program still has to execute. What changes is the path to understanding. Students can use their strongest language to test an explanation, negotiate a strategy with peers, or name a misconception before they must phrase it in technical English.

A practical routine is “explain, map, execute.” First, learners explain the goal in natural language. Next, the class maps the explanation to a small set of code constructs. Finally, students run and modify the program. The natural-language explanation is not a detour; it is evidence of what they already understand.

Teach error messages as a genre

Error messages are a special kind of reading. Rather than handing students a long list of errors to memorize, teach a repeatable response:

• Find the location the tool reports, but verify nearby lines too.
• Identify the category: syntax, name, type, or logic.
• Translate the message into a small question: “What token did the computer expect here?”
• Change one thing, rerun, and observe what changed.

Make a shared glossary of the error terms students see most often, with examples in plain language. When possible, pair the term with a visual or a tiny executable example. A student who can say “the loop’s condition is missing a colon” has gained a reusable diagnostic habit.

Assess the concept separately from the notation

If every assessment requires perfect syntax, instructors cannot tell whether students understand a concept. Mix code-writing tasks with tracing, predicting output, ordering pseudocode, explaining a program, and identifying what needs to change. These formats are not easier versions of programming; they examine different parts of the skill.

When a learner’s explanation is right but their code is not, respond precisely: “Your loop idea is correct. Let’s find the syntax that expresses it in Python.” That feedback protects a student’s sense of competence while giving them a concrete next step.

Design for gradual independence

Scaffolds should fade. Early lessons can use code templates, bilingual annotations, and a limited set of patterns. Later, remove one support at a time: perhaps students write the loop condition, then the full loop, then choose between multiple control structures. The goal is not to keep the learner dependent on translation. It is to give them enough conceptual footing that syntax practice becomes meaningful.

This perspective connects directly to Yusuf Gadelrab’s ACM SIGCSE 2026 poster collaboration, “Exploring Bilingual Coding for Inclusive Computer Science Learning.”The poster reports on bilingual coding for inclusive computer science learning and included 60 bilingual participants: 40 novice and 20 experienced participants.