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
a=3
b=4
a=a+b
print a
shouldn’t be too hard. In iteration 1, forget about expressions with more than one operator such as
a=3*b+c
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)
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
A=3
or
aa=0
Then, add features as you see fit. You will run into problems, such as questioning whether
print=3
print print
should be a valid program, or whether it’s a good idea if
a=2+3*4
print a
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:
a=1
@again
print a
a=a+1
>again
add simple if statements:
a=1
@again
print a
a=a+1
if a<20 >again
The end result will likely be buggy in places. For example, if you decide to support
a=3;b=4
and parse by splitting each line on semicolons, adding strings
a=“strings may have semicolons, too;”
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.
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.