It’s not the syntax
Pine's syntax is small. If you have written any language, you can read a Pine script in an afternoon. That is why "learn programming first" is bad advice here — experienced programmers get stuck on Pine too, and they get stuck on the same two things beginners do.
Both are things no mainstream language has.
1. Your variables are histories, not values
A Pine script does not run once. It runs once per historical bar [1], and repeatedly on the realtime bar — once for each new update [1]. You never write that loop. It is the environment.
So close is not a number. It is the closing price on the bar currently being
evaluated, and close[1] is the one before it. Every variable carries a
history behind it, and [1] reaches into that history.
This is why a beginner's first instinct — write a loop over the bars — is wrong, and why the code looks strangely flat. There is nothing to loop over because you are already inside the loop.
The consequence that actually bites: a calculation only has a continuous history if it ran on every bar. Skip it on some bars and its internal state is broken, with nothing in the source to show it. That is the whole reason the v6 lazy-evaluation change matters, and it is the first thing to check in generated code.
2. Types have a second dimension nobody warns you about
Pine's fundamental types are ordinary: int, float, bool, color,
string [2]. That part is easy.
The part that is not: every value also carries a qualifier, describing when it becomes known. There are four, and they form a hierarchy [2]:
const < input < simple < series
| Qualifier [2] | Known |
|---|---|
const | when the script compiles |
input | when the user confirms the settings dialog |
simple | when the script starts on the first bar |
series | can change on every bar |
And the rule that generates most of the confusion:
Any variable, parameter, or operation that accepts a value with a specific qualifier also allows a value of the same type with a weaker qualifier, but not one that is stronger. [2]
Conversion runs one way only, down the hierarchy. A parameter wanting
simple int will take input int or const int happily and reject
series int — because series is higher in the hierarchy [2]. Parameters
qualified simple accept only simple, input or const [2].
No other language most people have used works like this. You can know the type of every value in your script and still be unable to compile it.
One more thing that trips programmers specifically
Pine does not automatically convert other types to bool in logical
expressions [2]. int to float happens automatically [2]; truthiness does
not. If you have written C, Python or JavaScript, if someNumber is a reflex,
and here it is an error rather than a shortcut.
The error that makes no sense
Sooner or later you write something reasonable and Pine refuses it with a
message about series and simple. It is the most-asked Pine question, and
almost every answer online is "use input.int() instead" with no explanation
attached — which fixes the line and teaches you nothing.
Here is the reason, and with it the whole class of error becomes predictable.
Why a length cannot be a series
Consider a moving average whose length you want to vary as volatility changes.
The length is now a value that can differ on every bar — a series int. And
the parameter will not take it, because it is declared to accept simple int,
and series is stronger than simple in the hierarchy [2].
That looks arbitrary until you ask what the platform has to do. To keep a history for a 200-period average it must reserve a buffer, and it has to size that buffer before the bars start arriving. A length that can change on any bar makes that impossible: the buffer would have to be resized mid-run, on every bar, forever.
So the restriction is not the type system being fussy. It is the engine telling you that this number has to be settled before the first bar.
Which is why input.int() works
input.int() produces an input int — known once, when the user confirms the
settings dialog, and constant thereafter. input is weaker than simple, and
weaker qualifiers are accepted where stronger ones are not [2]. It is not a
trick; it is the qualifier the parameter was asking for all along.
How to read any qualifier error in ten seconds
Ask two questions, in order:
- What is the strongest qualifier in my expression? One
seriesvalue anywhere makes the whole expressionseries. Anything derived fromclose,high,volume, ata.*call or a bar-dependent condition isseries. - What does the parameter accept? If it wants
simple, nothingseries-derived will go in, and no amount of rewriting the syntax changes that.
The fix is always the same shape: move the decision earlier. Make the value an input, or a constant, or compute it once rather than per bar.
The three that come up most
| You wrote | Why it fails | What to do |
|---|---|---|
| a length computed from price | that length is series; the parameter wants simple | make it an input, or pick from a fixed set with switch |
| a timeframe string built from a variable | the request needs it settled up front | build it from inputs, not from bar data |
a lookback like close[n] where n varies | the history offset must be resolvable | use an input, and clamp it to 0 or more |
That last row is worth a note: a negative offset is a reference to the future,
so an offset input should have minval = 0. It is easy to ship an offset
control that allows negative values, and the result is either a runtime error or
a leak — see
repainting and lookahead.
What this means for learning Pine
The qualifier system is the one genuinely unusual idea in the language, and once you have it, most of Pine's error messages stop being surprises. It is worth half an hour of deliberate attention early — considerably more useful than memorising function names, which the reference manual has anyway.
Tactix AI — Studio vs Guide
Tactix AI is AlfaTactix’s product assistant brand (open Tactix AI).
- Tactix Studio turns a one-sentence strategy description into a draft across Timeframe, Signals, Filters, and Risk in the visual Strategy Builder. You review and edit every field before Code Generator writes MQL5 or Pine Script.
- Tactix Guide explains the step you are on — what to fill, what a control means, or how to phrase a rule — without dumping untested source code.
That is form-first automation: the LLM never replaces Code Generator, and you keep plan limits and real-time validation.