If you don’t want to read up front, don’t; start with a calculator. If you know regular expressions (and even if you don’t), getting something that handles<p><pre><code> a=3
b=4
a=a+b
print a
</code></pre>
shouldn’t be too hard. In iteration 1, forget about expressions with more than one operator such as<p><pre><code> a=3*b+c
</code></pre>
If you think it’s easier, also forget about multi-character identifiers (a…z should be enough for everybody) types (all variables can be int or, if desired, float)<p>Also, initially forget about making a product that doesn’t crash on invalid input. If a…z is enough for everybody, your toy language may crash on<p><pre><code> A=3
</code></pre>
or<p><pre><code> aa=0
</code></pre>
Then, add features as you see fit. You will run into problems, such as questioning whether<p><pre><code> print=3
print print
</code></pre>
should be a valid program, or whether it’s a good idea if<p><pre><code> a=2+3*4
print a
</code></pre>
prints ‘20’, but that’s part of the fun (if you have a puzzling mind, figuring out how to do that ‘properly’ without reading about it isn’t out of reach). And those features you add shouldn’t be large. For example, looping:<p><pre><code> a=1
@again
print a
a=a+1
>again
</code></pre>
add simple if statements:<p><pre><code> a=1
@again
print a
a=a+1
if a<20 >again
</code></pre>
The end result will likely be buggy in places. For example, if you decide to support<p><pre><code> a=3;b=4
</code></pre>
and parse by splitting each line on semicolons, adding strings<p><pre><code> a=“strings may have semicolons, too;”
</code></pre>
may result in an interpreter/compiler that is broken for a while. Who cares? You aren’t building a compiler or interpreter, you’re learning.<p>Also: start with an interpreter. A compiler isn’t that much harder, but requires you to know about your system’s assembly, object code format, etc.