Transition complete. There are now 3 branches: fn, Bobcat, and master (also known as “Cheetah”). I’m hoping that the new code-base in Cheetah will prove to be much faster than the original design. All things considered, I knew I had designed a slow system. It was effective and relatively easy to maintain, and the new system is likely to be slightly more challenging. However, I maxed out what I was going to get out of the old design. The processing code was very bulky with tons of methods dedicated to it. I spoke about its task system in a previous post, which should have been published a long time ago, but now is as good a time as ever to compare it with the new system. The new system (the new engine, that is) has a separate parsing and execution system, reducing the primary execution sector (the methods doing the repetitive operations) to only a handful of methods.
ATTENTION: This applies to the first two branches of Copper, known as “fn” (original, using “fn” for function start syntax) and “Bobcat” (the version to begin using the square bracket syntax). The task-processing system has been replaced in the new master branch known as “Cheetah”.
Copper is a very simple language. Unsurprisingly, the language requires a number of little quirks on the backside that make the model I’ve chosen for processing tokens to look like gold in hindsight. … Maybe I’ve just done this before and learned from experience. 😉
Sometimes the easiest way to see if something will work is to start coding it, writing down ideas as you go. The adage is 100 hours of programming will save you 10 hours of planning. That can be very true, but sometimes it isn’t possible to figure out if an idea will work until you try putting it together in code. You’re going to need to write some pseudo code, and you may get to the point where you’re just writing code.
After the disappointing times in the previous benchmarking tests, some things received optimization… and some things, reconsideration.
Before going too far, I wanted to test the speed differences in the two branches to see how much of a different “fn” makes in speed and if it even merits consideration. For this, I would need a lengthy test, but to ensure that the data is reasonably comparable, I needed code that was about the same in time for both branches. Hence, I created a looping test that merely iterates an integer and outputs the speed. The times for both branches should be different by no more than a small amount. If that amount happens to be equal to or greater than the difference in times for a test comparing the usage of “fn” to not, then either the test isn’t time-consuming enough, or the time cost for function construction doesn’t outweigh the cost elsewhere, or – a stretch – there really is no difference because the clock() stinks, at least on my PC. The clock() can be shown as reliable by getting consistent clock times, so any times that are greater than the clock-time variance are significant times. That makes only the first or second options viable.
Names are an important part of programming. They should be relatively easy to create. Up until this development point, I wasn’t making that the case, and because of that, things were looking alot more difficult.
Functions are about all there is in Copper. This fact is so driven home that, after further consideration, it seems the “fn” is entirely useless. Should it remain?