ASM is not good for writing floating-point math programs

If by floating-point you happen to mean binary floating-point, and not that awkward base 10 format, then coincidentally I happen to be doing that right now.

Yes, I really do.  I want to know which part of the user experience feel sluggish to you so I can either help you figure out how all the key shortcuts might help, discover that it's nothing I can fix, or find it's something I can optimize.  And I'd enjoy the opportunity to enumerate the different pieces that fit together to make up that 48KB and why I believe it's packed to the bursting point, with not an ounce of fluff.  Thanks for your response, Hayleia, and I'm glad you see my points.  I'm also happy to have educated you about the differences between the people who spend more time at Cemetech and those that spend more time here.  I hope we'll continue to see you around.  I'm glad to hear that your post was meant to not be bashing (but was meant a little hurtful?).  Anyway, as we agreed, with few exceptions the posts in the original thread were opinions, even criticisms (and complements), but criticisms and compliments that are all opinions, and thus valid as opinions.  Thanks for clarifying your motives.

Jacobly: I mean sign-exponent-mantissa, like the TI floating-point format and IEEE754.

Darl: Aye, I believe it took them >1KB to replicate the basic functionality of a DCS-style mouse, at which point they decided to instead make an Axiom wrapping the DCS GUI functions.  Unfortunately, it seems to have stalled.

Jacobly: I mean sign-exponent-mantissa, like the TI floating-point format and IEEE754.

Sorry, I wasn't very clear in my post. I actually was talking about sign-exponent-mantissa floating point numbers.
What I was referring to in my post was that TI floating-point numbers are base 10 and IEEE754 are base 2.
I'm not exactly using one of the IEEE754 specifications atm, but a 24 bit version split up into 1-7-16 bits.

Edit:

...The only people who lose are those that see attacks in intellectual debate, which based on the later posts in this thread, it seems no one is doing anymore...

Is my post one of them? I probably did feel attacked in some way, because I have become an Axe programmer and I don't like it that I wouldn't get credit for the programming in my games, which I think I deserve. I still haven't changed my mind about posting that post. Just so you know that.

agreed ^_^

Personally I think the biggest disadvantage Axe and to a lesser extent hybrid/on-calc ASM has over other languages right now is that if your program contains errors and you didn't backup, you can lose your entire progress. However I think that it's up to the user to do the effort of learning to backup his progress often on a computer while programming. When people use some judgement, the on-calc programming becomes an advantage in some ways (being able to code anywhere, for example).

Granted, on a computer you should backup too, but I mean in Axe or lib-enhanced BASIC games you are at higher risk of data loss, since most programming errors will lead to a RAM clear or corruption during testing, while on the computer the data losses are generally caused by laptop failures.

Not if you set the safety in Axe Parser to 'Auto Backup'

This feature doesn't work 100% of the time. Sometimes the backup gets corrupted.

That never happened to me - there were some bugs with that backup, but in V1.0.5 they are fixed I think.

The most important feature (for me) of Axe is, that the executable is only one program. You do not need Doors, xLib, Celtic or Grammar.
And, because I usually program for people who don't know much about the TI-83+, so if anything currupts, you don't need to set all these up / install them again.

Honestly, I do think they have some good points. However, just because a language is easy (and for many, including myself, it's not) doesn't mean worthless things come out of it. (Case and point, PortalX, Graviter) Actually, in my experience with games, high quality Axe games totally beat all but the highest quality ASM games. (Again, from my experience)

Each language has its uses. Axe is designed for speedy development of games. It was made for programmers to make as high quality games as ASM, in a fifth of the time. (However, as with every language, there is no such thing as a perfect design or programmer)

Something I find personally funny to the Axe/ASM debate, is that I actually find ASM easier than Axe!

So I agree, each language is capable of great things. It's not about what you're given before hand or how you go about it (though the experience of it is important) It's about the product. It's the same in professional development as well. 1. Make it work, 2. Make it fast, 3. Make it small. if one and two are taken care of in one fell swoop, then all the better. And if that's not your style, then just make something even awesomer in ASM! But don't bash the Axe programmer because of it.

As a side note, but I wonder how OPIA will influence this.

The hope is that OPIA will be to z80 what C/++ is to everything bigger! I'm quite certain that there will be nothing closer to assembly (for TI z80) that provides all the high-level stuff in place of it (or along with it). OPIA will not be what Axe or Grammer is; but also, nothing will be what OPIA is either Thanks, Homer-16, for including my project!!