Argh

OK, no, I'm not in good mood.

Turns out, spending all these months adding modern features to Forth has ended up making it harder to debug (and therefore write), more complicated, AND, slower.    Well, maybe.  It might be my fault for ab/using these new features.  Not using them appropriately.  I had a feeling about it, but I was so concerned about looking "legit" to the public, making the code all "high level" with lots of generics.  I am not sure if anyone cares right now - which doesn't bother me at all, because it means I don't have to be "legit" to keep anyone's attention.  Since no one is bothering me, and Plan A didn't lead to a big bang, I can take it wherever I want.

Turns out generics have a price.  Turns out they complicate things if you don't use them appropriately; maybe one central polymorphism system is hugely unnecessary some of the time.  Maybe I need to say OK here are places where it can make things easier (high level) and here is where it would actually be easier if I ignored them (low level).

Forth is assembly on steroids.  It makes low level seem high level, makes it fit in the palm of your hand, makes it friendly;  manageable.  Forth likes dumb data types, and keeping things flat - not building systems upon systems, but instead making specialized systems out of bits and pieces - that's flatter design  that doesn't necessarily hinder the complexity of your ideas but keeps them easier to test and change.   If those low level bits and pieces are reliable and rich, starting "from scratch" should be less painful.

Admitedly, some systems are complex.  But when you admit that, the fact that complex systems are hard to implement becomes a great motivation to simplify; not necessarily to not do your idea, but to let Forth help you do it in a dumb, flat, manageable way.  If you're smart and confident about Forth, you'll get that working and then implement the complex stuff under the hood, invisible and irrelevent to the calling code.

And you shouldn't proliferate redundant datatypes (integers, fixed point, halfword, bytes), unless you really REALLY need to for some reason. Polymorphism helps manage that (and Forth hates lots of types since it has no typing system), but it has to be appropriate.  For instance I know that it's prohibitive for building dynamic vertex lists, because each call to write out a vertex would be twice as expensive.  But for strings, it makes sense because it's an inherently non-realtime thing that you do in short bursts.  Polymorphism would help solve the problem of having to manipulate strings for external API's that love them, or for storing XML, or writing out Forth code :)

Forth has wordlists, a concept that lines up neatly with modular program design.  I'm using them, but maybe not as well as I could be.  Because sometimes I use polymorphism when reaching into a wordlist would be fine, and more efficient (direct call instead of a method call).

What's so weird is when everyone else says that making a program fast means "hard to read" or "complex", the old collision grid code was soooo much faster yet it was about the same size it is now.  Less if you count the assembly code I had to write to make it reasonable.

I get hung up on loading everything at once, maybe it's a laziness; as if to say "you never know when something will break" so you compile everything in case something does.  That is distracting; the human brain wasn't designed to work on more than one thing at once, because when it does, when I'm able to concentrate on one thing at a time, I get a lot more efficient.  If I used wordlists more often I'd be forced to narrow focus because it's inconvenient to be constantly modifying the search order.

OK, so, what have we learned ... it's good to break it down, figure out what you've been doing in the broad scope, and what you're doing right now, and make the bits and pieces ("primitives") support that by being fast and easy to use.  Perhaps wrap the polymorphic system AROUND primitives (same name, separate wordlist(s)) to virtualize them for higher level systems; but only when it's appropriate; probably great for modular plugin things.