Don't amputate numberFormat (was: affecting array keys???)

Curry Kenworthy curry at pair.com
Sat Apr 22 15:50:38 EDT 2017


Richard:
 > But when we consider the full cognitive requirements for
 > using numberFormat, esp. its dependency on multi-statement
 > context, I think it would be difficult to come up with a
 > cognitive-load metric which could demonstrate that it's
 > actually easier to learn than the subset of options needed
 > to get the same result with the format function.

 > Just because we learned it years ago doesn't mean it's
 > necessarily easier to learn for anyone else starting out today.

I don't believe for a moment that numberFormat style would lose in a 
straight competition to format style for people with zero related 
experience to either. I predict the learning time would be a fraction; 
there's just not much to learn when the symbols look so much like the 
desired result. I'm trying to be fair and think of how hard that can be, 
but not having much luck. I want "8.9" and I type "0.0" - it's so easy. 
The hashes are just one additional step, and might not be needed the 
first time.

Nor do I think numberFormat is mostly useful for legacy code and old 
timers, or that more intuitive implies an inferior method. Anything but! 
That's why it's not unique in the world; very natural method of 
representing formatting options, and it will always be around in many 
products. You've proposed some intricate rules for evaluating the two 
formatting options, but your system and your calls lean in your 
preferred direction. That's fine. But with my rules, numberFormat 
usually dominates.

BTW, the human mind is naturally designed for some contextual awareness. 
Concatenations often happen more than one at a time, and it's set for 
those transactions, much the way we would say it in a conversation.

Talking about a subject with a person, if there's some context we need 
to keep in mind for the whole conversation, we can say that once at the 
beginning, not keep repeating it along with each point. As if I kept 
saying "with LiveCode, with LiveCode" when we all know that's the 
context of our discussions here! (Our discussions here with LiveCode, 
that is.) You already understand that fact. (I mean, the fact that it's 
LiveCode.) Of course I can replicate that memory with some extra code, 
but then the use of format has become more verbose, hasn't it? With 
numberFormat it's already done and infinitely tested, KISS and robust. 
So I just can't see that as a problem. It seems quite natural to the way 
we think, so might as well call it a plus.

Whether I'm wearing pants or just nice boxers (more often the latter 
around the house, as a wheelchair guy) must be considered in social 
transactions. I believe this mental stream of thought at the conscious 
level looks more like "set currentClothing to "boxers";answer door for a 
package;prepare to go out" than a series of function calls providing my 
clothing as a parameter. Then again, maybe that stream is different for 
different people. If so, take your pick with my blessing. I'm in boxers 
now typing this and giving my blessing; might as well have some fun, 
right? :)

The data type awareness is nothing to fret about either. I don't think 
it really requires awareness until they reach a certain point. If they 
are unaware, a conversion is going to happen anyway, by default when no 
format is set. So it's something very natural to learn about when it's 
brought to our attention by our own actions, and when we have a desire 
for a different result. And when that time comes, dang is it easy to 
learn! That was quick.

You need even more awareness to use format. And awareness is good, but 
we can't have it both ways. If format awareness is good, numberFormat 
awareness can't be bad. And vice versa. I refuse to see the argument 
framed as an old timer/legacy thing when intuitive systems will dominate 
the future. I can really appreciate the reasons why some people like 
format, and more power to them, it's a very good system. But I demand 
just as much technical respect for the numberFormat, so I won't hesitate 
to reframe the discussion.

Trends and fads change the landscape, and hype drives sales and 
adoption, but those come and go. My criteria are objective and fairly 
constant, and the numberFormat performs very well for my philosophy. 
Intuitive, useful, readable, usually less code, simple, fast to 
implement, easy to proofread. Even if LC were mutilated by removing or 
denigrating it (I hope not) other products, especially those geared 
toward numbers, would continue to use similar representations to reap 
the natural benefits of modern and intuitive formatting.

With both, we can both be happy I'm sure! Always enjoy talking with you.

Best wishes,

Curry Kenworthy

Custom Software Development
LiveCode Training and Consulting
http://curryk.com/consulting/




More information about the use-livecode mailing list