Greenspun's tenth rule of programming:

> Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

I don't have it handy but in uni I was responsible for the Excel formula parser in a group project. I agonized over it for like six days until it suddenly clicked that I could just do a bunch of string matching, and rewrite the formula over and over again until it was a number.

More precisely, I had figured out how to parse an Excel formula (keeping track of braces and commas, I recall!). For the actual math symbols, all I had to do was rewrite them as Excel formulas!

3+6*2 -> 3+MUL(6,2) -> ADD(3,MUL(6,2))

In order of precedence. And then just evaluate the resulting formulas inside-out:

ADD(3,MUL(6,2)) -> ADD(3,12) -> 15

It somehow ended up being a thousand lines of code. Another guy doing the same assignment told me he did it in 50 with regular expressions.

In retrospect, what I did reminds me of hammering in a nail with a screwdriver.

I ended up revisiting the idea later (just the math parser, no ADD() syntax) and it was much nicer, like 30 lines of JS (no regex either!). (Well, you can do it in one line with eval, but yea :)

> Overall, I built a Graph Reduction engine

I did the same for my performant implementation of pure functional programming language BLC/BLC2, which in 400+ lines contains a graph reduction engine for combinatory logic, to which the lambda calculus programs are converted by Kiselyov's bracket abstraction algorithm.

[1] https://github.com/tromp/AIT/blob/master/uni.c

This reminds me of decades ago when ...wait, I was still writing code like three years ago.

Did you just say "just"?

Used to be a common refrain when we were whiteboarding new features. Usually as a check on somebody's overly ambitious thinking.

I counted 23 "just"s in the article. Bravo. Sometimes you have to _just_ plow ahead.