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

Richard Gaskin ambassador at fourthworld.com
Sat Apr 22 18:42:54 EDT 2017


Curry Kenworthy wrote:

 > 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 must admit I have neither the methodological background nor the 
resources to conduct such a study myself, hence my reliance here on mere 
heuristics.

The link I included in my other post about cognitive load may be 
interesting, though in a more general sense.  Of course that researcher 
wasn't comparing two different ways to format numbers in LC, but there 
may be aspects of his research which could guide a more detailed 
assessment here if needed.

That's a big "if", though, because I agree that in both cases cog. load 
is small enough that the distance between both forms is almost certainly 
shorter than this thread. :)

I just observe that we talk about numberFormat here a few times a year, 
even among people who've been using it for decades.

But I can't recall the last time we saw questions here about the format 
function.  More often, as with Paul's post, when format is mentioned 
here it's as a solution.


 > I want "8.9" and I type "0.0" - it's so easy.

Sure, but by itself it doesn't do anything observable.

With format(), you put something in and get something else out in one 
statement.

With numberFormat, you first change an abstraction in the engine, then 
do something to a value elsewhere, and if you remembered to do it in the 
right order, and within a single handler, you'll get what you were 
looking for.

That is, unless you've forgotten that you'd set the numberFormat to some 
value further up in the handler for some other reason than the place you 
happen to be typing in now some 50 lines later, where you're seeing 
values that aren't what you had expected because you'd overlooked that 
the numberFormat setting you'd done for one thing 50 lines up is still 
affecting everything afterward until you reset it. (Who among us has 
never had that happen to them?)   :)


 > Nor do I think numberFormat is mostly useful for legacy code and old
 > timers, or that more intuitive implies an inferior method. Anything
 > but!

Wholeheartedly agree, which is why I wrote:

    When numberFormat can do the job and you want to use it, use it.
    For certain tasks it may be somewhat simpler than the format
    function.


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

Amen to that, Brother Kenworthy.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com




More information about the use-livecode mailing list